<Guest20>
I am reaching out to you for urgent assistance as I am encountering difficulties building a Yocto image for my Jetson TX2 Devkit (4GB) following the instructions provided in the documentation.
<Guest20>
Despite my efforts, I am unable to pinpoint the exact source of the issue. I have doubts regarding whether the "kirkstone" branch of the Poky repository supports my Jetson TX2 Devkit, or if there are other factors contributing to the problem.
<Guest20>
Given the urgency of my situation and my limited expertise in debugging Yocto builds, I am kindly requesting your assistance in troubleshooting this issue. Any guidance, insights, or recommendations you can provide would be greatly appreciated.
Guest20 has quit [Client Quit]
enok71 has quit [Ping timeout: 256 seconds]
florian_kc has quit [Ping timeout: 260 seconds]
<tlwoerner>
JPEW: moto-timo: you guys are the best! thanks for your review!
<tlwoerner>
my python is a little weak, so i greatly appreciate the feedback
<tlwoerner>
i'll reply to your review comments specifically on github in a bit
<moto-timo>
tlwoerner: you are the best for doing the work!
joekale has joined #yocto
davidinux has quit [Ping timeout: 268 seconds]
davidinux has joined #yocto
joekale has quit [Ping timeout: 256 seconds]
jclsn has quit [Ping timeout: 246 seconds]
jclsn has joined #yocto
xmn has joined #yocto
joekale has joined #yocto
starblue has quit [Ping timeout: 260 seconds]
starblue has joined #yocto
nerdboy_ has quit [Ping timeout: 272 seconds]
Vonter has quit [Ping timeout: 252 seconds]
goliath has quit [Quit: SIGSEGV]
Vonter has joined #yocto
nerdboy_ has joined #yocto
joekale has quit [Ping timeout: 272 seconds]
ablu has quit [Read error: Connection reset by peer]
ablu has joined #yocto
<merit>
nvm
<merit>
I done goofed, after all
khem has joined #yocto
nerdboy_ has quit [Quit: Leaving]
nerdboy has joined #yocto
nerdboy has joined #yocto
Zapados has quit [Quit: Client closed]
dlan has quit [Ping timeout: 268 seconds]
dlan has joined #yocto
roussinm has quit [Ping timeout: 268 seconds]
dankm has joined #yocto
kanavin has quit [Remote host closed the connection]
GNUmoon has joined #yocto
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #yocto
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #yocto
jmd has joined #yocto
mulk has quit [Ping timeout: 255 seconds]
alessioigor has joined #yocto
mulk has joined #yocto
amitk_ has joined #yocto
amitk_ has quit [Remote host closed the connection]
jmd has quit [Remote host closed the connection]
leon-anavi has joined #yocto
thomas_34 has joined #yocto
olani- has joined #yocto
zpfvo has joined #yocto
bielpa__ has joined #yocto
bielpa_ has quit [Read error: Connection reset by peer]
pbiel has quit [Read error: Connection reset by peer]
pbiel has joined #yocto
mvlad has joined #yocto
ray-san has joined #yocto
mckoan|away is now known as mckoan
paulg has quit [Remote host closed the connection]
<yocton>
RP: Wait, my awesome SQL skillz were not enough? ^^ Joking aside, this is weird because I specifically tested a bluez5 CVE disapearance when updating from the AB database you sent :-/ Can you save again the new database?
frieder has quit [Remote host closed the connection]
mbulut has joined #yocto
Saur75 has quit [Quit: Client closed]
<rburton>
zhmylove: the -dev package doesn't actually contain any libraries to link against so you need the real packages too
<rburton>
argubly the sdk generation could prune /usr/bin out like we prune the sysroot already
Saur75 has joined #yocto
mbulut has quit [Client Quit]
<zhmylove>
rburton: thanks! So the proper way would be patching some bbclass in order to prune /usr/bin inside target sysroot, right?
<rburton>
zhmylove: if that bothers you enough, yeah
Daanct12 has joined #yocto
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #yocto
lexano has joined #yocto
starblue has quit [Ping timeout: 260 seconds]
rfuentess has quit [Remote host closed the connection]
Saur75 has quit [Quit: Client closed]
starblue has joined #yocto
Saur75 has joined #yocto
crazy_imp has joined #yocto
Guest3 has joined #yocto
hashraf has joined #yocto
Guest3 has quit [Client Quit]
thomas_34 has quit [Quit: Client closed]
<crazy_imp>
hi, i'm using `wic rm ...` to remove a file from a partition - the file is removed, but after compressing the file system, there's close to zero change in size, so i assume the files are just discarded from the the fs structure but the space isn't filled with zeros (or some other static value that compresses well). is there something to 'scrub' the filesystem? also tried `wic cp` with a file consisting
<crazy_imp>
of zeros to overwrite the file before removing it - no change
<crazy_imp>
(it's a FAT fs if thats relevant)
KorG has joined #yocto
<rburton>
crazy_imp: would it be easier to just remove the file from the rootfs in the first place?
astlep5504018066 has joined #yocto
<crazy_imp>
rburton: it's not the rootfs, it's the /boot which contains an unused Image which i like to remove (the real Image lies in the rootfs and uboots also loads it from there)
bielpa_ has joined #yocto
sotaover1ide has joined #yocto
astlep550401806 has quit [Read error: Connection reset by peer]
jclsn has quit [Ping timeout: 260 seconds]
sotaoverride has quit [Ping timeout: 260 seconds]
bielpa__ has quit [Ping timeout: 260 seconds]
dlan has quit [Ping timeout: 260 seconds]
ctraven has quit [Ping timeout: 260 seconds]
vvn has quit [Ping timeout: 260 seconds]
<rburton>
i'd spent some time hacking on wic so that it didn't do that in the first place instead of trying to work around and figuring out how to defrag a FAT filesystem from linux
ctraven has joined #yocto
dlan has joined #yocto
zhmylove has quit [Ping timeout: 260 seconds]
alessioigor has quit [Ping timeout: 260 seconds]
rob_w has quit [Ping timeout: 260 seconds]
Vonter has quit [Ping timeout: 260 seconds]
vvn has joined #yocto
jclsn has joined #yocto
<LetoThe2nd>
crazy_imp: long shot, but is that eventually IMAGE_BOOT_FILES kicking in?
Vonter has joined #yocto
<crazy_imp>
LetoThe2nd: possible, but removing the last traces of whatever was in there and got deleted is a good feature anyway :)
<crazy_imp>
rburton: got the effect i wanted - used the reported free size by `wic ls ...` to create a file with the right size (all zeros) to flood the fs, `cp` and `rm` later, it compresses better :)
<crazy_imp>
(attempting to flood it with a file that's too big fails, it checks first :D)
<rburton>
crazy_imp: fixing wic would be a better long-term solution though :)
<rburton>
some fixes were made upstream so it needs updating
<phako>
ah. Thought I had to do some other magic. thanks. I have just started an image build anyway to see what else breaks and have to attend meeting :D
<phako>
*goes and smashes exprtk to pieces*
manuel1985 has quit [Ping timeout: 256 seconds]
<hashraf>
> this file name is in SRC_URI, right?
<hashraf>
rburton no, it is an external file. Not coming from SRC_URI.
<rburton>
hashraf: put it in SRC_URI and bitbake will re-run unpack if it changes
<rburton>
phako: i can't remember if i made boost use it directly yet, was still convincing it to build properly
<phako>
rburton: well yeah the whole boost build situation is a dumpsterfire
<rburton>
indeed
<crazy_imp>
rburton: one warning regarding fatcat - it somehow manages to make the fs file larger ...
paw has joined #yocto
Noor has joined #yocto
<RP>
Does anyone have any thoughts on what to do with "missing" pthread flags? The trouble is newer glibc doesn't need them since libpthread is built in. This leads to native built on newer hosts being incompatible with native recipes then trying to rebuild on older hosts as the flags are lost
<RP>
Effectively the f39 worker is probably "polluting" the older native sstate compatibility
* RP
wonders about putting -lpthread into the uninative linking flags
joekale has joined #yocto
jmiehe has joined #yocto
<crazy_imp>
it grows from 536870912 (requestesd size with `--filex-size 512M` in the wks file) to 537927680 bytes - all zeros at the end of the fs. not sure why. running the -z on the same file again, it keeps the new size and doesn't grow further
tgamblin has quit [Remote host closed the connection]
tgamblin has joined #yocto
xmn has joined #yocto
ptsneves has joined #yocto
jmiehe has quit [Quit: jmiehe]
thomas_34 has joined #yocto
<thomas_34>
Can someone help me with compile/deploy tasks with overrides? I have a recipe which defines do_compile(), do_compile:k3r5(), do_deploy() and do_deploy:k3r5() tasks. I also specified "addtask deploy after do_compile" and inherited deploy class.
<thomas_34>
I also set a multiconf dependency: do_compile[mcdepends] += "mc::k3r5:recipe:do_compile"
<thomas_34>
When I execute bitbake -f recipe, the do_deploy:k3r5 tasks does not get executed. Why?
<rburton>
normally because bitbake recipe is actually bitbake recipe:do_build, and your do_deploy doesn't ask to be built before do_build
<RP>
"ninja: fatal: -l parameter not numeric: did you mean -l 0.0?" - something isn't quoting nicely :/
<thomas_34>
rburton, on which tasks do_build normally depends on? Or in other words: Which tasks are triggered by do_build?
<rburton>
for a normal recipe build depends on package_write which depends on package which depends on install which depends on compile which depends on configure which depends on unpack which depends on unpack
<rburton>
there's more tasks, but that's the gist
<rburton>
if you're adding your own deploy task and you want to deploy on build, then say so
<rburton>
eg meta/recipes-bsp/u-boot/u-boot.inc:addtask deploy before do_build after do_compile
KorG has quit [Ping timeout: 268 seconds]
ray-san has quit [Ping timeout: 264 seconds]
<thomas_34>
rburton would you throw a glance on my recipe when I paste it?
<rburton>
if i get a moment. all you need is to addtask before do_build.
<thomas_34>
I try to understand to answers. I'm just not sure if I miss something because of the override/multiconfig
<thomas_34>
*your answers
roussinm has joined #yocto
<rburton>
i'd definitely consider reusing the existing uboot recipes and just changing SRC_URI
Bardon_ has joined #yocto
Bardon has quit [Ping timeout: 272 seconds]
Saur75 has quit [Quit: Client closed]
<thomas_34>
Its not that easy, because of external dependencies which are gonna baked into "u-boot-container" images, multiple architectures and so on...
Saur75 has joined #yocto
<yocton>
RP: Indeed this cve-check result is more like it! What we see is rejected CVE disapearing and updated CVEs set to Patched status :D
<thomas_34>
So if I reevaluate your dependency summary, this is what I have: compile() -> deploy() -> install() -> package() -> build()
<thomas_34>
Ahhh... or do you mean my "addtask deploy after do_compile" is wrong here. It should be the other way around, like "addtask deploy before do_build"?
enok71 has quit [Ping timeout: 256 seconds]
luc4 has joined #yocto
luc4 has quit [Client Quit]
dgriego has quit [Ping timeout: 268 seconds]
dgriego has joined #yocto
<phako>
rburton: hm, so a quick test of just replacing boost-build-native with b2-native does not seem to change anything. Will check further next week
<zeddii>
RP: done. I had thought I pushed that compat bump a while ago. still testing the rest of the upgrades, but that should be done soon.
<RP>
zeddii: thanks, it removes an annoying AB failure :)
<yocton>
RP: as of now, if you revert the scheduler patch you should be okay'ish : the database has been cleaned up by today's run and master being last mean that the graph will be properly updated
<RP>
yocton: will that break anything else?
bielpa__ has joined #yocto
<yocton>
There won't be a daily full download until we find a proper fix but that is less urgent
<RP>
yocton: would it happen just 24h out of sync?
pbiel has quit [Ping timeout: 252 seconds]
bielpa_ has quit [Ping timeout: 268 seconds]
* RP
reverts that for now as it probably is better
<yocton>
No because the database will be <6h old when master will look at it (it will be updated by the nanbield branch just before)
pbiel has joined #yocto
<RP>
we don't store a "this is when it was originally downloaded" stamp?
<yocton>
the database file mtime is used for that
Noor has quit [Read error: Connection reset by peer]
<RP>
yocton: starting to wonder if a "weekly move the DB to an archive filename" might be an idea
florian_kc has joined #yocto
* yocton
must go AFK for a few hours but will try tonight to go back to this
<jdiez>
why would it be that clang-native is making its way into my ext sdk build? I have CLANGSDK = "0" set
<jdiez>
(I have the meta-clang layer in my build for other reasons)
simonew has quit [Ping timeout: 272 seconds]
amitk_ has quit [Ping timeout: 255 seconds]
amitk_ has joined #yocto
jmd has quit [Remote host closed the connection]
amitk_ has quit [Ping timeout: 252 seconds]
sakman has quit [Ping timeout: 252 seconds]
florian_kc has joined #yocto
mvlad has quit [Remote host closed the connection]
olani- has quit [Ping timeout: 256 seconds]
Saur75 has quit [Quit: Client closed]
Saur75 has joined #yocto
jclsn has quit [Quit: WeeChat 4.2.1]
jclsn has joined #yocto
static_rocket has joined #yocto
<static_rocket>
so, the way most distros package bzip2 is interesting...
jclsn has quit [Quit: WeeChat 4.2.1]
jclsn has joined #yocto
<static_rocket>
seems like other distros (arch, debian, gentoo (off and on)) are still using the secondary makefile "Makefile-libbz2_so" which produces a lib with an soname of "libbz2.so.1.0", in contrast to what yocto uses which produces a library with an soname of "libbz2.so.1"
<static_rocket>
I say gentoo was off and on because it dropped this behavior in a later release leading to this bug https://bugs.gentoo.org/338321 so now I assume their current behavior is to use the new soname lib and provide a link for backwards compatibility.
jclsn has quit [Quit: WeeChat 4.2.1]
jclsn has joined #yocto
<static_rocket>
If I submitted a patch to introduce this link for yocto / oe-core in the name of distro compatibility do you think I would get crucified?