khem has quit [Quit: Connection closed for inactivity]
davidinux has quit [Ping timeout: 255 seconds]
davidinux has joined #yocto
starblue has quit [Ping timeout: 268 seconds]
starblue has joined #yocto
ablu has quit [Ping timeout: 260 seconds]
ablu has joined #yocto
DaveNuge has quit [Ping timeout: 260 seconds]
LocutusOfBorg has quit [Read error: Connection reset by peer]
amitk has joined #yocto
lthadeus has joined #yocto
LocutusOfBorg has joined #yocto
Vonter has quit [Ping timeout: 240 seconds]
Vonter has joined #yocto
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #yocto
Vonter has quit [Ping timeout: 245 seconds]
Vonter has joined #yocto
alessioigor has joined #yocto
khem has joined #yocto
wooosaiiii has quit [Ping timeout: 260 seconds]
wooosaiiii has joined #yocto
rob_w has joined #yocto
wooosaiiii has quit [Quit: wooosaiiii]
lthadeus has quit [Ping timeout: 240 seconds]
linfax has joined #yocto
linfax has quit [Remote host closed the connection]
lthadeus has joined #yocto
goliath has joined #yocto
mort8 has joined #yocto
rfuentess has joined #yocto
mort has quit [Read error: Connection reset by peer]
mort8 is now known as mort
mattsm has quit [Ping timeout: 276 seconds]
mattsm has joined #yocto
Saur has quit [Ping timeout: 276 seconds]
Saur has joined #yocto
Kubu_work has joined #yocto
roussinm has quit [Quit: WeeChat 3.8]
tnovotny has joined #yocto
lthadeus has quit [Ping timeout: 260 seconds]
wooosaiiii has joined #yocto
Dane86 has joined #yocto
<Dane86>
Hello! Any pointers on where to get help regarding OSTree implementation on a custom board?
<Dane86>
I have everything building but the 'var' dir is not getting linked and I'm not sure why yet.
<Dane86>
(meta-updater layer)
DaveNuge has joined #yocto
thomas_34 has joined #yocto
<thomas_34>
Good morning, during building an image I got this warning and error from bitbake: https://pastebin.com/2ycRf0F6
<thomas_34>
I try to track down the root issue, but I'm lacking knowledge of that Manifest file which seems missing. Can someone direct me in the right direction what actually that file represents in that context, and why it could miss here?
DaveNuge has quit [Ping timeout: 240 seconds]
mckoan|away is now known as mckoan
florian_kc has joined #yocto
<LetoThe2nd>
yo dudX
radanter has joined #yocto
tnovotny has quit [Quit: Leaving]
<mckoan>
LetoThe2nd: hi
<rburton>
thomas_34: odd that its talking about nativesdk packages when you're building an image, or are you building a SDK?
<thomas_34>
rburton thanks for jumping in. I think I found the root issue to that problem: The task "do_create_srcipk" was disabled in that recipe. Once I enabled that, in /deploy/ipk the
<thomas_34>
* package of that recipe showed up and now the image is also building
<rburton>
you're building a sdk right though?
<thomas_34>
But I would have another question, which directs in that kind of area you mentioned rburton
<thomas_34>
No, I build a target image. But that recipe uses a external toolchain to produce an ELF-file which gets deployed on that image.
<thomas_34>
And that leads to my second question. I have another recipe which uses another external toolchain, to produce an ELF file which gets deployed on that image. However, the processor architecture of that ELF file is different to the target arch. So Sane-Class warned me about that, what makes sense of course.
<thomas_34>
I disabled this step via "INSANE_SKIP:${PN} += "arch"" in that recipe.
<thomas_34>
I wonder if that is the correct approach to do that, or are there better ways, to deploy a executable on a image, but which is not for the target architecture compiled. (?)
<rburton>
that's the right thing to do. the better solution is a complete second BSP for the second processor but that's a lot of effort for what is presumably firmware running on a second core.
<thomas_34>
Alright. So in my scenario I have 15 cores, with 4 different architectures in one system. One of them is a A72 (AArch64) which runs the yocto image. And on that image are also all other firmware the other 14 cores.
<rburton>
FIFTEEN
<rburton>
FOUR
<rburton>
well that's just madness but fine
frieder has joined #yocto
<thomas_34>
And the linux kernel is used to load and run all the other firmwares on the cores.
<rburton>
i point you at meta-arm which might have useful recipes for the arm firmware, if you're not already using it
<thomas_34>
rburton yes, its a SoC from TI I have to work with. But I'm glad that a yocto expert approved my INSANE_SKIP approach here :)
<rburton>
if the firmware ends up as a blob in the linux file system then insane_skip is the right thing. linux-firmware does the same as some of the firmware it packages triggers the same test.
<thomas_34>
Okay cool. I'll have a look at these meta-arm recipes. Currently I work with what TI provides me, which is arago...
lthadeus has joined #yocto
<rburton>
latest meta-ti uses meta-arm, but i guess that depends on what version of meta-ti you use
khem has quit [Quit: Connection closed for inactivity]
leon-anavi has joined #yocto
<thomas_34>
Ok, honestly I didnt had the capacity yet to fully understand how TI uses yocto for their products. But I'm right about now to update to the latest state, which makes me happy, because I can now use finally kirkstone instead of dunkirk.
<thomas_34>
*latest meta-ti state*
florian has joined #yocto
xmn has quit [Quit: ZZZzzz…]
mvlad has joined #yocto
prabhakarlad has joined #yocto
prabhakar has joined #yocto
mbulut has joined #yocto
florian_kc has joined #yocto
mros has joined #yocto
mros has quit [Client Quit]
starblue has quit [Ping timeout: 256 seconds]
starblue has joined #yocto
jmiehe has joined #yocto
mckoan is now known as mckoan|away
paulg has quit [Ping timeout: 240 seconds]
paulg has joined #yocto
jmiehe has quit [Quit: jmiehe]
linfax has joined #yocto
jmiehe has joined #yocto
jmiehe has quit [Client Quit]
Dane86 has quit [Quit: Client closed]
lthadeus has quit [Ping timeout: 245 seconds]
Daanct12 has quit [Quit: WeeChat 4.1.2]
<kanavin>
halstead, I think there's a mismatch between cdn and autobuilder cache:
<kanavin>
but /srv/autobuilder/autobuilder.yocto.io/pub/sstate/universal/2d/29/sstate:go-cross-cortexa57:x86_64-poky-linux:1.20.12:r0:x86_64:11:2d291879552b44a099c36e9e85358f703a8b8d8c2c0c2b876a0c7a339844f64b_populate_sysroot.tar.zst does not
<jdiez>
hi! I built a yocto image for an i.mx8 board with `EXTRA_IMAGE_FEATURES += "package-management"` and `PACKAGE_CLASSES = "package_rpm"`. However, I am having some issues trying to update packages at runtime.
<jdiez>
`rpm -U mypackage.rpm` errors out saying: error: Couldn't create temporary file for %prein(base-files-3.0.14-r90.phyboard_pollux_imx8mp_3): File exists
<jdiez>
and any `dnf` commands simply error out saying "Config error: [Errno 17] File exists: '/var/log': '/var/log'"
<jdiez>
any ideas?
joekale has joined #yocto
florian_kc has quit [Ping timeout: 245 seconds]
Xagen has quit [Ping timeout: 245 seconds]
<jdiez>
figured out at least the dnf issue. `/var/log` is a symlink to `/var/volatile/log`, and that directory didn't exist (but `/var/volatile` did)
olani- has joined #yocto
olani_ has joined #yocto
lthadeus has joined #yocto
xmn has joined #yocto
rob_w has quit [Remote host closed the connection]
olani_ has quit [Remote host closed the connection]
olani- has quit [Remote host closed the connection]
LocutusOfBorg has quit [Read error: Connection reset by peer]
<ablu>
"nothing provides libc6 >= 2.38+git1+750a45a783 needed by..." What may be triggering the "git1" here? It is "git0" in the repo directory but some bits coming from my sstate apparently want a "git1"?
Minvera has joined #yocto
Xagen has joined #yocto
DaveNuge has joined #yocto
|Xagen has joined #yocto
xmn has quit [Read error: Connection reset by peer]
dgriego has quit [Quit: Bye]
Xagen has quit [Ping timeout: 256 seconds]
lthadeus has joined #yocto
dgriego has joined #yocto
alessioigor has quit [Quit: alessioigor]
RobW has joined #yocto
alessioigor has joined #yocto
rcw has quit [Ping timeout: 268 seconds]
lthadeus has quit [Quit: Leaving]
rfuentess has quit [Remote host closed the connection]
<rburton>
yocton: i had a quick look at strace and it still wants the bluez headers. i'd endorse just deleting the PACKAGECONFIG:class-target line in strace
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<yocton>
rburton: I've arrived at the same conclusion
khem has joined #yocto
<rburton>
yocton: i was just writing in the bug but you beat me to it :)
<yocton>
rburton: hey :) Your comment is already written ;)
drkhsh has quit [Ping timeout: 240 seconds]
drkhsh has joined #yocto
Kubu_work has quit [Quit: Leaving.]
prabhakarlad has quit [Ping timeout: 250 seconds]
<moto-timo>
thank you reatmon
prabhakar has quit [Ping timeout: 268 seconds]
frieder has quit [Remote host closed the connection]
radanter has quit [Remote host closed the connection]
<rburton>
a friendly rust-knowing colleague points out that all of that non-reproducibility in rust is constrained to a single crate, compiler-builtins, which isn't pure rust
<rburton>
(links to libm for example)
<khem>
I looked at the diffoscope output just now, the difference it due to objects being names differently, and the different name is due to hash of .o being computed and added to name of .o
<khem>
so it seems those builtins are being compiled differently
<khem>
in two different runs
<khem>
adding hash to .o names is their way of re-using objects in incremental builds
<khem>
the compiler-builtins crate seems to be inspired by compiler-rt to me from quick look
<khem>
is their some asm code I wonder
<khem>
because that can add absolute paths to source file into final elf
<khem>
if someone could point me to the two build directories I can take a quick look in the .o files
<khem>
and see whats going on
mbulut has quit [Ping timeout: 255 seconds]
TinyTim is now known as Ebeneezer_Smooge
<moto-timo>
gah. sometimes we fail to fetch the expected crate version... maybe there are mirrors for crates.io that aren't in sync? (in this case it was base64)
<moto-timo>
makes it hard to know what is working and not... ArchLinux maturin build recently failed for similar reason (couldn't fetch 'anyhow' crate)
flom84 has quit [Quit: Leaving]
xmn has joined #yocto
florian_kc has joined #yocto
<moto-timo>
ArchLinux packager for maturin suggests disabling the debug build for repro perhaps...
<khem>
we are building it and thats where the issue is
<khem>
my guess is that we need to pass the mapping flags that we pass to C/C++ compiler in OE by default
<moto-timo>
for rust 1.74?
<khem>
because underneath its calling C compiler to build some of the intrinsics
<khem>
yes
<khem>
problem with maturin is different though
* moto-timo
still trying to ramp my head on the lower level rust issues
<khem>
again it could be somewhat related in nature provided how bzip-sys is being built
<moto-timo>
maturin _looks_ like it is the bzip2-sys crate being bad (injecting build or source paths into the debug)... although I am not sure that is the only problem with repo
<moto-timo>
s/repo/repro/
florian_kc is now known as florian
<moto-timo>
bzip2-sys is definitely an older style of crate... libgit2-sys is much better looking code
<moto-timo>
(not that I am fluent in Rust by any means)
<khem>
its including some of C as well. So if you have logs how these files are compiled might lead us further in right dir
<moto-timo>
yeah, I started replacing it with submodule and so on... didn't get that far just yet
<khem>
e.g. find how blocksort.c is being compiled in maturin
<moto-timo>
ah
<khem>
extern crate cc;
<khem>
this crate is interesting I wonder if it knows intricacies of cross build systems
<moto-timo>
I noticed ArchLinux is using bzip2 as a DEPENDS, so I was trying that to see if it helps... but then I had the base64 crate fetch/resolution failure. sigh
<moto-timo>
interesting... pbach reported my crates.inc is out of date. lol stupid human tricks.
Chocky has joined #yocto
Guest51 has joined #yocto
<Guest51>
If "inherit autotools" used in a recipe but can get a build successfully even if it not used, is there a purpose here or is it unnecessary?
<Chocky>
It might be inherited by something else. Or it might use some other build method that also works. Or it could be doing a native build, which wouldn't be ideal. You might want to look at the build logs if you want an exact answer
<alperak>
thanks
<alperak>
oops, wrong chat
Haxxa has quit [Quit: Haxxa flies away.]
Haxxa has joined #yocto
mvlad has quit [Remote host closed the connection]
<Guest51>
Chocky thx
Guest51 has quit [Quit: Client closed]
<khem>
Guest51: generally autotools class will encapsulate cross-build pieces of automake systems, if its working without it but it certainly is relying on host machine then, whats your target ?
rmmr has quit [Ping timeout: 260 seconds]
rmmr has joined #yocto
joekale has quit [Ping timeout: 260 seconds]
<rburton>
khem: re rust, yeah my hunch was assembler not getting the path prefix somehow.
<khem>
I checked the problematic .o files and they are built from .c files
<khem>
as per the builtins crate they are never called by llvm so I guess no one cared enough as they would not get into packages if compiler is not calling them
alejandrohs has joined #yocto
Kubu_work has joined #yocto
vladest has quit [Remote host closed the connection]
<alperak>
good night
alperak has quit [Quit: Client closed]
Saur_Home32 has quit [Quit: Client closed]
Saur_Home32 has joined #yocto
jmiehe has joined #yocto
jmd has quit [Remote host closed the connection]
amitk has quit [Ping timeout: 264 seconds]
jmiehe has quit [Quit: jmiehe]
Saur_Home32 has quit [Quit: Client closed]
Saur_Home32 has joined #yocto
pidge has quit [Remote host closed the connection]
vladest has joined #yocto
Kubu_work has quit [Quit: Leaving.]
dlan has quit [Ping timeout: 256 seconds]
florian has quit [Ping timeout: 240 seconds]
jpuhlman has quit [Ping timeout: 256 seconds]
alessioigor has quit [Quit: alessioigor]
<jdiez>
I built core-image-minimal using the NXP BSP (and some others). the sd card image boots up to u-boot, which says it can't find the kernel (`Image`). and indeed, it is missing from the /boot partition, as well as device trees. Any clue how that may happen?
<jdiez>
okay, my `IMAGE_BOOT_FILES` variable indeed only contains "bootenv.txt", hmm
mason has joined #yocto
<mason>
Hey all. Hopefully someone's around for a quick question, which is: If I want to suppress grub-efi being build/included, I seem to want PACKAGE_EXCLUDE = "grub-efi" and I'm wondering where that ought to live. The place I found the concept talked about a local.conf and we don't seem to have that. Can that just be made to exist or is there ceremony around it?
florian has joined #yocto
alimon has quit [Ping timeout: 260 seconds]
<jdiez>
hm, so the solution to my problem was to change `IMAGE_BOOT_FILES:mx8m-nxp-bsp += " bootenv.txt"` to `IMAGE_BOOT_FILES:append:mx8m-nxp-bsp = " bootenv.txt"`. not sure why that worked :/
pidge has joined #yocto
alimon has joined #yocto
<khem>
mason: yeah local.conf or your own distro conf file is a good place
|Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<khem>
jdiez: yeah append is safer when you use overrides like it seems to be in your case
<khem>
otherwise its overrides the previous values
<mason>
khem: kk, thanks
<khem>
jdiez: I do not see any reference to bootenv.txt in meta-freescale so I imagine its some other layer adding it ?