<kanavin>
manuel1985, not in a standard setup, only through use of externalsrc, e.g. 'devtool modify'
nemik has joined #yocto
camus has quit [Ping timeout: 240 seconds]
camus has joined #yocto
ilunev has joined #yocto
kranzo has quit [Quit: Client closed]
kranzo has joined #yocto
<kayterina[m]>
hello. In a recipe that simply installs a config file, I can do so with do_install{ install -m blabla }. Should I also add the config file in the package with FILES variable?
<kranzo>
kayterina[m]: if its not in the default directories inherited from cmake/autotools etc you need to add it, so it will be packed
<kayterina[m]>
hm, where are the default directories from cmake? I also do not compile anithing, so I don't explicitely inherit cmake
<kranzo>
otherwise it will trigger: installed-vs-shipped
<mnme>
Hi all! What's the best way to do an inherit depending on a PACKAGECONFIG? And is there a way to "remove" an inherit in a bbappend?
<ptsneves>
kayterina[m] if BPN==my-config yes
<_angelo_>
hi, building kernel i get ".do_preconfigure.1236297' failed with exit code 128:" but no other info.
<kayterina[m]>
Is the PATH '/usr/share/my-config' equal to '/usr/share/my-config/my-global.conf' for the FILES variable?
<ptsneves>
kayterina[m] give it a try. If the file is not packaged anywhere you will get an error. If you are unsure it went to another package just check the packages-split directory in the recipe's workspace
<kayterina[m]>
The recipe builds without errors and I checked FILES_ with bitbake -e. Τhe config ends-up in packages-split. But the client builds all their recipes with appending to FILES with these paths, ${datadir}, ${sysconfdir}
<ptsneves>
ok good so everything is working. that is a good step. If they do it, there is no harm besides it being redundant and may create some cargo cutting(quite common in Yocto). Harmless though
<kayterina[m]>
well, thanks. What is 'cargo cutting'?
<_angelo_>
sry, solved, it was a "SRC_URI = " in place of "SRC_URI +=". Error message was anyway not helping.
<ptsneves>
cargo culting, sorry typo. People trying to do something have seen before in a ritualistic way without really understanding what they are doing https://en.wikipedia.org/wiki/Cargo_cult
<thomasd13>
Lol - Its such a satisfying feeling, when a yocto build keeps all the 24 cores at 100% for hours
<kranzo>
ptsneves: i love learning new descriptions of behaviour i've seen before :D
<LetoThe2nd>
in which file is u-boot hiding on the raspi? I'm just too stupid to find the link between recipe/package and resulting image at the moment.
<qschulz>
LetoThe2nd: U-Boot might not be running on the RPi
<LetoThe2nd>
qschulz: it certainly is, I get the messages on the serial.
rob_w has quit [Remote host closed the connection]
ptsneves has quit [Ping timeout: 252 seconds]
ptsneves has joined #yocto
thomasd13 has quit [Ping timeout: 256 seconds]
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
kovalevsky has joined #yocto
nemik has quit [Ping timeout: 272 seconds]
nemik has joined #yocto
<ptsneves>
has anybody had issues with kernel-devsrc recipe causing races with make-mod-scripts? I see there is a do_install[lockfiles] but the kernel-scripts.lock does not get used anywhere else, leading me to believe it is not working as intended
<ptsneves>
i ask because i have work-shared/kernel-source files magically not existing.
kevinrowland has quit [Quit: Client closed]
mnme has quit [Quit: Client closed]
hcg has joined #yocto
hcg has quit [Quit: Ping timeout (120 seconds)]
nemik has quit [Ping timeout: 272 seconds]
nemik has joined #yocto
prabhakarlad has quit [Quit: Client closed]
kranzo has quit [Quit: Client closed]
<ptsneves>
Ok regarding the issue with kernel-devsrc i have the following model:
<ptsneves>
virtual/kernel:do_shared_workdir is a cleandir task for the kernel build dir!
<ptsneves>
but in kernel-devsrc.bb: module_base is inherited as well and that means that kernel-devsrc.bb:do_configure[depends] += make-mod-scripts:do_compile and that means that make-mod-scripts:do_compile happens after make-mod-scripts.bb:do_configure. Also we can see make-mod-scripts.bb:do_configure[depends] += "virtual/kernel:do_shared_workdir"
<ptsneves>
meaning, that do_shared_workdir done by make-mod-scripts will be erased concurrently by kernel-devsrc.bb:do_install[depends] += "virtual/kernel:do_shared_workdir" as well as kernel-devsrc.bb:do_install[depends] += "virtual/kernel:do:install"
<ptsneves>
Basically this recipe is broken as is
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
mnme has joined #yocto
argonautx has quit [Quit: Leaving]
ptsneves has quit [Quit: Client closed]
prabhakarlad has joined #yocto
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
<JaMa>
rburton: are there any known corner-cases where export GIT_CONFIG_PARAMETERS isn't enough to keep git happy? e.g. I'm seeing it from scons in iotivity build "fatal: unsafe repository ('git/extlibs/tinycbor/tinycbor' is owned by someone else); CalledProcessError: Command 'git tag -l v0.5.1' returned non-zero exit status 128.
<JaMa>
maybe because SConscript.py has own filtering of shell environment :/
<sotaoverride>
How would I get started on somethng like backporting rootfs overlay stuff from kirkstone to dunfell?
<sotaoverride>
just need the broadstrokes for now / thoughts now
frieder has joined #yocto
<sotaoverride>
talking about back porting overlayfs.bbclass from kirkstone to dunfell
camus has quit [Ping timeout: 240 seconds]
otavio_ has joined #yocto
otavio has quit [Read error: Connection reset by peer]
Circuitsoft has quit [Quit: Connection closed for inactivity]
sakoman has joined #yocto
<LetoThe2nd>
sotaoverride: cp, start build and see what fails.
<sotaoverride>
got it. Thanks
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
<ptsneves>
Couldnt make-mod-scripts use inherit nopackages?
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
<rburton>
LetoThe2nd: i know better than to click on your links
florian has quit [Quit: Ex-Chat]
florian_kc has quit [Ping timeout: 276 seconds]
Piraty has left #yocto [-]
<kranzo>
I'm porting some stuff from dunfell to kirkstone, can someeone explain me:
<kranzo>
Fetcher failure: Recipe uses a floating tag/branch without a fixed SRCREV
<kranzo>
I'm using git fetcher and have set branch=fixedname and tag=Bla_${PV}
<rburton>
the SRCREV should be a sha, not a name
<rburton>
tag names are not fixed
<rburton>
a sha is fixed, everything else can change
<kranzo>
true but in dunfell this was working. is sha enforced now? and how to work around this? is there something in place to receive the sha from the tag?
<kranzo>
ok that would break the whole idea i think ..
<rburton>
yes
<rburton>
its a change in kirkstone
<LetoThe2nd>
rburton: booooooring not clicking my links.
<JaMa>
and you can write a function which confirms that the sha mathes with the tag (or at least does in your local checkout) after bitbake fetches from sha, that's what we're using in webOS
<qschulz>
this seems to indicate it is not possible anymore to use tags/branches without SRCREV
<qschulz>
Would need confirmation from RP but that's mny understanding. We should therefore update the docs to reflect that
<qschulz>
kranzo: wondering if you couldn't use AUTOREV with the tag then
kroon has quit [Quit: Leaving]
<kranzo>
I'm scanning every variable right now to check how to make it work, but my brain just creates loops in what chain i can use this :D
<RP>
qschulz: I don't think we intended to stop tags working
<RP>
kranzo: you probably need to trigger the get_autorev() call somehow, then things will work again
<kranzo>
RP: that gives me some hope, that i don't need to fight about tag usage:D any startingpoint to this ?
<RP>
kranzo: how are you setting PV in these recipes?
<RP>
kranzo: something like SOMEVAR := "${@bb.fetch2.get_srcrev(d)}" in the recipe will probably make it work but it does mean your PV isn't triggering that
<kranzo>
RP: inherited from the recipename
<RP>
kranzo: that will be the issue
<RP>
zeddii, jonmason: For this qemuarm thing, I had a look at the defconfig, CONFIG_PCIEPORTBUS changes as does CONFIG_PCIE_PME and CONFIG_HOTPLUG_PCI, CONFIG_PCI_HOST_COMMON, CONFIG_PCI_HOST_GENERIC. I suspect one of these is the cause of the issue
<RP>
zeddii: rather than revert, we might be able to add the missing bit back?
<zeddii>
RP jonmason said he located the option, but I haven't gotten the patch yet. hopefully he pops up soon.
* zeddii
is fighting with strace
<RP>
zeddii: did you get it to reproduce?
* zeddii
has NFI what a landlock is.
<zeddii>
yah, I've been installing the strace-ptest package on all my images for a while, since it has caused issues int he past.
adrian__ has joined #yocto
<jonmason>
Is this the fbdev thing?
<kranzo>
RP: sadly even if i change to PV="'1.2.3" SRC_URI unchanged the error is raised
<zeddii>
I ran it manually and landlock and a couple of others failed. I'm looking at the first one now. maybe the other ones will follow.
<zeddii>
jonmason: yah, the sato qemuarm boot. I think you said you had it working locally.
<RP>
zeddii: I think we just have two landlock failures which are the issue
<jonmason>
zeddii: +CONFIG_DRM_VKMS=y
<RP>
kranzo: try adding SRCPV in there
<RP>
jonmason: I'm not convinced at that :/
<jonmason>
I've been reworking my gitlab CI stuff to not suck, and got pulled into a hole of getting it to now suck
<RP>
an unfortunate typo
<jonmason>
RP: yeah, it does seem dodgy but does fix it
<jonmason>
RP: lol, more accurate though
<RP>
jonmason: fix with your patch series or fix without your patch series
<RP>
jonmason: I'm worried we'll end up porting this bug into kirkstone
adrian_ has quit [Ping timeout: 272 seconds]
<kranzo>
RP: so PV = "${SRCPV}"
<kranzo>
results into a single line:
<kranzo>
ERROR: Parsing halted due to errors, see error messages above
<kranzo>
without any error message above oO
<jonmason>
RP: thats why I'm trying to determine, because I layered the defconfig change with the machine conf change
<jonmason>
together they work
prabhakarlad has quit [Quit: Client closed]
adrian_ has joined #yocto
<jonmason>
zeddii: your changes are in your poky-contrib?
<zeddii>
yup.
<zeddii>
zedd/kernel
<jonmason>
ok, let me run with that instead of adding your SHA changes by hand
<RP>
jonmason: also in master-next atm
<jonmason>
is the issue qemuarm and qemuarmv5 not having a bsp definition?
adrian__ has quit [Ping timeout: 246 seconds]
kranzo has quit [Quit: Client closed]
<jonmason>
"Could not locate BSP definition for qemuarm/standard and no defconfig was provided" is what I'm seeing
<jonmason>
of course, the odds are good I screwed something up :)
<zeddii>
jonmason: not in this case, they build fine here.
<jonmason>
ok, let me do it by hand, off of master-next
<RP>
jonmason: I dumped a defconfig before and after your changes. Did you intend to turn off the pci bits?
* RP
is trying to get to a local build position where he could test something
<jonmason>
RP: I had qemuarm working without PCI, since all of the virtio was -device
<fray>
"local build position".. I assume that isn't standing on your head with a keyboard ont he ceiling?
<jonmason>
but I have a patch queued to just use PCI, since all the rest are using PCI and its common
<RP>
jonmason: right, but that will break kirkstone if we backport the kernel change
kranzo has joined #yocto
<jonmason>
and IIRC removing PCI graphics caused the xorg test to fail on sato
<kranzo>
RP: ok -D flag showed me another problem here, so i would say for now the tag stuff is done solved
<kranzo>
[17:16:22] <kranzo> thx all have a nice weekend
<kranzo>
[17:16:28] [NOTICE] Last login from: ~kranzo@http-v.fe.bosch.de on Apr 29 15:10:09 2022 +0000.
kranzo has quit [Client Quit]
kovalevsky has quit [Quit: Leaving]
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
ptsneves has quit [Quit: Client closed]
nemik has quit [Ping timeout: 256 seconds]
nemik has joined #yocto
jmiehe has joined #yocto
GLumen_ has joined #yocto
amitk has quit [Quit: leaving]
GLumen has joined #yocto
GLumen_ has quit [Ping timeout: 246 seconds]
adrian_ has quit [Ping timeout: 256 seconds]
jmiehe has quit [Quit: jmiehe]
<lrusak[m]>
Hey guys, can I make the IMAGE_FSTYPE conditional to a recipe? If I build my image directly I want to use wic.xz but if I build my rauc bundle (which builds my image recipe) I want to use tar.xz
<RP>
jonmason, zeddii: I've confirmed that if I add back those PCI options, qemuarm works again without the virtio changes
<RP>
does it help if I try and figure out the ones that we really actually need?
<shoragan[m]>
lrusak: you can have multiple entries in IMAGE_FSTYPE. also, for the rauc bundle, you probably want to use a tar, as the rauc bundle itself is already compressed
<zeddii>
RP: from my side, not so much, jon was trying to get something minimal, so he may have a stronger opinion.
<jonmason>
RP: this is the defconfig?
<jonmason>
add them back, and I do another to fix it afterward
<jonmason>
I'm working to repro now, base passes and sato is taking a bit of time
<jonmason>
RP: yeah, that actually should get added to virtio.cfg
<jonmason>
but seems sane
<RP>
jonmason: I'm assuming you/zeddii know the correct place to put it
<jonmason>
RP: yes, I'll do a follow on with better testing this time
<zeddii>
yah. I can always drop it in, but I'm not set up to test it easily, my poor builder is chugging on strace right now.
<jonmason>
I've expanded my setup recently and I'm actually testing all the various kernels
<jonmason>
just wasn't doing graphics/sato
argonautx has joined #yocto
<jonmason>
which blows up on other stuff, like beaglebone-yocto and generic-x86
F_Adrian has joined #yocto
<zeddii>
I'll update the fragments here, my 2nd builder is quite slow, so it'll be a bit before I can do a test, but it can sit with me and I'll sned a patch that goes on top of the series I sent yesterday
<RP>
zeddii, jonmason: confirmed we just need the CONFIG_PCI_HOST_COMMON, CONFIG_PCI_HOST_GENERIC
<zeddii>
ack'd. making the change now.
<lrusak[m]>
shoragan: yep I’m aware, I would have just liked to separate the steps for our CI
<RP>
lrusak[m]: IMAGE_FSTYPE:pn-<recipe> would probably work
<RP>
jonmason: I also confirmed CONFIG_DRM_VKMS=y alone is not enough to get virtio graphics working
mckoan is now known as mckoan|away
kevinrowland has joined #yocto
<jonmason>
RP: that's for the fbdev issue
<jonmason>
I'll work off of master next and get it working
leon-anavi has quit [Quit: Leaving]
<RP>
jonmason: ah, ok.
gsalazar has quit [Ping timeout: 276 seconds]
rfuentess has quit [Remote host closed the connection]
amahnui1 has quit [Quit: Connection closed for inactivity]
amahnui1 has joined #yocto
vladest has quit [Remote host closed the connection]
vladest has joined #yocto
<jonmason>
RP: i think you need to drop e2d8c1dfbef93b1305cac58f43562ccff730df0d (qemuarm: use virtio device interface for graphics) from master-next
<jonmason>
that was causing problems for me for the past few weeks
<jonmason>
(from oe-core master-next)
Vonter has joined #yocto
kevinrowland has quit [Quit: Client closed]
<RP>
jonmason: I plan to, yes. Was just there in case it helped
<RP>
jonmason: dropped :)
<jonmason>
no, it makes things worse
<RP>
jonmason: I did test the PCI change without that FWIW
<jonmason>
a few weeks ago, i was messing with it and the graphics device was never found unless it was pci
<jonmason>
never caught it because I wasn't doing sato
<RP>
jonmason: Glad you can reproduce it now at least :)
<jonmason>
right now, I'm only needing "qemuarmv5: use arm-versatile-926ejs KMACHINE and add more virtio devices" patch and normal kernel is working for qemuarm, qemuarmv5, and qemuarm64
<RP>
jonmason: sounds good. I did just drop that one again too as I thought it might have the same graphics issue
<jonmason>
the dev-kernel is expected to work, right?
<RP>
jonmason: I'd think so but we don't test on the autobuilder
<jonmason>
it wasn't for some of the machines, and just wondering if it was my changes or not
argonautx has quit [Quit: Leaving]
turkeykittin has joined #yocto
m_jimmer12345 has joined #yocto
<m_jimmer12345>
Does anyone know of a bitbake command to clean all recipes that are in a image ?
<m_jimmer12345>
I tried
<m_jimmer12345>
bitbake -g IMAGE_NAME && cat task-depends.dot | grep -v -e '-native' | grep -v digraph | grep -v -e '-image' | awk '{print $1}' | sed "s|\.do_*.*$||g" | sed "s/*}/:/g" | sed "s/.*://" | sed "s|\"||g"| sort | uniq
<m_jimmer12345>
it does not remove the "everything" before }
<m_jimmer12345>
bitbake -c clean $(echo $t | sed "s/.*}//g")
<m_jimmer12345>
there we bo
<m_jimmer12345>
go *
florian_kc has joined #yocto
<rfs613>
m_jimmer12345: might be simpler to just delete tmp directory?
<m_jimmer12345>
No because there is so many other things to consider\
<m_jimmer12345>
My deploy and sstate and stamps are not in the tmp
<m_jimmer12345>
this the kinda the issue
<rfs613>
afaik do_clean will not clean sstate, and it also doesn't clean downloads
<m_jimmer12345>
If they where It would kill alll 20+ machines in the cache or dep;loy ect
<rfs613>
there is do_cleansstate though
<m_jimmer12345>
yeah that is do_cleanall right ? \
<rfs613>
cleanall should do it yeah
<m_jimmer12345>
we really just want to run do_clean becuase there are license isssues
<rfs613>
still doesn't clean downloads, in case you want to check you can still fetch sources
<m_jimmer12345>
example
<m_jimmer12345>
ERROR: packagegroup-core-boot-1.0-r17 do_populate_lic: The recipe packagegroup-core-boot is trying to install files into a shared area when those files already exist. Those files and their manifest location are:
<m_jimmer12345>
example build fails once then I run again ^^
<rfs613>
m_jimmer12345: that's above my pay grade :P
<neverpanic>
you should be able to get rid of this by wiping tmp, unless they are systematic issues, in which case they will happen again on the next build.
<m_jimmer12345>
right so the fact that DEPLOY_DIR is nto in tmp and if I
<m_jimmer12345>
build dir and tmp dir's(mc) are in like /home/whatever/somebuild
<m_jimmer12345>
if I remove tmp sstate and stamps(this really) freaks out. But If I remove stamps .....
<m_jimmer12345>
if I remove the license dir that it is saying I am installing to something that is alreay there. I have to rebuild the bsp(kernel, uboot/redboot at91bootstrap loader) layers (clean -> build) and the image will make it
<m_jimmer12345>
so I figure if I loop each of the deps of the image and tell it to clean the thing. Will that clean the /deploy/license dir ?
<neverpanic>
Your setup it weird. Sounds a lot like self-inflicted damage to me.
<neverpanic>
Just set DEPLOY_DIR = "${TMPDIR}/deploy" for now while keeping SSTATE_DIR and DL_DIR and build again and it should pass.
<m_jimmer12345>
what is the advantage of having the deploy there ?
<m_jimmer12345>
it will not do the license deal ?
mvlad has quit [Remote host closed the connection]
manuel1985 has joined #yocto
<neverpanic>
the error message is triggered in sstate.bbclass in sstate_install. Because it happens in do_populate_lic it's clear that it happens when restoring the license.bbclass sstate cache, which according to https://git.yoctoproject.org/poky/tree/meta/classes/license.bbclass#n411 deploys from ${LICSSTATEDIR} to ${LICENSE_DIRECTORY}
<neverpanic>
LICENSE_DIRECTORY is "${DEPLOY_DIR}/licenses"
<m_jimmer12345>
Ok thanks for looking into that
<neverpanic>
Your DEPLOY_DIR/licenses contains a file that your sstate restore wants to write
<neverpanic>
Hence, if you start with an empty DEPLOY_DIR, this can't happen.
<m_jimmer12345>
but I would figure that the sstate would know that it already did such a task
<m_jimmer12345>
or that stamps would. Is this not true ?
<neverpanic>
Apparently it decided that the task needs re-running for packagegroup-core-boot. Figuring out why is a longer journey.
<m_jimmer12345>
yeah I kinda went down that rabbit hole the other night.
<m_jimmer12345>
neverpanic thanks for all your nice words and help. I have changed everything back tpo tmp. But will this kill my other builds sstate ?
<m_jimmer12345>
like if my other (12) boards have the sstate and it thinks that the deploy dir is .... and that the package groups are located X would that not break the cache ?
<m_jimmer12345>
sorry for all the questions just really dont want to lose that cache unless I do it over the weekend on the ci/cd. I am sure that you understand why
<neverpanic>
sstate is independent of tmp, why would it will your sstate?
<neverpanic>
I don't think the path of DEPLOY_DIR should affect sstate – if the value of $DEPLOY_DIR ends up in the contents of your sstate cache, wouldn't that be a bug anyway?
<m_jimmer12345>
I did not know if sstate was or was not. I just figured that it used the packages(in deploy dir) to set the scene
<m_jimmer12345>
but I guess you are saying it does not. Ill give it a test run
<m_jimmer12345>
does stamps dir want to know where the deploy if ? Should that also be in tmp. We have a large number of devices that are the same really minus the bsp layers as I am sure you all do as well
<m_jimmer12345>
deploy is*
<turkeykittin>
In an attempt to upgrade cmake in my yocto, I found a poor mans way of forcing cmake 3.16.5 to cmake 3.18.2 by changing the cmake bb file versions (and checksums). Seems like everything rebuilt fine (albeit with some warnings) but my populated SDK (after install) still maintains cmake 3.16.5. Do I have to manually wipe and rebuild the whole SDK
<turkeykittin>
got it, thank you! What indicates that it should be "nativesdk-cmake" as opposed to what I have in my current yocto/poky configuration as "cmake-native_3.16.5"? Is it just something that changed over versions? (I'm a bit behind, still on Dunfell)
<turkeykittin>
(obviously ignoring version)
<turkeykittin>
specifically nativesdk-cmake vs cmake-native
<m_jimmer12345>
native is your host native-sdk could mean cross compiled for say things like qt or cmake or your toolchain
Vonter has quit [Ping timeout: 240 seconds]
frieder has quit [Ping timeout: 276 seconds]
frieder has joined #yocto
<turkeykittin>
ah I see it now, I had assumed it was a version difference but yeah I see it in my current version, a higher level dependency
Wouter0100 has quit [Ping timeout: 276 seconds]
<m_jimmer12345>
neverpanic same error:(
<m_jimmer12345>
LICSSTATEDIR seems to be read only:(
<neverpanic>
m_jimmer12345: sounds like you have two sstate tasks that attempt to setscene the same file
<m_jimmer12345>
maybe Ill look
<m_jimmer12345>
I think we found it .....
<m_jimmer12345>
legacy stuff
manuel1985 has quit [Ping timeout: 250 seconds]
amahnui1 has quit [Quit: Connection closed for inactivity]
<m_jimmer12345>
false alarm no extra calls to sstate or anything:(
<m_jimmer12345>
I am thinking that LICSSTATEDIR is show getting currrupted
<m_jimmer12345>
Ok so from sstate.bb I see that we have a hardcoded value of
<turkeykittin>
So ever since I made the cmake change with preferred cmake (as well as added TOOLCHAIN_HOST_TASK += "nativesdk-cmake" to my conf), Ive encountered an issue when installing the sdk
<turkeykittin>
the SDK extracts fine but hangs trying to set up the environment: "Setting it up...ls: cannot access '/opt/fslc-xwayland/3.1/environment-setup-*': No such file or directory"
<turkeykittin>
I don't know why suddenly it would no longer generate an environment setup script?
<m_jimmer12345>
what was your command is it a meta script or just stright up do_populate-sdk ?
<turkeykittin>
just bitbake myimage -c populate_sdk
<turkeykittin>
I suppose I could do it for the core (my image is more or less a very slightly modified core) but I dont understand why it worked before and suddenly the change regarding cmake would break it
<turkeykittin>
I _did_ delete the /opt/fslc-xwayland/3.1 directory for a fresh install, but I don't believe it existed prior to populating the sdk. My only concern would be that it may have existed and been pulling from it prior. Not sure what other commands I could have used would have generated it though...
<turkeykittin>
Havent touched the SDK until today.
<m_jimmer12345>
Im not sure TBH. Are you doing anything with SDK_DEPLOY_DIR or anything like that ?
<turkeykittin>
Nope
<turkeykittin>
Just using defaults
<m_jimmer12345>
have you tried to re-generate it ?
<m_jimmer12345>
can you show your local.conf in a paste bin ?
<turkeykittin>
Like run bitbake myimage -c populate_sdk after deleting the directory? Or the image itself? I've regenerated the image (without a clean, just a rebuild) in an attempt to fix, but wanted to hold off on regenerating the whole image due to how long it takes on my host :X
<turkeykittin>
Yeah I can include that, one second
frieder has quit [Remote host closed the connection]
<m_jimmer12345>
so OECMAKE_GENERATOR="Ninja"
<m_jimmer12345>
would use ninja but the other is unix make files. Look likes there is not support for Watcom or green hills
<m_jimmer12345>
maybe i missed it
<turkeykittin>
Ah good to know! So it's using 8 already then (from memory of seeing ninja -j 8 or something similar in a recent error)
<turkeykittin>
Interesting, removing the toolchain host task fixed the environment issue
<turkeykittin>
YES
nemik has quit [Ping timeout: 276 seconds]
<turkeykittin>
cmake --version prints out 3.18.2. Greatly appreciated m_jimmer12345
nemik has joined #yocto
<m_jimmer12345>
good job !:)
<turkeykittin>
The preferred version was a life saver. That was what was missing
<turkeykittin>
and then me inserting legacy code that I didnt know would work or not after I realized I had inserted it into bblayers instead of local.conf...
<turkeykittin>
Don't try to fix multiple things at once! :X You'll only break it more! haha
<turkeykittin>
For anyone curious, TOOLCHAIN_HOST_TASK += "nativesdk-cmake" in local.conf seems to make bitbake unhappy when populating the sdk
<turkeykittin>
populating/installing*
kevinrowland has joined #yocto
<kergoth>
turkeykittin: beware of direct operations with variables used by recipes/classes, if the recipe/class sets its value with ?=, your += will result in that value not being applied, and only nativesdk-cmake will be listed, instead of adding to the existing value as would be the case with :append/_append. i'd examine bitbake -e yoursdkrecipe | grep TOOLCHAIN_HOST_TASK= with and without that addition
<turkeykittin>
Will check that out, thank you kergoth !
<turkeykittin>
Interesting, it's having a hard time finding python when I'm sourcing and trying to manually cmake some cpp to python bindings... sounds like an issue for another time though. Gotta head out for an hour or two :\
<turkeykittin>
Thank you for all the help! Hope you track down the root of your issue m_jimmer12345! Unfortunately it's way over my head :(
<m_jimmer12345>
thank you for the nice words. We found the root issue and are testing
<m_jimmer12345>
gotta build close to 40 + machines and all with multi images. Let alone the multiconfig emulators that we do.