<brimonk>
Hey all, I'm having trouble getting curl dev libraries on my output meta-toolchain, and I think I need to add a DEPENDS (+)= somewhere, but I honestly have no idea.
<brimonk>
While I'm a noob to all things yocto and bitbake, I think I've got a frankenstein'd repo with the poky and meta-ti repos smashed together. When I run 'bitbake meta-toolchain' to build my toolchain, the output toolchain doesn't contain libcurl, which is a dependency of what I'd ACTUALLY like to build with the toolchain. How can I add libcurl, with headers and libs to the output toolchain?
devious has quit [Quit: Client closed]
perdmann has quit [Ping timeout: 268 seconds]
perdmann has joined #yocto
amitk has joined #yocto
sakoman has quit [Quit: Leaving.]
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
perdmann has quit [Ping timeout: 272 seconds]
nemik has quit [Ping timeout: 255 seconds]
perdmann has joined #yocto
nemik has joined #yocto
perdmann has quit [Ping timeout: 240 seconds]
perdmann has joined #yocto
pbsds has joined #yocto
alessioigor has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 244 seconds]
nemik has joined #yocto
alessioigor has quit [Quit: alessioigor]
perdmann has quit [Ping timeout: 276 seconds]
perdmann has joined #yocto
Schlumpf has joined #yocto
goliath has joined #yocto
perdmann has quit [Ping timeout: 272 seconds]
perdmann has joined #yocto
xmn has quit [Ping timeout: 260 seconds]
davidinux has joined #yocto
mckoan|away is now known as mckoan
<mckoan>
good morning
ptsneves has joined #yocto
dacav has quit [Quit: leaving]
Schlumpf has quit [Quit: Ping timeout (120 seconds)]
jclsn has joined #yocto
jclsn has quit [Client Quit]
goliath has quit [Quit: SIGSEGV]
vladest has quit [Quit: vladest]
vladest has joined #yocto
manuel_ has joined #yocto
perdmann has quit [Ping timeout: 244 seconds]
perdmann has joined #yocto
bluewhale has joined #yocto
mvlad has joined #yocto
bluewhale has quit [Quit: Client closed]
Schlumpf has joined #yocto
perdmann has quit [Ping timeout: 272 seconds]
<mckoan>
I have a variable MYVAR ?= "1" defined in local.conf, how can I override its value from command line doing MYVAR="0" bitbake imagename ?
<LetoThe2nd>
brimonk: AIUI adding it to TOOLCHAIN_HOST_TASK should do the trick
goliath has joined #yocto
<mckoan>
LetoThe2nd: thanks, the syntax is totally unclear though
<mckoan>
at this point is probably clearer use a 'sed' command to replace the line
jclsn has joined #yocto
jclsn has quit [Client Quit]
<LetoThe2nd>
mckoan: no example to be found? we've used it at my old company for sure.
<qschulz>
mckoan: patches welcome to the documentation :)
<ptsneves>
:D
<ptsneves>
BB_ENV_PASSHTHROUGH is evil. just pass bitbake -R extra.conf or something
<ptsneves>
it achieves the same
<ptsneves>
if i would start a holy war in Yocto like vim/emacs it would be about BB_ENV_PASSTHROUGH
<qschulz>
mckoan: IIRC it's a space separated list of environment variables that can be passed from your shell to inside recipes
<LetoThe2nd>
I would say, it really depends on the specific setup.
perdmann has quit [Ping timeout: 260 seconds]
perdmann has joined #yocto
bluewhale has joined #yocto
manuel__ has joined #yocto
manuel_ has quit [Ping timeout: 244 seconds]
florian has joined #yocto
bluewhale has quit [Ping timeout: 252 seconds]
denisoft81 has joined #yocto
Herrie|2 has joined #yocto
Dracos-Carazza has quit [Quit: ZNC 1.8.2 - https://znc.in]
Herrie has quit [Ping timeout: 256 seconds]
Dracos-Carazza has joined #yocto
Herrie|2 is now known as Herrie
mrnuke_ has joined #yocto
mrnuke has quit [Ping timeout: 256 seconds]
bluewhale has joined #yocto
perdmann has quit [Ping timeout: 240 seconds]
kayterina[m] has quit [Quit: You have been kicked for being idle]
perdmann has joined #yocto
<mckoan>
ptsneves: nice idea, thanks
<ptsneves>
@mckoan the -R extra.conf has 2 benefits: You can generate them as a K="V" from some kind of script even from env variables. The other is that you have access to BITBAKE keystore to compose those variables. This is often not possible by passing env variables, and ugly hacks have been written to get bitbake datastore stuff(like paths) to the shell so it can be passed back into bitbake
yannholo has joined #yocto
<ptsneves>
s/keystore/datastore/g
<LetoThe2nd>
ptsneves: that is indeed a neat side effect, thanks for bringing it up!
<ptsneves>
LetoThe2nd: Thanks. Extra one, you can track the extra.conf standalone in a version control system if needed.
<yannholo>
Hello, short version : What would be the technique to change a configuration file for a recipe depending on an image ?
<yannholo>
Long version : I already build two images (prod and dev), It is quite easy to add tools on the dev image (for ssh access & cie). But I can't seams to find the way to simply update a configuration file (/etc/x/x.conf) depending on the image... My approach until now has been to apply patches to recipes, but I don't think that can handle input from images. What is the keyword I should google to find my answer ?
<LetoThe2nd>
yannholo: building a debug distro. an image is a recipe, and therefore cannot affect another recipe. simple as that. recipe data is local.
Xagen_ has joined #yocto
Xagen has quit [Ping timeout: 255 seconds]
<yannholo>
LetoThe2nd: Very well, I will look into that, I guess I took the image approach because KAS allow to build 2 images in a single cmd line. Nothing a script can't handle.
mrnuke_ has quit [Ping timeout: 244 seconds]
<LetoThe2nd>
yannholo: well it can be two different images also. but the key part really is yocto chant #1: recipe data is local, configuration data is global.
<qschulz>
yannholo: depending on your layers and recipes, you could technically have two conf recipes
mrnuke has joined #yocto
<qschulz>
one with conf1 file and another with conf2 file
<qschulz>
and then in image1 you IMAGE_INSTALL conf1 and in image2 conf2
pbsds has quit [Quit: Ping timeout (120 seconds)]
<yannholo>
qschulz: I was thinking about that before coming here but it seams more like a hack than the clean way to do it ?
pbsds has joined #yocto
<qschulz>
yannholo: it depends what this configuration file is for
<qschulz>
but I think it's an okay approach
<qschulz>
compared to the cost of having two distros, it's a good compromise
<yannholo>
qschulz: The use case right now is to configure mosquitto to only accept connections from localhost in the production image
<qschulz>
yannholo: mmmm this feels like you want a debug image and a production image
<qschulz>
s/this/it/
<jclsn[m]>
Do you know any good tutorial for getting good with device trees? I am still overwhelmed by them
<qschulz>
and you'll want to have more differences later on I believe, so going for distro makes sense now even though the cost is now high for that small difference
<LetoThe2nd>
The key thing to think about is if you want to do the recipe split-duplication for how many instances. In real life, the dev-prod image topic is often tackled through a combination of means.
<LetoThe2nd>
Read: everybody starts out with "it is only that one tiny modification"
<yannholo>
qschulz: Yeah that's already the case but until now I only needed to install or not some recipes, images worked fine
<qschulz>
jclsn[m]: I know Thomas from Bootlin did a Device Tree for Dummies talk/presentation some years back
<qschulz>
jclsn[m]: and they have a Device Tree 101 thingy right now
<yannholo>
LetoThe2nd: I agree, I will take a closer look at distros and try to do it cleanly
<ptsneves>
@yannholo If your changes between prod and dev can be packaged differently then you can include special packages in your dbg image. If you want recipes to have build steps that are different than the distro as mentioned is the way to go
<RP>
ptsneves: why would that become a holy war?
<yannholo>
ptsneves Right now both approach would work for me, it is a "simple" file substitution, learning how distro seams to be the way to go for future developments
<jclsn[m]>
<qschulz> "jclsn: I know Thomas from..." <- That was actually the first Bootlin video I ever watched. Unfortunately it doesn’t dive deep into the syntax.
<qschulz>
jclsn[m]: what are you struggling with exactly?
<jclsn[m]>
I also read the introduction by NXP. I am still clueless. I wonder why no one puts comments in the source files…
<jclsn[m]>
I need to replace the MIPI-DSI controller for our board. The imx8mm uses the adv7535 and we one from TI. We had all of this done by GPV previously, but u-boot-imx has changed quite a bit since 2019
<jclsn[m]>
There is a port@1 and port@2 now, which I don’t ger
<jclsn[m]>
Yeah need to read the specification, but it is not very beginner-friendly
<rburton>
RP: so the RC1 failed in reproducible
<jclsn[m]>
Patience young padawan
<RP>
rburton: kernel host gcc issue?
<qschulz>
jclsn[m]: try to read the dt-bindings in the Linux kernel too
<qschulz>
for mipi-dsi controllers, and panels, etc..
<ptsneves>
yannholo: IIf it is only one file you can create a separate recipe for each and use the appropriate package in each of your images.
<yannholo>
I don't want to be rude but as a noob, looking at "Distro Features" and "Image Features" I instinctively would go with a prod/debug image instead of prod/debug distro. (I guess the approach is to have debug distro + debug image)
denisoft81 has quit [Remote host closed the connection]
<rburton>
RP: yeah likely. all in the kernel, at least.
<ptsneves>
RP: Because in my experience people love env vars and will not accept the -R syntax. I am amazed at the lack of desire to learn in our industry, and learning a new switch of bitbake and how .confs work is often too much for devops guys.
<RP>
rburton: should be clear from the diffoscope output?
<RP>
ptsneves: why would that make it a war though? The syntax exists and works?
<ptsneves>
RP: it was a figure of speech :)
<qschulz>
yannholo: patches to the documentation very welcome :)
<LetoThe2nd>
yannholo: not rude at all. I know that it is the usual way to start out, but... "things are complicated". as qschulz said - documentation patches, or tutorial content is appreciated.
<qschulz>
yannholo: the thing is, most of us contributing to the project don't have the beginner eye anymore so it's not easy to write docs for things you (usually) understand
<ptsneves>
RP: It works until somebody tries to add another env variable and not understand why it works. BB_ENV_PASSTHROUGH is obscure from my PoV
<qschulz>
jclsn[m]: but yeah, that's basically the point where you have to dig in or get contractors to do the work for you :/ Many areas aren't as well documented as they could be in the kernel
<rburton>
RP: i wasn't paying attention to this earlier when it came up. surely it should just be using the cross gcc, so that's a relatively easy fix?
perdmann has quit [Ping timeout: 272 seconds]
perdmann has joined #yocto
<RP>
rburton: no, it is using the host's gcc for retpoline generation
<RP>
rburton: we basically need to filter that option out our generated confs
<rburton>
not sure i want to know why the host compiler is used for that
<RP>
rburton: it is used to build a tool which is used when compiling
<rburton>
ah, ok, that makes more sense
<jclsn[m]>
<qschulz> "jclsn: but yeah, that's basicall..." <- I really want to understand all of that. Guess I will have to be patient
<rburton>
kanavin: i forgot to copy anuj 🤦♂️
<rburton>
RP: going to jfdi and add a pretty minor testimage for -rt to the autobuilder
<rburton>
RP: turns out jonmason has it in his personal gitlab CI for poky and it's been working fine for him for ages
<RP>
rburton: has what in his personal gitlab?
<RP>
oh, rt?
<rburton>
yeah, a testimage using the -rt config
<ptsneves>
RP: agreed. I actually had once somebody adding machine (lowercase) to the env whitelist and funny things happened :D
<RP>
rburton: I wish he'd sent something for the autobuilder ;-)
starblue1 has quit [Ping timeout: 268 seconds]
starblue1 has joined #yocto
ardo has quit [Read error: Connection reset by peer]
ardo has joined #yocto
seninha has joined #yocto
florian_kc has joined #yocto
<jclsn[m]>
Ah the device tree 101 is new. That seems to dive deeper. I will watch that
zpfvo has joined #yocto
<rburton>
RP: so i looked at some of the lttng ab-int issues and i'm 80% convinced that they're a bug in the ptest runner or processing. some of logs that are reported as failing are all successes
<RP>
rburton: hmm. Any leads we could work on to track down what is breaking?
<RP>
rburton: I'm sure we have seen failures :/
<rburton>
there are failures, but i'm sure there are false-positives too
<rburton>
got some ideas, but the lttng-tools test run takes forever!
<rburton>
kernel does a load of probing and comes up short
<rburton>
might be qemu options missing, might be probes which should fail quietly
<RP>
rburton: you could just put them in the ignore list
<rburton>
i feel icky putting apparently meta-arm specific ignores in oe-core
<RP>
rburton: that list should be layer/machine extensible
<rburton>
pretty sure i own the bug to implement that
<rburton>
need to think about how to do it
<RP>
rburton: get on with it then! :)
<RP>
rburton: there are probably a few options, a variable, a file etc
ruslan has joined #yocto
sotaoverride has quit [Ping timeout: 276 seconds]
<yannholo>
LetoThe2nd: The youtube live coding was helpfull
<yannholo>
qschulz LetoThe2nd ptsneves: Thanks for your help. I ended up creating a second distro. I am not yet hugely satisfied on my understanding on distro/image responsibilities split but it works :-)
<ptsneves>
yannholo: congrats :)
Schlumpf has quit [Quit: Client closed]
<LetoThe2nd>
yannholo: \o/
xmn has joined #yocto
<RP>
rburton: (and anyone else interested) care to take a look at master-next and see what you think of the debug prefix mapping changes I'm pondering
<RP>
rburton: merging S and B for debug source purposes shouldn't matter?
<jonmason>
the point of me doing gitlab on poky is really to give me an easy CI before pushing. I was getting too many "this breaks on other platforms"
* RP
doesn't quite know if the commit order is right but it does explain the changes better. I'm also torn on making it work for the kernel or not
<rburton>
RP: going out for a bit, will look after
nemik has quit [Ping timeout: 244 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
vladest has quit [Ping timeout: 272 seconds]
<ThomasRoos[m]>
Is there any document or rule that say what patches, recipe upgrades get backported (and when) to kirkstone and dunfell? And how this is performed (git cherry pick, merge, rebase...)
<ThomasRoos[m]>
<LetoThe2nd> "Thomas Roos: anything beyond..." <- this is good - thank you!
<ThomasRoos[m]>
So the patches that go into kirkstone are probably cherry-picked from master if they are ok to the mentioned rules I guess?
<RP>
ThomasRoos[m]: correct
marc1 has quit [Quit: WeeChat 3.5]
camus has quit [Quit: camus]
kscherer has joined #yocto
alejandrohs has quit [Ping timeout: 260 seconds]
alejandrohs has joined #yocto
mihai has joined #yocto
<ThomasRoos[m]>
<RP> "Thomas Roos: correct" <- How often is this done? What about dunfell?
<RP>
ThomasRoos[m]: people propose patches to the LTS maintainer and he makes a decision. Same for dunfell
sakoman has joined #yocto
<RP>
If they don't apply cleanly, people propose a patch
<ThomasRoos[m]>
ok, thank you!
SDes91 has joined #yocto
jpmlima has joined #yocto
<jpmlima>
Hello there
<jpmlima>
i have a question
<jpmlima>
is it possible create a recipe that clone from github to my custom image?
<jpmlima>
an alternative to copy tarball ?
<RP>
jpmlima: git:// urls work in SRC_URI
jpmlima_ has joined #yocto
jpmlima has quit [Ping timeout: 276 seconds]
perdmann has quit [Ping timeout: 268 seconds]
marc1 has joined #yocto
perdmann has joined #yocto
ptsneves has quit [Read error: Connection reset by peer]
ptsneves1 has joined #yocto
ptsneves1 is now known as ptsneves
SDes91 has quit [Quit: Client closed]
Guest92 has joined #yocto
Guest92 has quit [Client Quit]
ruslan has quit [Quit: Client closed]
<rburton>
jpmlima_: do you mean you want a git clone inside your image? just do a git clone, you'll need to enable networking in the task you do the fetch in though
goliath has quit [Quit: SIGSEGV]
<RP>
rburton: I got rid of the kernel bits for now as that caused a few too many issues
yannholo has quit [Remote host closed the connection]
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
yannholo has joined #yocto
zpfvo has quit [Remote host closed the connection]
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
yannholo has quit [Quit: Leaving]
yannholo has joined #yocto
tlwoerner__ has quit [Quit: Leaving]
tlwoerner has joined #yocto
<RP>
khem: I've stopped your meta-oe build as it would end badly, it needs to be restarted given I fixed master-next
<rburton>
RP: can we get the gcc fix from khem into next? it's a good fix for zephyr builds
<vvn>
hi there -- what is the proper way to remove systemd services such as deprecated the initrd-udevadm-cleanup-db.service and systemd-udev-settle.service?
<RP>
rburton: it is now in -next
<rburton>
RP: thanks
<RP>
rburton: any thoughts on that package change?
<rburton>
yeah sorry, back now and will look
<rburton>
RP: so the debug path searching using the prefix map is a good idea, but we could cleanup bitbake.conf by using file-prefix-map (which sets debug- macro- and profile-). might be worth looking for all *-prefix-map arguments
<rburton>
also i'd be tempted to replace flag = flag.split("=");prefixmap[flag[1]] = flag[2] with "flag,old,new = flag.split('=') and catch whatever exception happens if it doesn't split perfectly. clear what the entries are for, and you can give a nice message. current code will just throw an exception
<RP>
rburton: we can't since things like as in binutils ignore file-prefix-map :(
<RP>
rburton: I tried that
<rburton>
can't *yet*, right?
<RP>
rburton: well, I don't know if anyone is sorting the patches
<RP>
rburton: good point on the flags
<rburton>
dare i ask why gcc-runtime needs its own slew of prefix-maps?
<RP>
rburton: see later patch?
<rburton>
ha
<rburton>
series needs a reorder? :)
<RP>
rburton: I'm not sure that'd help. I was trying to capture some of the history
<rburton>
"shouldn't be source references in WORKDIR that isn't S and B either." BRAVE ASSERTION
<RP>
rburton: autobuilder is testing this
<rburton>
i bet something breaks, but i'm fairly sure you could consider that to be a bust recipe
<RP>
rburton: right, if core is ok we'll call recipes broken ;-)
<RP>
rburton: we have to at least try
<rburton>
i like patches which remove code, so that looks sensible to me on the whole
<RP>
rburton: I'm just a bit nervous about changing a core part of the system like this
<rburton>
well, yes
<rburton>
do a image build with and without, with any luck the result will be binary identical anyway
<RP>
rburton: things do change as more source appears in /usr/src/debug
<RP>
but I wanted that!
<RP>
layout of /usr/src/debug changes slightly too
<rburton>
sure, most things should be identical though hopefully?
<RP>
rburton: I'd hope! :)
<RP>
alejandrohs: could you try your externalsrc use case with the patches in master-next, see if these work there?
denisoft81 has joined #yocto
ptsneves has quit [Ping timeout: 268 seconds]
amitk has quit [Ping timeout: 240 seconds]
mckoan is now known as mckoan|away
manuel_ has joined #yocto
manuel__ has quit [Ping timeout: 272 seconds]
<rburton>
zeddii: just sent a perf reproduciblity fix. don't ask!
<zeddii>
python2! I'm warming up the tar
<RP>
zeddii: can I provide feathers? :)
<rburton>
seriously, i want to burn this sublayer with chemical fire
<rburton>
5.4!
<RP>
rburton: you have to wonder why we need fdebug-prefix-map=${STAGING_DIR_NATIVE}
<rburton>
yeah
<rburton>
at least now you can rip it out and see what barfs
<RP>
rburton: current -next appears to have signs of green builds
<RP>
sadly every time I tweak this, it is a total rebuild of everything
<RP>
zeddii: lttng-modules then explodes with unpackaged kernel source files
<RP>
zeddii: I think I've convinced myself doing this is the wrong thing to do
<RP>
If anyone would like a simpleish bug to fix, "bitbake bc; bitbake bc -C compile" breaks
<RP>
and the fix isn't flex-native
goliath has joined #yocto
<jpmlima_>
is it possible to create recipe that clone some repo from github to image directly?
jpuhlman_ has joined #yocto
jpuhlman is now known as Guest5207
Guest5207 has quit [Killed (tungsten.libera.chat (Nickname regained by services))]
jpuhlman_ is now known as jpuhlman
nemik has quit [Ping timeout: 272 seconds]
nemik has joined #yocto
jpmlima_ is now known as Johnny_da_pi
<Johnny_da_pi>
is it possible to create a recipe that clone some repo from github to image directly?
nemik has quit [Ping timeout: 272 seconds]
nemik has joined #yocto
prabhakarlad has quit [Quit: Client closed]
florian has quit [Quit: Ex-Chat]
perdmann has quit [Ping timeout: 260 seconds]
perdmann has joined #yocto
florian_kc has quit [Ping timeout: 260 seconds]
jsbronder has quit [Ping timeout: 264 seconds]
Johnny_da_pi has quit [Quit: Leaving]
jsbronder has joined #yocto
perdmann has quit [Ping timeout: 240 seconds]
perdmann has joined #yocto
yannholo has quit [Remote host closed the connection]
GNUmoon has quit [Ping timeout: 268 seconds]
florian_kc has joined #yocto
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
GNUmoon has joined #yocto
prabhakarlad has joined #yocto
perdmann has quit [Ping timeout: 268 seconds]
perdmann has joined #yocto
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
<frosteyes>
hey folks. Have anyone of you tried to ues the native libs for some native unittest and then seen issues when wanting to debug it?
<frosteyes>
I have a small test app, where I change the sysroot to be the sysroot/x86_64-distro-name/ - e.g. the native part and then it select the /libstdc++.so.6 from this
perdmann has quit [Ping timeout: 276 seconds]
<frosteyes>
a test variable there is defined as vector<string> ambu_msg {"Hello", "from", "clst"};
<frosteyes>
instead of just std::vector<std::string>
<frosteyes>
and printing the variale also fails.
<rburton>
frosteyes: why do you need to change the sysroot? sounds like you're doing something wrong
florian_kc has quit [Ping timeout: 268 seconds]
<frosteyes>
It was a way to get access to the libs from native part instead of using the normal root of the system. E.g. instead of /usr/lib set systemroot to /opt/yocto/sdk/version/sysroot/x86-64-distroname/
perdmann has quit [Ping timeout: 272 seconds]
<frosteyes>
so it select the libs from the yocto to link with.
<frosteyes>
But I just become a bit wiser
<frosteyes>
there is no pretty printers installed in gdb when the libstdc++ version from the yocto SDK is loaded
<frosteyes>
Where the ubuntu provided one have pretty printers installed in gdb when it is loaded.
perdmann has joined #yocto
<frosteyes>
don't know so much about pretty printers in gdb - must be my next place to investigate..