pasherring has quit [Read error: Connection reset by peer]
jclsn has joined #yocto
pasherring has joined #yocto
_whitelogger has joined #yocto
tammranil has quit [Remote host closed the connection]
tammranil has joined #yocto
Chaser has joined #yocto
thomas_34 has joined #yocto
Chaser has quit [Ping timeout: 276 seconds]
alperak has joined #yocto
zeemate has joined #yocto
rob_w has joined #yocto
savolla has joined #yocto
rfuentess has joined #yocto
leon-anavi has joined #yocto
florian has joined #yocto
thomas_34 has quit [Quit: Client closed]
ptsneves has joined #yocto
ptsneves has quit [Read error: Connection reset by peer]
<LetoThe2nd>
how could I construct such an assignment? BLAH:foo = "d.getVar('bar'), else d.getVar('baz'), else d.getVar('BLAH')"? means, override with something if a variable is set, otherwise fall back to the original value?
Tyaku has joined #yocto
florian has quit [Ping timeout: 276 seconds]
<Tyaku>
Hello, I install a file in '${D}${datadir}/u-boot.dtb' from u-boot recipe, I also set 'FILES:${PN} += " ${datadir}/u-boot.dtb "' from the same receipe. In the build directory of U-Boot, in 'package' directory I have the installed file at correct place: 'u-boot/1_v2021.10+gitAUTOINC+5141064c15-r0/package/usr/share/', but then I want to get access to it from linux-renesas receipe. So in linux-renesas I have
<Tyaku>
configured: DEPENDS += " u-boot " in linux-renesas, but unfortunately, I don't have the expected file in 'linux-renesas/5.10.201-cip41+gitAUTOINC+meta_machine-r1/recipe-sysroot/usr/share/' I am missing something but don't know what. Any ideas ?
vthor has quit [Excess Flood]
vthor has joined #yocto
vthor has quit [Changing host]
vthor has joined #yocto
frgo_ has quit [Read error: Connection reset by peer]
frgo has joined #yocto
dmoseley_ has joined #yocto
dmoseley has quit [Ping timeout: 268 seconds]
florian has joined #yocto
<Tyaku>
Hummmm, is it possible that when we do "DEPEND += "XX"", it doesn't add in receipes-sysroot all the files installed by XX ? I suspect that only 'the supposed required files for the build' are installed in receipe-sysroot.
<rburton>
yes
<rburton>
no point putting target binaries in the sysroot as you can't run them
<rburton>
grep for SYSROOT_DIRS
<Tyaku>
In my case, I am doing this: https://docs.yoctoproject.org/ref-manual/classes.html#ref-classes-kernel-fitimage . I arrive to build the fitimage, but when I add the signing stuff, the problems comes. How the things are made, in kernel-fitimage.bbclass (called by linux-renesas.bb) I get an error at "cp -P ${STAGING_DATADIR}/u-boot*.dtb ${B}" Because
<Tyaku>
'linux-renesas/5.10.201-cip41+gitAUTOINC+meta_machine-r1/recipe-sysroot/usr/share/u-boot*.dtb': No such file or directory'. So I was looking for the good way to have this file here.
<Tyaku>
And I think the good way was what I was doing: In u-boot bbappend: Install the u-boot.dtb file, then on linux-renesas depend on u-boot so that the file is available. But it is not.
zwelch has quit [Ping timeout: 252 seconds]
zwelch has joined #yocto
polprog has quit [Remote host closed the connection]
dmoseley_ has quit [Ping timeout: 252 seconds]
dmoseley has joined #yocto
<Tyaku>
SYSROOT_DIRS=" /usr/include /usr/lib /lib /lib /usr/share /sysroot-only " (using bitbake -e), so /usr/share should be ok
thomas_34 has joined #yocto
<Fr4nk>
Tyaku: I had a similar issue and I remember that I had installed the single files into the do_install function
<Tyaku>
In u-boot_2021.10.bbappend: FILES:${PN} += " ${datadir}/u-boot.dtb " and do_install:append() { install -d ${D}${datadir}; install -m 0644 ${B}/hubmz-rzg2ul_defconfig/u-boot.dtb ${D}${datadir}/u-boot.dtb; }
<Fr4nk>
have you indicated the "u-boot.dtb" also in SRC_URI of bbappend, with also the "FILESEXTRAPATHS:prepend" at the top?
<Tyaku>
In linux-renesas_5.10.bbappend: DEPENDS += " u-boot ", but as the file is not "instaled" in the recipe-sysroot/usr/share of linux-renesas: The build fails in kernel-fitimage.bbclass
<Tyaku>
I don't add SRC_URI, because this file is generated by U-Boot. The idea is: U-Boot generate a DTB (for himself), based on the DTS. Then when we build linux-renesas, this is where the kernel-fitimage.bbclass is working, so it' isgoing to add the public key used to sign the kernel in the U-Boot DTB
<Fr4nk>
ah got it, but for that I think that you have to copy the generated file into the SRC of your recipe, like copying the dtb at the end of do_install of u-boot
<RP>
LetoThe2nd: a python function?
<LetoThe2nd>
RP: but that turns into an infinite recursion, it seems.
<RP>
LetoThe2nd: oh, I see. The tricky for that is immediate expansion
<RP>
BLAH := "${BLAH}"
ablu has quit [Ping timeout: 276 seconds]
ablu has joined #yocto
<RP>
but it will immediately expand the value
<LetoThe2nd>
RP: ah okay thanks, will check later. AFK for rest of today.
ptsneves has joined #yocto
dvergatal has quit [Read error: Connection reset by peer]
<Tyaku>
And the problems seems to be quiet easy to identify: linux-renesas.bb use kernel-fitimage.bbclass, in kernel-fitimage.bbclass it needs to copy a file from ${STAGING_DATADIR}/u-boot*.dtb of linux-renesas. But natively u-boot.dtb will not come here.
<Tyaku>
And DEPENDS mechanism seems to filter which files are really copied. Maybe it copies only files usefull for compilation (.so, .h, ...)
Lars99 has joined #yocto
<RP>
It seems the parsing time in core is pretty much entirely dependent on how long core-image-ptest takes to parse :/
ardo has quit [Ping timeout: 252 seconds]
ardo has joined #yocto
<rburton>
RP: i'm not massively surprised to be honest. does it skip lots of the parse if ptest isn't in distro features, as it doesn't need to run the class extension?
ptsneves has quit [Quit: ptsneves]
goliath has joined #yocto
ptsneves has joined #yocto
<RP>
rburton: I didn't check that, I'm just left wondering how it would be possible to spread this load...
aardo has joined #yocto
ardo has quit [Ping timeout: 252 seconds]
Lars99 has quit [Quit: lars99]
jjrh has quit [Ping timeout: 248 seconds]
rob_w has quit [Remote host closed the connection]
ptsneves has quit [Ping timeout: 244 seconds]
druppy has joined #yocto
cyxae has joined #yocto
tgamblin has quit [Ping timeout: 252 seconds]
Algotech has quit [Ping timeout: 260 seconds]
ptsneves has joined #yocto
Algotech has joined #yocto
Algotech has quit [Ping timeout: 276 seconds]
tgamblin has joined #yocto
Algotech has joined #yocto
tgamblin has quit [Ping timeout: 276 seconds]
<usvi>
pardon my yesterdays stupidity; I was able to compile the iptable owner module by merely modifying the kernel defconfig
<Crofton>
usvi: thanks for coming back and letting us know. We all ahve those kind of days :)
savolla has quit [Quit: WeeChat 4.6.3]
tgamblin has joined #yocto
<usvi>
I have a new stupidity today. I am not able to override mosquitto.conf with bbappend
<RP>
usvi: bbappends only work with recipes. You could replace it with your own copy of that
<usvi>
yea ; I can like go do devshell and patch it and the patch works; I just don't know why direct override does not work
SandeepRaju has joined #yocto
zeemate has quit [Ping timeout: 260 seconds]
khem has quit [Quit: WeeChat 4.6.3]
thomas_34 has quit [Quit: Client closed]
<usvi>
RP: I am too stupid to fully understand what you meant : ) I have a working bbappend for openssh, it writes custom sshd_config. but for mosquitto stuff just does not work the same way. It is probably my fault somehow, just trying to figure out how
tgamblin has quit [Quit: Leaving]
<usvi>
ok, so openssh recipe has in original recipe SRC_URI file://sshd_config . mosquitto recipe does not have mosquitt.conf in SRC_URI . probably explains the situation. I just ... don't understand where does it come from
<usvi>
ERROR: Unable to find any package producing path /etc/mosquitto/mosquitto.conf
khem has joined #yocto
tgamblin has joined #yocto
<usvi>
now it is there. I don't know what is happening anymore. I'll just devshell patch it and continue my business. sorry about the noise
druppy has quit [Ping timeout: 245 seconds]
tgamblin_ has joined #yocto
tgamblin_ has quit [Remote host closed the connection]
tgamblin has quit [Ping timeout: 268 seconds]
tgamblin_ has joined #yocto
tgamblin_ is now known as tgamblin
JPEW has quit [Ping timeout: 244 seconds]
ptsneves has quit [Ping timeout: 276 seconds]
JPEW has joined #yocto
<khem>
usvi: I think just having the file is not sufficient, you might have to write a do_install:append() as well in the bbappend which installs mosquitto.conf to the right location
<khem>
I dont see the main recipe doing an explicit install of this file, it might be getting installed via make install
<khem>
so you can overwrite it with explict install of this file via a do_install:append
<usvi>
yes I think that would be the most correct way
<usvi>
but I devshell-patched it and it works. of course not a pretty solution
<Tartarus>
Hey all, I'm trying to track down an odd problem with leon-anavi on a Pi 4 based platform. Is it valid to have compressed kernel modules inside the initramfs? They seem to be the cause of numerous "Invalid ELF magic" warnings from the kernel.
<RP>
Tartarus: is the compression module in the kernel a module itself? Just a random thought, I know nothing about that
<Tartarus>
RP: A good question. I would *hope* the Kconfig logic is such that if you set the compression type to xz it then doesn't let you set xz support to modular but a good thing to check, thanks.
<RP>
Tartarus: I'd hope that too but I know what the real world is like
<Tartarus>
Indeed
gvmeson is now known as vmeson
pasherring has quit [Remote host closed the connection]
<khem>
Tartarus:warnings suggest there's a mismatch between how the modules are compressed and how the kernel is trying to load them.
<khem>
what does zcat /proc/config.gz | grep -E "(DECOMPRESS|MODULE.*COMPRESS)"
<khem>
say
<khem>
IIRC we use xz for compression on kernel mods in linux-raspberrypi
<Tartarus>
khem: Leon has the setup atm and it's rather late there now.
<khem>
ok
<Tartarus>
And yes, it should be xz, and the files were xz (iirc) but we got that warning instead, and just disabling compression "fixes" it. But of course then grows the initramfs a good bit
<khem>
right, I think it will be good to know if initramfs kernel has xz decompressor built-in
fredcl has quit [Ping timeout: 276 seconds]
<khem>
tools during initramfs generation could be other suspects
<khem>
but I doubt
<khem>
does it happen for some kmods alone or every one being loaded
<Tartarus>
It's a number of warnings like that so more likely than not all
rfuentess has quit [Remote host closed the connection]
<khem>
which release are you on ?
fredcl has joined #yocto
<Tartarus>
This is still on scarthgap
<khem>
ok that should be good, with 5.15 kernel compressed kmods were in transition
leon-anavi has quit [Quit: Leaving]
SandeepRaju has quit [Quit: Client closed]
polprog has joined #yocto
SandeepRaju has joined #yocto
LetoThe2nd has quit [Ping timeout: 252 seconds]
florian_kc has joined #yocto
vmeson has quit [Ping timeout: 265 seconds]
LetoThe2nd has joined #yocto
goliath has quit [Quit: SIGSEGV]
vmeson has joined #yocto
vmeson has quit [Ping timeout: 268 seconds]
ptsneves has joined #yocto
SandeepRaju has quit [Quit: Client closed]
druppy has joined #yocto
savolla has joined #yocto
vmeson has joined #yocto
goliath has joined #yocto
dankm has quit [Remote host closed the connection]
dankm has joined #yocto
florian has quit [Ping timeout: 248 seconds]
ptsneves has quit [Ping timeout: 252 seconds]
druppy has quit [Ping timeout: 248 seconds]
warthog9 has quit [Remote host closed the connection]