tgamblin has quit [Remote host closed the connection]
tgamblin has joined #yocto
mckoan|away is now known as mckoan
<mckoan>
good morning
pabigot has quit [Ping timeout: 250 seconds]
Thorn_ has joined #yocto
Thorn has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
pabigot has joined #yocto
wooosaiiii has quit [Quit: wooosaiiii]
wooosaiiii has joined #yocto
rfuentess has joined #yocto
barometz has quit [Quit: you can't fire me!]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
barometz has joined #yocto
Kubu_work has joined #yocto
gsalazar has joined #yocto
Guest98 has joined #yocto
<Guest98>
hi, morning everyone.
<Guest98>
i have TARGET_LDFLAGS += "..." definitions in myrecipe.bb. i want to export this definition as target_link_libraries(exe ${TARGET_LDFLAGS}) in CMakeListst.txt, how can i do it? if i can't do this, i have to manually add all the definitions in TARGET_LDFLAGS to target_link_libraries and delete them from the recipe as well.
vladest has quit [Ping timeout: 240 seconds]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
amitk_ has joined #yocto
alessioigor has quit [Client Quit]
alessioigor has joined #yocto
ptsneves has joined #yocto
alessioigor has quit [Client Quit]
alessioigor has joined #yocto
<LetoThe2nd>
yo dudX
<Guest98>
hi
florian_kc has joined #yocto
<RP>
mischief: Ah. Is this under pseudo? I think pseudo may need to learn some "magic" to help with security attributes :/
ptsneves has quit [Ping timeout: 246 seconds]
<mischief>
RP: sigh, no
<mischief>
it's a stupid tar bug.
<RP>
mischief: ah, right, yes. I'm paging in context! Did ubuntu patch that?
<mischief>
this release of tar is from 2 years ago and does not contain the patch.
xmn has joined #yocto
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
ptsneves has joined #yocto
nemik has quit [Ping timeout: 245 seconds]
nemik has joined #yocto
manuel1985 has quit [Remote host closed the connection]
florian_kc has quit [Read error: Connection reset by peer]
manuel1985 has joined #yocto
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
<RP>
mischief: correct
prabhakarlad has joined #yocto
static_rocket has quit [Remote host closed the connection]
<Alban[m]1>
rburton: Regarding the useradd dependency problem, I just noticed that appending to USERADDSETSCENEDEPS didn't work because there is a class-target override on this variable. Now using USERADDSETSCENEDEPS:append:class-target I can see that the do_package_setscene task do have the extra dependency. But I'm still unsure which dependency I should add to get the pulseaudio group. I used pulseaudio:do_populate_sysroot_setscene because other
<Alban[m]1>
dependencies in USERADDSETSCENEDEPS use this task as well, but I have no idea what this task does.
amitk_ has quit [Ping timeout: 246 seconds]
<mischief>
RP: so.. buildtools can't help me in that case unfortunately
<mischief>
and unfortunately ubuntu 18 has too old gettext to build HEAD of tar so now i have to fix that too :)
xmn has quit [Quit: ZZZzzz…]
<RP>
mischief: I was meaning we might consider adding that patch as a backport so the next buildtools would have it. You could also patch tar locally and build a new buildtools?
<RP>
("bitbake buildtools-tarball")
<mischief>
i have to get that new buildtools into the build container somehow though
<mischief>
we need to upgrade from ubuntu 18 to 22 anyway; since ubuntu 18 is sorta EOL'd and ubuntu 22 has a new coccinelle :)
amitk_ has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
amsobr has quit [Quit: Konversation terminated!]
<mischief>
RP: is there some kind of automation the yocto project uses that could exercise this? testing oe.path.copytree or archiver.bbclass on a SELinux enabled host?
<RP>
mischief: we don't have any selinux enabled hosts to test on
amitk_ has quit [Ping timeout: 245 seconds]
<mischief>
i think fedora, alma linux and opensuse leap all support it and they are described as supported hosts for yocto. does nobody use those in the automation infrastructure?
<Guest98>
when trying to build myproject on yocto with cmake, it cannot find string, iostream, vector, limits headers. could it be a problem with sysroot somehow? i handled my own .cpp and .hpp files. any idea?
<rburton>
Guest98: sounds like your cmakelists is doing Bad Things
<mcfrisk>
Guest98: not using cmake.bbclass and the toolchain file provided by it?
<rburton>
because lots of cmake recipes work just fine
amitk_ has quit [Ping timeout: 246 seconds]
amitk_ has joined #yocto
amitk_ has quit [Ping timeout: 246 seconds]
ptsneves has quit [Ping timeout: 245 seconds]
<Guest98>
rburton rookie doing rookie things. i shouldnt have override CMAKE_CXX_FLAGS, should have append.
<sudip>
khem: another example of devshell advantage :)
<rfs613>
sudip: could you try using ldd without using devshell, and tell me which libcrypto it shows?
<sudip>
without devshell it will just show you whatever libcrypto you have in your host,
vladest has joined #yocto
Guest98 has quit [Quit: Client closed]
vladest has quit [Read error: Connection reset by peer]
vladest has joined #yocto
<rfs613>
hmm i don't see that here. But really I am trying to understand how it works. Is bitbake modfying LD_LIBRARY_PATH for example, or something similar?
sakoman has joined #yocto
<sudip>
it will have its own LDFLAGS, but you can see more on what its doing in the run.do_compile script, for me its at tmp/work/x86_64-linux/curl-native/8.1.2-r0/temp/run.do_compile
jpanisbl has joined #yocto
zpfvo has quit [Ping timeout: 246 seconds]
<rfs613>
yes, I see it sets LDFLAGS to pass -L flag... also I see a wrapper script that prefixes to LD_LIBRARY_PATH
pabigot has quit [Ping timeout: 252 seconds]
jpanisbl has quit [Quit: Konversation terminated!]
<yudjinn[m]>
running into a super confusing error. I have a job that should ONLY run when a large rebuild happens; I handled that by doing a check_breaking_change[depends] += " libgcc:do_compile ". Now, locally, this works as expected. but my CI uses SSTATE from an NFS mount, and this task runs (incorecctly) even when it doesnt need to rebuild that job. I can even go through the logs and see that libgcc only uses a setscene. I'm at a loss, as I've been
<yudjinn[m]>
trying to resolve this for weeks
Kubu_work has joined #yocto
<rburton>
yudjinn[m]: how do you define a large rebuild? how does that [depends] do what you want?
<yudjinn[m]>
rburton: so I have a task in my image recipe that runs only when libgcc is recompiled. I basically want to have this run ONLY when it it fully recompiled (like changes were detected in libgcc). Otherwise, If it's just using the cached one (because I made a change in something downstream of libgcc), the task should not run. My understanding was that if bitbake detected no changes, it would run a `do_compile_setscene` instead of a `do_compile`
<yudjinn[m]>
so the task wouldnt run
<yudjinn[m]>
edit: it runs a do_package_setscene not do_compile_setscene; the do_compile task is nowhere in my log, but it still runs that task that depends on do_compileh
adrianf has quit [Quit: Leaving]
manuel1985 has quit [Ping timeout: 246 seconds]
<rburton>
yudjinn[m]: do_compile vs do_compile_setscene is an internal thing and unrelated to what you're trying to do.
<rburton>
the tasks form a graph and if sstate is present chunks can be removed, so an image from sstate will just do libgcc:write_package_rpm and skip out the actual compile
Kubu_work has quit [Ping timeout: 245 seconds]
adrianf has joined #yocto
<rburton>
yudjinn[m]: whats the use case for 'run a task in an image if libgcc was rebuild in this build run'? what if libgcc was build in a previous build?
<rburton>
like the user did bitbake zlib; bitbake theimage
mckoan has quit [Read error: Connection reset by peer]
Kubu_work has joined #yocto
mckoan has joined #yocto
<yudjinn[m]>
rburton: so I provide swupdate images as well as rpm repos, but I manage whether or not an image can use one or the other based on if something "breaking" (I defined as libgcc) has occurred. So this is expected to happen if, say, we update gcc version/recipe -> causes bitbake recompile -> run this `check_breaking_change` task; else, anything downstream (say, networkmanager), wouldnt cause this task to run
<rburton>
that sounds fragile and hard to actually detect
<yudjinn[m]>
its more my attempt at saying "if you HAD to rebuild gcc, this SHOULD be set as a swupdate update, not an rpm".
<rburton>
what if someone else builds libgcc and your image pulls the sstate
<yudjinn[m]>
The only thing that has write access to that sstate is our master branch CI
<yudjinn[m]>
this task is almost entirely for making sure that certain version strings are correctly updated by the time they hit our initial "smoke test" CI jobs. If it detects you changed something that causes a rebuild, namely you made a change that caused a recompile of libgcc over the master sstate, then it requires you also bump a version in that PR. Otherwise, if you correctly updated the version, it still runs that task, but the result is just
<yudjinn[m]>
info saying "You did the right thing" rather than a bb.error
<rburton>
personally, sounds like you're trying to embed too much process into the details of the build. whether or not libgcc happened to be rebuilt in _this bitbake invocation_ shouldn't be deciding logic. i'm presuming if the pipeline fails then the builds sstate is thrown away, right?
<yudjinn[m]>
correct, but once it hits master, it is fully rebuilt and is the new "master"
<rburton>
i suggest you rethink your process, not sure how you'd even be able to know that libgcc:do_compile happened in _this build in particular_ from another recipe, ignoring the details about how fragile that is and needs a very specific build/sstate setup
zpfvo has quit [Ping timeout: 245 seconds]
<rburton>
i guess you could make libgcc:do_compile drop a file in the build tree somewhere and look for that, but i'm not sure how you'd be sure it wasn't a stale file (you could expect a clean build tree every run, but again, fragile)
<yudjinn[m]>
what do you mean? If i made no change for an MR, it would setscene the entire image. If I made a change to a recipe that was downstream of libgcc, this specific task doesnt run. if its upstream -> causes a recompile due to dependency rebuild. If that happens, if version is correctly updated -> no error; else, error
<yudjinn[m]>
but once that is merged, that becomes the new sstate. so new MRs just rerun the logic
<yudjinn[m]>
and its "technically" not just gcc. we also have a task-depends of linux:do_compile; so as we change KConfigs, this also throws an error if we dont correctly set it as a breaking change in the FS.
rfuentess has quit [Remote host closed the connection]
florian has joined #yocto
zpfvo has joined #yocto
cperon has quit [Remote host closed the connection]
zpfvo has quit [Remote host closed the connection]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
mckoan is now known as mckoan|away
Kubu_work has quit [Quit: Leaving.]
pbsds has joined #yocto
alessioigor has quit [Quit: alessioigor]
ptsneves has quit [Ping timeout: 260 seconds]
amitk_ has joined #yocto
alessioigor has joined #yocto
alessioigor has quit [Client Quit]
alessioigor has joined #yocto
alessioigor has quit [Client Quit]
amitk_ has quit [Remote host closed the connection]
gsalazar has quit [Ping timeout: 246 seconds]
tlwoerner has quit [Ping timeout: 246 seconds]
PhoenixMage has quit [Remote host closed the connection]
florian has quit [Ping timeout: 246 seconds]
tlwoerner has joined #yocto
manuel1985 has joined #yocto
prabhakarlad has quit [Quit: Client closed]
cb5r has joined #yocto
nerdboy has quit [Ping timeout: 246 seconds]
Thorn has joined #yocto
Thorn_ has quit [Ping timeout: 246 seconds]
amitk has quit [Ping timeout: 245 seconds]
nerdboy has joined #yocto
nerdboy has quit [Changing host]
nerdboy has joined #yocto
nerdboy has quit [Remote host closed the connection]