<Guest51>
BUNDLE ensures initramfs is bundled with the kernel. I assume initramfs successfully bundled with kernel because size of Image-initramfs bigger than kernel Image.
<Guest51>
I also set load mmc 0:4 ${kernel_addr_r} Image-initramfs in U-Boot prompt. Kernel boots but I can't see any log related to initramfs. Am I doing something wrong?
<Guest51>
and I'm using core-image-base
Guest55 has joined #yocto
<Guest55>
If anyone answered the question, I didn't see because connection dropped.
Guest51 has quit [Ping timeout: 272 seconds]
<walter>
`time bitbake core-image-sato` got me 18.870s
ablu has quit [Ping timeout: 252 seconds]
ablu has joined #yocto
<walter>
but without any change, so it's basically the same as running the command twice and reporting the 2nd one. -- but the first command was ran yesterday, so there were no caches involved
Guest55 has quit [Quit: Client closed]
paulg has joined #yocto
<kanavin>
RP: rust update is good to go. It's about 10% slower.
<zeemate>
hello everybody, I have a git repository where the actual build are just in the subdirectories, and there is no top level makefile
<zeemate>
I had the idea either to point $S to ${WORDIR}/to/subproject or to change the directory with the do_compile task but neither works: doesn't find a mekfile
<zeemate>
makefile
<rburton>
zeemate: that's exactly what to do. can you share anything?
<rburton>
i'd double-check that S is actually correct
<rburton>
bitbake-getvar --value --recipe [your recipe] S
ptsneves has joined #yocto
gvmeson has joined #yocto
vmeson has quit [Ping timeout: 244 seconds]
gvmeson is now known as vmeson
vmeson has quit [Quit: Konversation terminated!]
belsirk is now known as rfuentess
lexano has quit [Ping timeout: 252 seconds]
sizzop has joined #yocto
lexano has joined #yocto
<RP>
khem: I tweaked the patches a little to clean up the cross/crosssdk recipe handling. It forces gcc for now but we can change that later
<wmills_>
When we build our own images for testing, we have testexport.tar.gz files for each image. When testing prebuilt images from the autobuilder (releases are RCs) textexport files are not supplied but we have the files needed for the /data directory (the manifest and the testdata.json)
<wmills_>
Is it possible to constrct the textexport.tar.gz from other files in the release?
<wmills_>
To me the other files look constant for a given layer stack and layer commits. Am I wrong?
goliath has joined #yocto
<RP>
wmills_: there are mixed feelings on testexport. I can see why it is really useful but the implications of doing it are horrible from a code perspective.
<RP>
wmills_: as such, we've been steering away from it as we'd prefer not to have that code, which is probably why the autobuilder doesn't enable it
<RP>
nobody has asked for it to be enabled so far
ptsneves has quit [Ping timeout: 276 seconds]
<RP>
rburton: do we want to enable testexport by default and make it a first class citizen?
<wmills_>
I guess I am confused. How do we run the OEQA tests w/o the files from testexport (regardless of how we get them)
<RP>
wmills_: the autobuilder runs tests immediately after it builds things. QA have checkouts matching the release and run their tests within those. I suspect your lava setup can't run without the testexport pieces instead of a full build end
<RP>
env
<RP>
this has been a source of friction for years :(
<wmills_>
Right we don't run the test in the build environment
<RP>
wmills_: and the autobuilder and QA do
<wmills_>
I don't understand the push back. It looks to me like you could supply one more file (testexport_template.tar.gz) either per release or per machine and enable testing for anyone regadless of the environment.
<wmills_>
Even the textexport per image only adds 0.5M per image which is dwarfed by the SPDX per image of 12M
<zeemate>
rburton: thank you, I mistakenly put "https://github.com/$projectrepo/;protocol=https" in SRC_URL instead of "git://github.com/$projectrepo/;protocol=https" now it works
tgamblin has quit [Quit: Leaving]
tgamblin has joined #yocto
Daanct12 has quit [Quit: WeeChat 4.6.3]
sizzop has quit [Remote host closed the connection]
sizzop has joined #yocto
nerdboy has quit [Ping timeout: 276 seconds]
nerdboy has joined #yocto
nerdboy has quit [Changing host]
nerdboy has joined #yocto
<RP>
wmills_: it is the principle of using the textexport code, not the filesize/resources
<RP>
test export code
rfuentess has quit [Remote host closed the connection]
tgamblin_ has joined #yocto
tgamblin has quit [Ping timeout: 260 seconds]
tgamblin_ is now known as tgamblin
florian has quit [Quit: Ex-Chat]
dgriego_ is now known as dgriego
jmd has joined #yocto
JPEW has quit [Ping timeout: 252 seconds]
JPEW has joined #yocto
mckoan is now known as mckoan|away
goliath has quit [Quit: SIGSEGV]
florian has joined #yocto
Guest64 has joined #yocto
polprog has quit [Changing host]
polprog has joined #yocto
sizzop has quit [Remote host closed the connection]
gvmeson has joined #yocto
sizzop has joined #yocto
berton has quit [Quit: Connection closed for inactivity]
leon-anavi has quit [Quit: Leaving]
druppy has joined #yocto
sizzop has quit [Ping timeout: 272 seconds]
_walter_32 has joined #yocto
walter has quit [Ping timeout: 245 seconds]
_walter_32 is now known as walter
walter has quit [Quit: Konversation terminated!]
jmd has left #yocto [ERC 5.4 (IRC client for GNU Emacs 28.2)]
walter has joined #yocto
ptsneves has joined #yocto
Guest64 has quit [Quit: Client closed]
risca has quit [Ping timeout: 248 seconds]
leaf_it_out has quit [Ping timeout: 272 seconds]
leaf_it_out has joined #yocto
risca has joined #yocto
risca has quit [Ping timeout: 276 seconds]
druppy has quit [Ping timeout: 276 seconds]
risca has joined #yocto
<fray>
I have two builds one works and one doesn't.. same recipe and the configuration is slightly different, but has the same CPU tune. In the one that is failing, all I get is an error message that saus
<fray>
../git/meson.build:1:0 ERROR: Executables created by c compiler ... are not runable. (this is the cross compiler BTW)
<fray>
in the that works, I get a list of host and build system compilers and options and continuation ofthe do_configure..
<fray>
I can't figure out any way to debug this to tell me WHY it thinks the executable is "wrong" in the bad one
<fray>
I even diffed the bitbake -e between the one that worked and didn't and all of the variables I looked at were the same... so it's a broader environmetn thing, I just can't figure out what without an ACTUAL useful error message
<fray>
any suggestions how I can get it to spit out a real error message (even what it was trying to run and the return code being not-zero would more more helpful)
ptsneves has quit [Ping timeout: 260 seconds]
druppy has joined #yocto
<RP>
fray: did for the config.log file, that usually has the answers
<JPEW>
huh... I would have though devtool had enough bitbake for that, but maybe not
<JPEW>
But don't some of those files `import bb...`
zeemate has quit [Ping timeout: 260 seconds]
<JPEW>
devtool imports plenty of bb, so I don't think it should be a problem; maybe those files need an `import bb.parse` at the top
<rburton>
fray: that means meson wants to be able to run executables but can't - usually as qemu-usermode doesn't work
<rburton>
fray: build/meson-logs/ has the full breakdown of what happened
<RP>
JPEW: maybe, the other users don't do that but I guess we perhaps just get lucky
<RP>
rburton: sorry, it is meson. For some reason I was thinking autotools
* RP
should sleep, I'm clearly not functioning!
<fray>
I finally figured it out, it was a misconfigured qemu, but there was absolutely noe rror message that the qemurunner was the problem.. just that nebulous message about "compiler doesn't work". really annoys the hell out of me when cmake/meson do crap like this
druppy has quit [Ping timeout: 244 seconds]
__ad has quit [Quit: ZNC 1.9.0+deb2+b1 - https://znc.in]
ad__ has joined #yocto
florian has quit [Ping timeout: 248 seconds]
savolla has quit [Quit: WeeChat 4.6.3]
frgo has quit [Read error: Connection reset by peer]