invalidopcode has quit [Remote host closed the connection]
invalidopcode has joined #yocto
<LetoThe2nd>
yo dudX
mrnuke has joined #yocto
granjow has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
frieder has joined #yocto
frieder has quit [Remote host closed the connection]
<granjow>
Hi there, I'm trying to build nut, but configuring fails with QA issue “it looked at host include and/or library paths while determining system capabilities” – I do have warnings (cross tools not prefixed with host triplet, not running test binaries) but I'm not sure what really is the reason for the QA error and how to fix this. Where do I best start?
<LetoThe2nd>
granjow: by looking at the build system/infrastructure that the package uses, it almost certainly is not cross compile aware.
frieder has joined #yocto
gho has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
frieder has quit [Remote host closed the connection]
frieder has joined #yocto
<granjow>
LetoThe2nd: Okay; automake is fairly new to me, how can I see that? (ChatGPT suggests to check AC_ARG_VAR, AC_CHECK_TOOL and others, but it lacks some clarity :))
frieder has quit [Remote host closed the connection]
mvlad has joined #yocto
zpfvo has joined #yocto
frieder has joined #yocto
<LetoThe2nd>
granjow: lol interesting way to look at it.
<LetoThe2nd>
granjow: i guess the key is to understand if CC, LD, all of those are assigned/overwritten somewhere. because if the autotooling is not doing any weird tricks, then it works out of the box by adding "inherit autotools" to the reicpe.
manuel1985 has joined #yocto
<granjow>
LetoThe2nd: For some questions it is really nice as it has broad knowledge (not always correct), yesterday I watched a video with a guy melding two wires together with pliers, and ChatGPT knew that was spot weldering.
invalidopcode has quit [Remote host closed the connection]
invalidopcode has joined #yocto
<granjow>
LetoThe2nd: The ideas as still-newbie to Yocto sound reasonable to me :D
alicef has quit [Quit: install gentoo]
alicef has joined #yocto
Algotech75 has joined #yocto
mckoan|away is now known as mckoan
xmn has joined #yocto
amitk_ has joined #yocto
<granjow>
LetoThe2nd: Ok, I'm guessing this should not point to /usr: checking for libneon cflags... -I/usr/include/neon -I/usr/local/include/neon
xmn has quit [Ping timeout: 252 seconds]
amitk has quit [Ping timeout: 272 seconds]
manuel has quit [Remote host closed the connection]
leon-anavi has joined #yocto
rob_w has quit [Remote host closed the connection]
manuel has joined #yocto
<granjow>
Can I just disable this QA check? It says Rerun configure task after fixing this. [configure-unsafe]
florian has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<granjow>
Is this a test that cannot be skipped? It is not listed in insane.bbclass.
zhmylove has joined #yocto
florian_kc has joined #yocto
lainwir3d has joined #yocto
<lainwir3d>
Hi
<lainwir3d>
Building poky/meta/recipes-devtools/python/python3_3.10.7.bb fails here. Log file (python3-native/3.10.7-r0/temp/log.do_install.xxxxxx) not really helpful except for "Failed to build these modules: _hashlib"
<lainwir3d>
New to yocto, so might not be looking at the right place. Host is Fedora 36 wsl
<lainwir3d>
ok no matter, found a solution (I just skip the build completness check I dont need python)
gstinocher[m] has quit [Ping timeout: 264 seconds]
Tartarus1 has quit [Ping timeout: 260 seconds]
ThomasRoos[m] has quit [Ping timeout: 260 seconds]
perceval[m] has quit [Ping timeout: 260 seconds]
mborzecki has quit [Ping timeout: 265 seconds]
haroon-m[m] has quit [Ping timeout: 256 seconds]
jackos888[m] has quit [Ping timeout: 256 seconds]
kiwi_29_[m] has quit [Ping timeout: 265 seconds]
Salamandar has quit [Ping timeout: 252 seconds]
rber|res has quit [Remote host closed the connection]
ZolaLosonszky[m] has quit [Ping timeout: 256 seconds]
phako[m] has quit [Ping timeout: 246 seconds]
argonautx[m] has quit [Ping timeout: 248 seconds]
swedishhat[m] has quit [Ping timeout: 248 seconds]
patersonc[m] has quit [Ping timeout: 246 seconds]
barath has quit [Ping timeout: 246 seconds]
falk0n[m] has quit [Ping timeout: 265 seconds]
glgspg[m] has quit [Ping timeout: 260 seconds]
lrusak[m] has quit [Ping timeout: 260 seconds]
agherzan has quit [Ping timeout: 260 seconds]
T_UNIX[m] has quit [Ping timeout: 264 seconds]
FredericOuellet[ has quit [Ping timeout: 256 seconds]
mrybczyn[m] has quit [Ping timeout: 256 seconds]
shoragan[m] has quit [Ping timeout: 246 seconds]
nemik_ has quit [Ping timeout: 255 seconds]
zyga[m] has quit [Ping timeout: 265 seconds]
danielt has quit [Ping timeout: 260 seconds]
jclsn[m] has quit [Ping timeout: 256 seconds]
Cir0X[m] has quit [Ping timeout: 248 seconds]
nemik_ has joined #yocto
ericson2314 has quit [Ping timeout: 260 seconds]
khem has quit [Ping timeout: 265 seconds]
CharlesKwiatkows has quit [Ping timeout: 264 seconds]
phodina[m]1 has quit [Ping timeout: 246 seconds]
manuel1985 has quit [Ping timeout: 252 seconds]
Saur[m] has quit [Ping timeout: 260 seconds]
azcraft has joined #yocto
kmaincent[m] has quit [Ping timeout: 252 seconds]
gstinocher[m] has joined #yocto
Saur[m] has joined #yocto
kmaincent[m] has joined #yocto
ZolaLosonszky[m] has joined #yocto
mborzecki has joined #yocto
manuel1985 has joined #yocto
bitob[m] has joined #yocto
tokamak[m] has joined #yocto
Mickal[m] has joined #yocto
Algotech75 has joined #yocto
jkorsnes[m] has joined #yocto
Algotech75 has quit [Remote host closed the connection]
kayterina[m] has joined #yocto
glgspg[m] has joined #yocto
ThomasRoos[m] has joined #yocto
<rburton>
granjow: fix, don't skip. it's fundamentally broken and you're lucky the build works.
Tartarus1 has joined #yocto
<rburton>
granjow: neon ships a pkgconfig file so the configure script should just be doing PKG_CHECK_FLAGS(NEON, neon)
esben[m] has joined #yocto
falk0n[m] has joined #yocto
jackos888[m] has joined #yocto
ejoerns[m] has joined #yocto
perceval[m] has joined #yocto
FredericOuellet[ has joined #yocto
haroon-m[m] has joined #yocto
barath has joined #yocto
thekappe has joined #yocto
swedishhat[m] has joined #yocto
zyga[m] has joined #yocto
<thekappe>
Hello guys ! I have recipe A that ships "A-mylib-dev" which has some header files needed by recipe "B". In recipe B I've added DEPENDS += "A-mylib-dev" but bitbake complains that "nothing PROVIDES A-mylib-dev but B.bb DEPENDS on or otherwise requires it . Close matches: A RPROVIDES A-mylib-dev. How can I solve this issue ?
<JaMa>
"A" should be in DEPENDS not A-mylib-dev
thekappe has quit [Quit: Client closed]
thekappe has joined #yocto
<thekappe>
JaMa, thanks, I'll try it !
patersonc[m] has joined #yocto
prabhakarlad has quit [Quit: Client closed]
hmw[m] has joined #yocto
lrusak[m] has joined #yocto
kiwi_29_[m] has joined #yocto
ericson2314 has joined #yocto
jclsn[m] has joined #yocto
agherzan has joined #yocto
argonautx[m] has joined #yocto
shoragan[m] has joined #yocto
mrybczyn[m] has joined #yocto
phako[m] has joined #yocto
seninha has quit [Quit: Leaving]
Salamandar has joined #yocto
seninha has joined #yocto
danielt has joined #yocto
Cir0X[m] has joined #yocto
khem has joined #yocto
<granjow>
rburton: Agree, but I don't even need/want neon ;) Found out that it was not the actual problem, but some compiler flags set elsewhere. (Maybe neon would become a problem once I enable it in PACKAGECONFIG.)
<rli>
bb.BBHandledException: Execution of 'git describe --always --dirty --tags' failed with exit code 128:
<rli>
abort()ing pseudo client by server request.
<rli>
But if I define the variable in bitbake/conf/bitbake.conf then everything works as expected. I'd like to keep my changes to my own repos but can't figure out what is happening. Any ideas?
Poppy has joined #yocto
<Poppy>
I have some trouble to use encrypted password for users. A recipe inherit useradd and use mkpasswd generate sha-256 password, put in varibale and call useradd command with -p "password_hash". But sometimes the generated password contains "$" special char and the password is not correctly set. There is a syntaxe tip to avoird this kind of issue ?
florian_kc has quit [Ping timeout: 246 seconds]
florian_kc has joined #yocto
Poppy has quit [Quit: Client closed]
sakoman has joined #yocto
olani has joined #yocto
thekappe has quit [Ping timeout: 260 seconds]
prabhakarlad has joined #yocto
demirok has quit [Quit: Leaving.]
azcraft has quit [Remote host closed the connection]
azcraft has joined #yocto
<RP>
JPEW: this is quite the voyage of discovery :/
<JPEW>
RP: running events in parallel?
<RP>
JPEW: We're discovering much of our existing locking code is just plain wrong/scary
<RP>
JPEW: I was wrong yesterday btw - parsing is already an async task so we don't need to convert it!
<JPEW>
RP: ah that's nice at least
<granjow>
If something needs /sbin/sh, how can I find out which recipe provides it so I can RDEPEND on it?
<JPEW>
RP: ya in my experience, correct locking is hard, especially on an evolving codebase
<RP>
JPEW: right. I still don't think we're too far off having this work but the patch I just sent to event.py explains a lot!
<JPEW>
Python doesn't help either sometimes, because the GIL hides problems, until it doesn't
* JPEW
looks
<RP>
JPEW: the enable/disable block in sstate.bbclass was just disabling the locking :)
<JPEW>
Lockin'? We don't need no stinking lockin'
<JPEW>
Ah you switched to using "with". Very good
<RP>
JPEW: I was slightly surprised when I realised it was simply turning it off :)
<RP>
JPEW: I'm doing my best to try and write better python!
<JPEW>
I think my code reviews are feared at work, but I'm never sure how pedantic to get on the OSS stuff :)
<RP>
JPEW: I think it depends what the code is. In bitbake core we do need to be careful
<RP>
JPEW: given the number of people who'll even touch bitbake, I just have to do the best I can
* RP
hates having to debug this by using the autobuilder
<JPEW>
Ya not locking in that function is all sorts of wrong. I wonder why it was allowed in the first place?
rli has quit [Quit: Client closed]
florian_kc has quit [Ping timeout: 260 seconds]
<JPEW>
Maybe just unnecessary because there was less parallelism?
<RP>
JPEW: it was never necessary when we just had a single thread. The enable/disable was due to threading use in sstate.bbclass
xmn has joined #yocto
kscherer has joined #yocto
Muerre has joined #yocto
zhmylove has quit [Remote host closed the connection]
azcraft has quit [Read error: Connection reset by peer]
florian_kc has joined #yocto
demirok has joined #yocto
azcraft has joined #yocto
seninha has quit [Remote host closed the connection]
seninha has joined #yocto
olani has quit [Remote host closed the connection]
granjow has left #yocto [#yocto]
Starfoxxes has quit [Ping timeout: 265 seconds]
<abelloni>
AntA: this is building core-image-minimal core-image-full-cmdline core-image-sato-sdk world and word includes rust for the target
<abelloni>
I think this is a use case we want to support
<AntA>
abelloni: "want to support" or "do support"?
<tlwoerner>
we have DISTRO_FEATURES, MACHINE_FEATURES, and IMAGE_FEATURES... what about LAYER_FEATURES?
<abelloni>
I think we are one patch away from having that working
<abelloni>
RP: ^
<tlwoerner>
in a BSP layer, i have 2 use-cases that are looking for elegant solutions
<tlwoerner>
1. user can choose between mainline/upstream vs vendor-forks
<tlwoerner>
2. whether or not your board boots from on-board emmc or sdcard
<tlwoerner>
in essence these are just OVERRIDES
<AntA>
abelloni: then maybe I should wait for that patch. may be it will include correct parameters for x86
<tlwoerner>
what's a good way to expose these choices to the user?
Starfoxxes has joined #yocto
ptsneves has joined #yocto
<RP>
AntA: rust works in world today afaik?
<AntA>
RP: Until today I didn't know that we build rust for target in tests.
<RP>
AntA: we've slowly been fixing it, there are patches on the mailing list adding more tests
<RP>
AntA: it does sound like a discrepancy we need to get to the bottom of. I did wonder if it was related to the code in security_flags.inc and the handling of pie flags
<RP>
AntA: we can probably fix for target, native might be a lot harder
<RP>
we control the target config, we're given the native config from the host distro
<AntA>
RP: if we fix it for x86 target then my patch v3 would pass
<RP>
AntA: what do we need to do to fix x86 target?
ptsneves has quit [Ping timeout: 265 seconds]
<AntA>
RP: good question. I don't know in details. AFAIU as a part of rust build we also build rustc_driver crate which includes a C dependency. Currently without CRATE_CC_NO_DEFAULTS exported this dependency is built (successfully) with C compiler parameters defined by Yocto and by CC crate. When I export CRATE_CC_NO_DEFAULTS for x86 target the build fails. It means Yocto is missing some required C complier parameters and unintentionally relies on CC para
<AntA>
meters. The correct fix would be to identify these missing parameters and define them correctly in Yocto
<RP>
AntA: I'm struggling to see flags in there that would break things :/
<RP>
AntA: actually, I can, it is the -fPIC
prabhakarlad has quit [Quit: Client closed]
<AntA>
RP: it's other way around - there are flags there which are required and are missing in Yocto (in rust-target-config.bbclass AFAIU)
<AntA>
RP: and for arm32 targets there are flags there which conflict with Yocto flags for the platform. This is where it's all started
<RP>
AntA: What I mean is that security_flags.inc is where the project tries to force PIE code so I suspect that class is probably the cause of making this work or break and it isn't really an arm vx x86 issue
<RP>
AntA: which DISTRO setting are you testing locally with and does it use security_flags.inc ?
invalidopcode has quit [Remote host closed the connection]
invalidopcode has joined #yocto
Tokamak_ has joined #yocto
<RP>
AntA: How are you testing this? Or are you just relying on your CI with no local testing?
leon-anavi has quit [Remote host closed the connection]
<AntA>
RP: I build core-image-base for different types of machines with parsec-service recipe included (from meta-parsec which is a sub-layer of meta-security)
<RP>
AntA: with which DISTRO?
<AntA>
poky
<RP>
AntA: and can you reproduce the x86 failure locally?
<AntA>
RP: yep. `MACHINE=qemux86 bitbake rust` would fail for me with my patch v3. and `MACHINE=qemuarm bitbake parse-service` would fail without a fix
<RP>
AntA: what does qemuarm64 do?
<AntA>
RP: pass
<RP>
AntA: I suspect it might have the same PIE failure with your fix
<AntA>
RP: my fix simply says to CC crate "do not add your default C compiler parameters, use the one we defined".
<RP>
AntA: right, but where does aarch64 define PIE ?
<RP>
AntA: I guess the compiler defaults may be different but that would be a little surprising
<AntA>
RP: I know nothing about PIE. I know that for arm32 CC parameters conflict with Yocto parameters. for other platform they do not. and for x86 platfrom Yocto parameters are not sufficient to build C dependencies for rust crates. For other platforms they are sufficient
alessioigor has quit [Quit: alessioigor]
<AntA>
RP: and I think Yocto way is to define all parameters for all platforms and not rely third party crates. i.e CRATE_CC_NO_DEFAULTS should be exported for all targets
zpfvo has quit [Quit: Leaving.]
<RP>
AntA: I'm trying to help you understand the problem so that you might be able to fix it
<RP>
AntA: I don't really have the time to dive into the details on this and run builds to figure out exactly what is happening
<AntA>
RP: I understand. What I don't understand is why you think PIE is related
<RP>
AntA: I suspect that when you add CRATE_CC_NO_DEFAULTS, it disables the code you linked to which has cmd.push_cc_arg("-fPIC".into());
<RP>
AntA: I'm worried why qemuarm64 would work when qemux86-64 fails as both should behave the same
<RP>
AntA: We unconditionally enable PIE so adding some flags to hardcode it is probably ok. THere is a small problem that there are some patches queued which enable rust for baremetal which the PIE change will break though
florian_kc has quit [Ping timeout: 260 seconds]
<AntA>
RP: and arm32 works with the patch as well as arm64
<RP>
AntA: which makes me wonder if PIE isn't the default on x86 or something...
<RP>
AntA: at this point my knowlege runs out :(
<AntA>
RP: my knowledge in this area run out long time ago :)
frieder has quit [Remote host closed the connection]
<khem>
RP: cc-rs is limited and hardcodes defaults which is not useful if we are setting tune options elsewhere, Its perhaps better to nullify smartness that cc-rs has
<khem>
from the compile logs I see our LDFLAGS are missing when build-rust-ccld wrapper is called to link the library
<khem>
since we pass vital parameters via TOOLCHAIN_OPTIONS its not norm in rest of systems. compiler itself is compiled with right defaults
Tokamak_ has joined #yocto
<khem>
so these kind of wrappers unknowingly rely on those defaults sadly
<khem>
I guess setting CRATE_CC_NO_DEFAULTS for cross builds is perhaps best we can do
<AntA>
kmem: exactly. but why cross builds only?
<khem>
native still uses native compiler and options
<khem>
so it will work ok
<AntA>
khem: yes, but now we have a problem with building target rust when target is x86
<khem>
this is x86/musl, can you see it failing in same way with x86/glibc ?
<AntA>
kmem: it looks like when we export CRATE_CC_NO_DEFAULTS we miss fPIC which is required for building dynamic libraries on x86
<AntA>
kmem: yes, my manual builds fail with the same errors with glibs
<RP>
AntA: I'm fuzzy on which flag we need to include where exactly, I was just trying to show how I'd start looking at fixing it
paulg has quit [Quit: Leaving]
goliath has joined #yocto
goliath has quit [Client Quit]
<AntA>
RP: OK, I thought you're planning to submit your change with PIE
<RP>
AntA: no, I just shared the patch to give an idea of what I was thinking
<RP>
AntA: I have some memory that we use these flags (from security_flags.inc) for some reason instead of -fPIC
<AntA>
RP: AFAIU PIE is for executable and PIC is for dynamic libraries. So, in our rust wrappers case we need the latter. The question is when to apply it. It's platform specific and shouldn't be used unconditionally. I'm searching for examples how it's used in other places
<RP>
AntA: we can pass -pie in all cases I think
<RP>
JPEW: at least one more obvious race and some other more worrying/puzzling logic error failures :(
seninha has quit [Remote host closed the connection]
kalj has joined #yocto
<RP>
JPEW: I'll fix the obvious issue and retry, the other bits don't make sense
mvlad has quit [Remote host closed the connection]
Tokamak_ has joined #yocto
shota has joined #yocto
camus has quit [Remote host closed the connection]
camus has joined #yocto
<shota>
Hello, I vaguely remember reading somewhere that there is a potential race that can cause setscene to fail when multiple bitbake jobs are running in parallel. Am I misremembering?
Tokamak_ has quit [Ping timeout: 255 seconds]
Tokamak_ has joined #yocto
shota has quit [Ping timeout: 260 seconds]
shota has joined #yocto
florian_kc has quit [Ping timeout: 252 seconds]
xmn has quit [Ping timeout: 246 seconds]
florian_kc has joined #yocto
xmn has joined #yocto
azcraft has quit [Read error: Connection reset by peer]
<RP>
shota: I suspect you might be thinking of when some sstate object is deleted while a build is running?
<shota>
yes. it is an intermittent failure in our build system where siginfo file appears to be missing when multiple bitbake jobs are running in parallel.
<RP>
shota: are you running cleanall or cleansstate tasks anywhere?
sakoman has quit [Quit: Leaving.]
<shota>
Not to my knowledge
<RP>
shota: something must be removing the siginfo file :/
kscherer has quit [Quit: Konversation terminated!]