<g-embed>
ArgaKhan___, there was another error before aclocal failed to find m4macros.
<g-embed>
""ln: failed to create symbolic link '/media/tunahan... /work/armv7vet2hf-neon-mepos-linux-gnueabi/imsettings/1.8.3-r0/imsettings-1.8.3/m4macros/': No such file or directory" I would start looking at that one.
zpfvo has joined #yocto
<ArgaKhan___>
yes, I searched where it said and there really is no such file or folder. I don't understand why? Or why is he looking there. I pulled the kirkston branch from github and used it, I didn't make any extra settings, it's related to imsettings.
mckoan|away has joined #yocto
<ArgaKhan___>
g-embed
<g-embed>
Followed by "Not a directory". Look into work. Do the parent directories exist? armv7vet2hf-neon-mepos-linux-gnueabi/imsettings/1.8.3-r0/imsettings-1.8.3 ? If not, why not?
<g-embed>
Some version mixup? Is there a directory under work indicating a different version than 1.8.3-r0?
<ArgaKhan___>
yes there is a parent directory only m4macros is not there.
<g-embed>
OK I'm just brainstorming here. If kirkstone fails without any changes I guess it's for the real devs to answer.
<g-embed>
You could try a tagged version, or look at git log if something was recently modified. I don't know more about it.
mckoan_ has quit [Ping timeout: 264 seconds]
<ArgaKhan___>
All right, thanks anyway. I checked Github, but I couldn't see anything different about this issue. Maybe there is something I've overlooked.
<ArgaKhan___>
LetoThe2ndo: yes, this is the package but the kirkstone version.
seninha has quit [Remote host closed the connection]
<LetoThe2nd>
ArgaKhan___: let me check. i guess for raspi?
behanw has quit [Quit: Connection closed for inactivity]
sgw has joined #yocto
<ldericher>
I have foo_1.0.bb which is compatible with "arm" targets only, and foo_1.1.bb which is compatible with "aarch64" targets only. How can I express this in the recipes?
<ldericher>
I tried setting COMPATIBLE_MACHINE to "arm" and "aarch64" respectively, but when I try and compile my image for aarch64, it still creates a warning, as tries to find source for "foo_1.0.bb" (which doesn't exist, as 1.0 doesn't work for aarch64)
<ldericher>
specifically, it fails to find "foo_1.0_aarch64.tar.gz" in the "files/" subdir. But it shouldn't consider foo_1.0 in the first place, as it is not compatible with "aarch64". What am I missing?
<mcfrisk>
ldericher: it's a regular expression into MACHINEOVERRIDES, so you may need to check how that resolved in various build targets, and if aarch64 is including also some variants of arm, like arm64
<ldericher>
mcfrisk, maybe I should use another approach - can I select the correct version in my image recipe, depending on the current arch?
<ldericher>
mcfrisk, (how) can I display the contents of MACHINEOVERRIDES variable?
<ldericher>
LetoThe2nd, I don't have bitbake-getvar :(
<LetoThe2nd>
ldericher: why?
<ldericher>
How would I know? \o/
<LetoThe2nd>
ldericher: which release are you on?
<ldericher>
hardknott
<LetoThe2nd>
ldericher: ... which is EOL.
<ldericher>
LetoThe2nd, ... which I can't do much about, since manufacturer hasn't come up with a newer release yet.
<mcfrisk>
ldericher: common but sadly bad excuse. It is possible to upgrade the open source yocto things while keeping BSP SW side tied to an older release. Hard work though. Good luck!
* LetoThe2nd
resisted the urge for the usual hints, but in the end is - choose your vendor wisely. or kick them hard.
GillesM has joined #yocto
<ldericher>
mcfrisk, LetoThe2nd, true - but 1) switching the vendor is not a good option at this point, and 2) creating such a "mixed" release is on the roadmap, but definitely not the first step to solving the issues at hand.
kanavin_ has quit [Remote host closed the connection]
<mcfrisk>
ldericher: you seem to be on the right track then! Mixed releases are easier once ownership and delivery chain for the whole product and all its sub components are clear. The BSP vendors influence can be limited to the SW component tied to the HW, like bootloader, firmware and kernel. Above that sits possibly complex but really HW independent open source SW stack which should be maintained by someone,
* LetoThe2nd
shrugs.
<mcfrisk>
preferably with ties to the upstream community
kanavin has joined #yocto
<ArgaKhan___>
LetoThe2nd: Sorry, it was lunchtime. Yes, you can think of it like raspi, I'm compiling for armhf.
<LetoThe2nd>
k
malsyned has joined #yocto
florian_kc has joined #yocto
malsyned has quit [Ping timeout: 260 seconds]
leon-anavi has joined #yocto
starblue has quit [Ping timeout: 248 seconds]
starblue has joined #yocto
sgw has quit [Quit: Leaving.]
vladest has joined #yocto
sgw has joined #yocto
sgw has quit [Ping timeout: 260 seconds]
manuel1985 has joined #yocto
nemik_ has quit [Ping timeout: 252 seconds]
nemik_ has joined #yocto
nemik_ has quit [Ping timeout: 268 seconds]
nemik_ has joined #yocto
goliath has joined #yocto
<ArgaKhan___>
LetoThe2nd: Is there any progress?
<LetoThe2nd>
ArgaKhan___: build progressing.
<ArgaKhan___>
oh, okay
<g-embed>
vendors... let's not get started. I'm struggling with a zeus(!) BSP here!
<g-embed>
I'm not kidding.
rob_w has joined #yocto
<rburton>
g-embed: have you considered making your own bsp by porting the good pieces to modern systems?
<phako[m]>
waves at g-embed is it a certain fpga-based BSP?
<ldericher>
(how) can I use if statements in a bb file?
<rburton>
ldericher: can you explain more what you want to do
<ldericher>
if $HOST_ARCH is "value1", I want VARIABLE_${PN}="foo", else "bar"
<rburton>
use overrides
<rburton>
VAR="bar"
<rburton>
VAR:value1 = "foo"
<ldericher>
so does this work with VAR_${PN}="bar" as well I assume?
<ldericher>
like VAR_${PN}:value1
<mcfrisk>
g-embed: zeus based BSP layer can quite easily work with dunfell poky, meta-openembedded etc. BBMASK all unused things away and fix remaining issues in a local branch.
<ldericher>
rburton, I came up with `VAR_${PN} = "${HOST_ARCH}"; VAR_${PN}:aarch64 = "arm64"; (...); ANOTHER_VAR_${PN} = "var is ${VAR_${PN}}.";` where ; is newline. Does this look remotely sane?
<rburton>
no, use overrides
<rburton>
oh sorry can't ready
<rburton>
yes
<rburton>
you can use bitbake-getvar to see what things evaluate too fwiw
<ldericher>
well that is if you're not stuck on hardknott for the time being :D
xmn has joined #yocto
<g-embed>
rburton, like ldericher I need to first "make things work", then most likely upgrades. Get the customer's requested functionality in place.
<g-embed>
But yes, struggling with patches on patches on the kernel now, and considering replacing it instead.
<g-embed>
mcfrisk, thanks, will consider
<ric96>
Hi, needed some help with installing a custom library. Currently the issue is that i need to manually run ldconfig on first boot to get the library to load, how do i make it a part of the recipe?
<rburton>
ric96: top tip would be to write a proper makefile/meson/whatever so your recipe doesn't need to do that
brabander has joined #yocto
guest2345 has joined #yocto
guest2345 has left #yocto [#yocto]
sgw has joined #yocto
<g-embed>
So... maybe a dumb question but some kernel source ends up in work, some in work-shared? I've read the docs but it is very brief: "For efficiency... hold recipes that share a work directory with other recipes". But for a kernel recipe, what goes where, and why, more exactly?
GNUmoon has quit [Ping timeout: 255 seconds]
<ric96>
rburton: i agree, this is just a temporary setup. any quick fix?
<g-embed>
Generally struggling to a bit understand which files are really being used in the kernel build.
<rburton>
ric96: i'd have to see the recipe entirely, as the default postinst generated should include a ldconfig call
<LetoThe2nd>
ArgaKhan___: built perfectly for me. a fresh rpi setup, added meta-gnome and meta-xfce, then bitbake imsettings.
florian_kc has quit [Ping timeout: 260 seconds]
<LetoThe2nd>
ArgaKhan___: so chances are your build setup breaks something.
<ArgaKhan___>
Maybe the mistakes I got before broke something. I got quite a bug and as I solved it, I bitbaked again.
sakoman has joined #yocto
<ArgaKhan___>
LetoThe2nd: for a clean bibake from scratch, should i run the command "bitbake cleanall" or should i delete the tmp?
<LetoThe2nd>
ArgaKhan___: i had an empty tmp.
<ArgaKhan___>
LetoThe2nd: I'll empty the tmp then. but it takes about 2 days since i have more buil. If it's finished, I'll write it here. Thank you.
<LetoThe2nd>
ArgaKhan___: i personally wouldn't bet on it solving the problem for you, sorry. my build just was meant to verify the recipe does not in itself have a direct problem.
<ArgaKhan___>
LetoThe2nd: But I didn't change anything about imsettings or meta-xfce. I got the errors in meta-qt5. and I moved on by solving them. I can't think of anything else right now.
<LetoThe2nd>
ArgaKhan___: my gut feeling is that something in your build is off. if i had to guess, then the bsp.
zpfvo has quit [Ping timeout: 252 seconds]
<ArgaKhan___>
LetoThe2nd: Can we identify what is missing?
<LetoThe2nd>
ArgaKhan___: try to build your application stack for a known good board like qemuarm64, or as raspberrypi. if it works then, your bsp is probably the guilty one.
<ArgaKhan___>
LetoThe2nd: OK, I'll try, but this process will probably take 2 days. There's a lot to compile
<LetoThe2nd>
ArgaKhan___: get a faster box.
<ArgaKhan___>
:D i wish
randomdude has joined #yocto
<randomdude>
hello
<rburton>
moto-timo: i think we can switch to pypa/build...
<rburton>
just testing a branch now
randomdude has quit [Client Quit]
zpfvo has joined #yocto
kpo has quit [Read error: Connection reset by peer]
kpo has joined #yocto
rob_w has quit [Remote host closed the connection]
<RP>
JPEW: I did push a fix for the addpylib change
<JPEW>
I saw that
<RP>
JPEW: I figured you wouldn't mind ;-)
<JPEW>
nope
<RP>
(I did test it)
florian has quit [Quit: Ex-Chat]
<rburton>
moto-timo: success!
gsalazar has quit [Remote host closed the connection]
<rburton>
oh ffs the moment i say that a build explodes
<rburton>
RP: i'm upset at how bitbake handles native DEPENDS/RDEPENDS again
gsalazar has joined #yocto
<moto-timo>
rburton: cursed!
<RP>
rburton: I did try and start changing that
<rburton>
i'm sure its a bloody maze
<RP>
rburton: the challenge is that we clear PACKAGES
<RP>
rburton: which element is upsetting you in particular?
<RP>
rburton: another challenge is that some PACKAGES don't get generated until build time so how could we possibly know the RDEPENDS actually exists without iterating the datastore?
<RP>
and even if we do that, it might not be enabled
<rburton>
yeah anyway i think this was my fault
<rburton>
fingers crossed
kpo has quit [Read error: Connection reset by peer]
Tokamak_ has joined #yocto
<rburton>
moto-timo: poky-contrib:ross/pybuild
<rburton>
going to let it simmer in my head for another day
<moto-timo>
rburton: that looks promising!
kpo has joined #yocto
PhoenixMage has quit [Ping timeout: 256 seconds]
Tokamak_ has quit [Ping timeout: 255 seconds]
PhoenixMage has joined #yocto
malsyned has joined #yocto
goliath has joined #yocto
seninha has quit [Ping timeout: 255 seconds]
invalidopcode has quit [Remote host closed the connection]
invalidopcode has joined #yocto
PhoenixMage has quit [Ping timeout: 246 seconds]
PhoenixMage has joined #yocto
<rburton>
moto-timo: i'm thinking about writing a ptest plugin for pytest again. it shouldn't be *too* difficult to reformat the output to match what ptest wants.
<moto-timo>
rburton: totally understand that conclusion1
<rburton>
then we just add a subpackage to pytest itself with the plugin and a wrapper script
Tokamak_ has joined #yocto
PhoenixMage has quit [Ping timeout: 268 seconds]
PhoenixMage has joined #yocto
* moto-timo
wonders if we could do something similar for perl...
goliath has quit [Quit: SIGSEGV]
<moto-timo>
Anybody have hints about: configuration error - unknown item 'SYSLOG_S{U,G}_ENAB' (notify administrator) failure for usermod during do_rootfs?
<rburton>
moto-timo: perl should be easier as it has a single standard test suite essentially
<kiwi_29_[m]>
Hello... I upgraded GO compiler in my yocto dunfell from default 1.14 .....(available as part of standard poky meta/recipes-devtools/go) to 1.19 by copying go 1.19 recipes available in langdale to my customlayer . When I used to generate sdk using. bitbake -c populate_sdk DISTRO_NAME before go upgrade, it used to include go compiler version 1.14. After upgrading to go 1.19, I m not getting any go version inside sdk
<kiwi_29_[m]>
I do see some code related to this in meta/recipes-core/meta/meta-go-toolchain.bb , but I am not sure how to use it to include go 1.19 in the sdk
Tokamak_ has quit [Quit: Tokamak_]
<moto-timo>
ok, so it was `INHERIT += "extrausers"` (bad) vs. `IMAGE_CLASSES += "extrausers"` (good)
<kiwi_29_[m]>
* I do see some code related to this in meta/recipes-core/meta/meta-go-toolchain.bb , but I am not sure how to use it to include go 1.19 in the sdk
<kiwi_29_[m]>
I m wondering how was this recipe included previously when I compiled toolchain using bitbake -c populate_sdk DISTRO_NAME
<moto-timo>
(the SUDO_SU_ENAB was a red herring)
<JPEW>
RP: I've jpew/extra-siggen branch on master
malsyned has quit [Ping timeout: 260 seconds]
Tokamak_ has joined #yocto
<rburton>
moto-timo: ok ross/pybuild is, i think, ready. \o/
<moto-timo>
\o/
<moto-timo>
dreams do come true
malsyned has joined #yocto
dgriego has quit [Read error: Connection reset by peer]
dgriego has joined #yocto
malsyned has quit [Ping timeout: 248 seconds]
malsyned has joined #yocto
florian_kc has quit [Quit: Ex-Chat]
kpo has quit [Read error: Connection reset by peer]