<RP>
sveinse: yes, you need to find which task hashes change
<RP>
rburton: two stap failures in one build now. There is a qemuarm64 on that failed in 30s so this may be something different but it was on an arm host with kvm so may just happen faster
<coldspark29[m]>
Can someone tell me what imx-boot is needed for? I am currently trying to bump our Yocto version to hardknott and when packaging the .wic, bitbake is missing imx-boot. The NXP user guide says it is SPL + U-Boot etc. so I guess it is the bootloader image. We are building our own bootloader though. Can't find a way to turn this off as dependency.
<dacav>
Hi. As mentioned a few days ago, I've got problems in building the SDK (due to a broken third party). I've been suggested to work with `bitbake -c devshell ...`, which effectively gives me a way out. I'm unfortunately missing a few tools. For example, gdb is present, but has wrong prefix (aarch64-none-elf-gdb). On the other hand, gcc exists with the correct prefix.
<dacav>
Doing `bitbake-layers show-recipes` presents only `gdb-cross-aarch64`, which I executed, with no success. Any suggestion?
salutfdp has joined #yocto
<qschulz>
coldspark29[m]: hardknott is soon EOL, I'd suggest starting to work on master so that once kirkstone is out you're ready
<qschulz>
or dunfell
zpfvo has quit [Ping timeout: 268 seconds]
<coldspark29[m]>
qschulz: What about honister?
zpfvo has joined #yocto
<coldspark29[m]>
The NXP document doesn't even mention honister yet.
<qschulz>
coldspark29[m]: honister is EOL in May
<qschulz>
coldspark29[m]: whata re you upgrading from?
<coldspark29[m]>
gatesgarth
salutfdp is now known as salutlesbg
<qschulz>
coldspark29[m]: hardknott is EOL in March
<qschulz>
coldspark29[m]: what do you use from NXP?
<qschulz>
it seems you don't use their bootloader
<coldspark29[m]>
Some NXP layers don't even have an honister branch yet
<qschulz>
coldspark29[m]: you don't necessarily need vendor BSP layers is all I'm saying
<qschulz>
it depends what your needs are
<coldspark29[m]>
meta-freescale, meta-freescale-3rdparty and meta-freescale-distro
<coldspark29[m]>
Not sure if I need all of them though
<coldspark29[m]>
qschulz: But I need the NXP kernel I guess
<qschulz>
coldspark29[m]: it's a simple recipe so you can just copy that recipe (or create one that is heavily stripped down from theirs, if bloated) in your meta layer
<qschulz>
I've always tried to not use vendor BSP layers if possible
<qschulz>
taking only what I need
zpfvo has quit [Ping timeout: 268 seconds]
<agherzan>
RP: we have a kirckstone next branch. Is it fair to assume that it will follow master branch for a good while until we branch off for the release?
<coldspark29[m]>
qschulz: I don't think that I am experienced enough to do that
zpfvo has joined #yocto
tnovotny has joined #yocto
<coldspark29[m]>
We have our custom board based on an imx8mm chip
<coldspark29[m]>
I probably should create our own custom layer, but for now we just use the NXP layers and throw out what we don't need
<dacav>
`devtool build-image` -> how does it know what image to build? I usually have to tell it explicitly to bitbake (e.g. `bitbake my-image`)
<landgraf>
dacav: looks so: config.set('SDK', 'sdk_targets', d.getVar('SDK_TARGETS')). give it a try :)
manuel1985 has joined #yocto
<coldspark29[m]>
qschulz: Why is it bad if a Yocto branch is EOL? Isn't just the buildsystem?
<coldspark29[m]>
In the end I am more dependent on the BSP releases from my chip manufacturer, am I not?
<dacav>
landgraf: where should I write that (python?) line?
<dacav>
also, a colleague mentioned to me that `devtool build-image` allows for an argument with the image name. This is not mentioned in the inline help ...but it seems to work.
<dacav>
but still, where should I put this kind of lines?
mariusz1 has quit [Ping timeout: 250 seconds]
mariusz1 has joined #yocto
zpfvo has quit [Ping timeout: 268 seconds]
zpfvo has joined #yocto
<coldspark29[m]>
@qschulz: I tried with master now and now all layers are not compatible
zpfvo has quit [Ping timeout: 245 seconds]
<landgraf>
dacav: you should not. this is the way how it's set. What are you trying to achieve?
zpfvo has joined #yocto
<qschulz>
coldspark29[m]: no security fixes once the release is EOL
<qschulz>
coldspark29[m]: you're dependent of your vendor currently because of their vendor BSP layers, hence why I suggested to not use vendor BSP layers but take only what you need. Which takes more time in the beginning for sure, but frees you from your vendor
<qschulz>
it's not always easy nor fast, especially when you need GPU/VPU/IPU/whatever custom weird IP they use
<coldspark29[m]>
qschulz: Do you think that is doable for a newbie? I am new to the company and need to provide some results
<coldspark29[m]>
I haven't come much further than booting the old configuration
<coldspark29[m]>
Is there any guide you can recommend to do that?
<qschulz>
coldspark29[m]: it's the age old question of immediate results but more difficult maintenance and taking time now for easier maintenance long term
<qschulz>
you can see already that you have a vendor lockin for now
goliath has joined #yocto
<qschulz>
It might be just as easy as copying the recipes you need in your layer
<qschulz>
you'll learn a few things while debugging stuff as well
<coldspark29[m]>
qschulz: I see that point and I am definitely with your there
<coldspark29[m]>
qschulz: But would I not have to do that for every release again? NXP changed quite a lot from gatesgarth to harknott already. I would have to copy the recipes every time. Else I would duplicate all the work NXP does in their layer. I don't see how that will save me work.
<coldspark29[m]>
* harknott already and I coudn't even figure out how to port that yet. I
<qschulz>
sorry, let me put more ocntext in my message
<coldspark29[m]>
I am super confused now
<qschulz>
You said you had an issue upgrading to more recent version of Yocto because of meta-freescale layers
<coldspark29[m]>
Yes
<qschulz>
but meta-freescale seems to be supporting whatever
<qschulz>
same for meta-freescale-3rdparty and meta-freescale-distro
<qschulz>
or did I miss some messages and got confused?
kanavin has joined #yocto
<coldspark29[m]>
No that is basically it.
<qschulz>
aaah this imx-boot stuff I remember, my bad
<coldspark29[m]>
What I am doing atm is checking out the freescale stuff and then copy some things over to my custom layer if they need adjustment
<coldspark29[m]>
That is already hard enough
<coldspark29[m]>
But you are telling me to write my own layer somehow
<qschulz>
there's almost no way you don't need a layer
<coldspark29[m]>
I am not able to create BSP layers myself yet
<qschulz>
be it for an image recipe
<coldspark29[m]>
I am quite discouraged now
<qschulz>
I kinda made it hard and confused you so no worries
<qschulz>
So.. the initial issue was "my vendor BSP layer is not supporting hardknott" (or more recent)
<qschulz>
but it seems that the three layers you mentioned all have their own hardknott branch
<qschulz>
and there's an imx-boot recipe in meta-freescale
<coldspark29[m]>
Well the freescale-ml doesn't, but we don't need that actually
<qschulz>
(also, as far as I remember, meta-freescale is community maintained, not a vendor BSP layer per se)
<qschulz>
meta-imx is the vendor BSP layer I think. Anyway :)
<coldspark29[m]>
Freescale is NXP
<qschulz>
yes that I know
<coldspark29[m]>
NXP took them over
<qschulz>
meta-rockchip is community maintained
<coldspark29[m]>
So what do you mean by vendor bsp now? I am even more confused now
<qschulz>
basically... My point being. There is a difference between vendor BSP layer and just BSP layer
<qschulz>
BSP layer is usually fine
zpfvo has quit [Ping timeout: 256 seconds]
<qschulz>
vendor BSP layer, not so much (and they might not allow external contribution either)
<qschulz>
so, try to make meta-freescale work as is, if it does nto, you can always ask question/support on the mailing list (or here?) and we can help. We don't really provide help for vendor BSP layer though
<qschulz>
anyway.. I kinda messed up my answers to you and made it more difficult to understand than it should have been
<qschulz>
so.. let's work on fixing this meta-freescale thingy
rperier has joined #yocto
<qschulz>
so let's start from the beginning and forget the last 30min :D
zpfvo has joined #yocto
<coldspark29[m]>
I already deleted all of my hardknott progress because you told me it was EOL
<qschulz>
1) did you make sure all of your layers are on the same branch (seems to be hardknott for you, though it'll be EOL soon but the process is the same for other branches)
<qschulz>
2) what is the exact error you're having?
<coldspark29[m]>
qschulz: Sure, I only need to fix my custom layer
<coldspark29[m]>
But if hardknott is so old, I might as well go honister. Especially for the syntax change. That was my initial plan, but then my colleague said I should go with the NXP documents.
<qschulz>
(openembedded-core is "embedded" in poky FYI)
<coldspark29[m]>
So I don't need meta-openembedded if I already have poky?
<qschulz>
no, different things
<qschulz>
meta-openembedded is NOT openembedded-core
<coldspark29[m]>
Okay
<coldspark29[m]>
I want to verify that rust is still there
zpfvo has quit [Ping timeout: 250 seconds]
zpfvo has joined #yocto
<qschulz>
if you have something that depends on rust, you'll know soon enough if it's not there
<rburton>
RP: so yeah running the stap test case by hand has resulted in a hang
<coldspark29[m]>
Okay it is in ./poky/meta/recipes-devtools/rust
zpfvo has quit [Ping timeout: 250 seconds]
zpfvo has joined #yocto
<RP>
rburton: at least you can reproduce I guess :)
<coldspark29[m]>
qschulz: So far we have our own meta-custom layer and our own custom machine type in there, because we have our own board based on an imx8mm chip. Then I copy all the required files over from meta-freescale and make our changes. Is that good practice or not?
<coldspark29[m]>
If not, now is the time to do it differently. I want to use the best habits from the start
risca has quit [Quit: No Ping reply in 180 seconds.]
risca has joined #yocto
<qschulz>
keep meta-freescale
<qschulz>
if something's wrong you can contribute to it or get support from the community
<coldspark29[m]>
Sure, but I need to create my own machine configuration I guess
<qschulz>
yes, in your own layer
<coldspark29[m]>
Yeah
<coldspark29[m]>
And then I start off with the imx8mm-lpddr4-evk.conf and the corresponding kernel and make my changes
<coldspark29[m]>
I will see how far I get and the write you again
<qschulz>
coldspark29[m]: you can have your own machine conf file which requires imx8mm-lpddr4-evk.conf in it
<qschulz>
so you don't need to duplicate everything
<qschulz>
(if it makes sense, I didn't check)
leon-anavi has quit [Ping timeout: 256 seconds]
Schlumpf has quit [Ping timeout: 256 seconds]
<salutlesbg>
has anyone ever tried to use meta-linaro? can't build anything using the official tags (morty, sumo, warrior, zeus...)
leon-anavi has joined #yocto
<rburton>
you've listed a lot of very old releases
<rburton>
what are you building, for what versions, and what is the error?
<rburton>
salutlesbg: ^
Vonter has quit [Ping timeout: 256 seconds]
<salutlesbg>
i'm trying to build for armhf, using arm gcc 8.3
zpfvo has quit [Ping timeout: 268 seconds]
<salutlesbg>
looks like zeus is the version i look for
zpfvo has joined #yocto
<rburton>
zeus is very old, and we recommend you upgrade
<zeddii>
the class was removed from core. your local.conf is just needs to be udpated.
<coldspark29[m]>
Updated how? When I remove it I get another error
<zeddii>
just remove it fro the USER_CLASSES, whatever error you have next, I can't say .. but you defnitely have to remove it from that variable if you are in a branch where it has been removed (It was removed ~may 2021)
<coldspark29[m]>
Guess the local config layout has changed in honister?
<zeddii>
yep
sakoman has joined #yocto
<coldspark29[m]>
Any idea why bitbake is complaining about the old override syntax here? https://pastebin.com/D35Exg5q
<coldspark29[m]>
It is inside poky so no idea why that happens
<qschulz>
coldspark29[m]: can we get the error message maybe?
<coldspark29[m]>
ERROR: /home/user/Workspace/Yocto-Workspace/vti2/sources/poky/meta/recipes-graphics/wayland/weston-init.bb: Variable do_install_append_mx6 contains an operation using the old override syntax. Please convert this layer/metadata before attempting to use with a newer bitbake.0:41
<coldspark29[m]>
ERROR: Failed to parse recipe: /home/user/Workspace/Yocto-Workspace/vti2/sources/poky/meta/recipes-graphics/wayland/weston-init.bb
<coldspark29[m]>
There is no do_install_append_mx6 in that recipe
<qschulz>
coldspark29[m]: did you checkout ALL your layers to a honister branch?
<coldspark29[m]>
Yep
<qschulz>
poky included?
<coldspark29[m]>
Yes
<qschulz>
did you check your bblayers.conf points to those up-to-date layers?
<coldspark29[m]>
Think it was my custom layer
<coldspark29[m]>
I ried to change the override syntaxes manually
<qschulz>
do_install:append:mx6
<coldspark29[m]>
I ran the change-overrides.py script over it and now it works
<coldspark29[m]>
Should have done that in the first place...
<coldspark29[m]>
Sorry
<qschulz>
it's alright don't worry :)
<coldspark29[m]>
Yeah but I want to work independently actually
<coldspark29[m]>
My colleague also says that I should look at the code rather than asking people, but Yocto is just a special kind of beast
<coldspark29[m]>
s/asking/ask/
<coldspark29[m]>
Compling now tumbs crossed
<qschulz>
coldspark29[m]: everybody starts one day, I still ask plenty of questions
<coldspark29[m]>
Who do you ask? You are the most active person here
<qschulz>
we know Yocto has a steep learning curve, you'll get there eventually. I was very lost at the beginning too, I'm doing better now :)
<coldspark29[m]>
Yeah but you know that bosses don't care
<qschulz>
coldspark29[m]: I read the code now more than I ask questions but I started like you
<coldspark29[m]>
They don't want to hear why or how it works or doesn't
<coldspark29[m]>
They want results
<qschulz>
your bosses didn't tell you to not ask the community :)
<qschulz>
We all struggled and still struggle to find the right balance between immediate results and learning things/doing them properly
<coldspark29[m]>
Well I have one colleague who knows more than me. He has been the sole base system guy of this company for years and has done everything by himself. He is just approaching stuff differently
<coldspark29[m]>
qschulz: Yeah and doing things properly is important. I am a big fan of that. I don't like to advance if I don't know what I am doing.
<coldspark29[m]>
But then I am slow...
<coldspark29[m]>
It was like this job I had as a sysadmin once. There were two of us and we were supposed to activate SSL for our servers. The other guy created the certificate online while I was working on certbot. He was done faster than me and my boss asked me why. Just stupid...
<coldspark29[m]>
😄
<qschulz>
I'm afraid to say this feeling of being slow hasn't disappeared yet, even if I'm more skilled than I was years ago. I don't have a recipe for feeling better unfortunately :/
<coldspark29[m]>
His approach would have to be repeated every year and mine was a one-time solution.
<coldspark29[m]>
s/one/long/, s/time/term/
<coldspark29[m]>
qschulz: Just act like it's French mentality or something. Should work in Austria ;)
xmn has joined #yocto
<qschulz>
just to be clear, I was saying I still feel slow today. No complaint from bosses. Just wanted to say that sometimes we feel/think things that aren't objectively true (and what is *slow* anyway?)
<coldspark29[m]>
Then that is just a character trait I guess. I am quite hard on myself as well. It also has advantages though.
Vonter has quit [Ping timeout: 256 seconds]
<qschulz>
Therapy helped me already with self expectations but yeah, it's hard to find a healthy balance
<coldspark29[m]>
I think most people are like it though ;)
<qschulz>
then it says more about our society than yourself :)
<qschulz>
anyways, I think our not-so-private conversation has spammed enough the chan :)
<coldspark29[m]>
qschulz: Well, you shouldn't see it as a defect. I have friends who think they are doing great, but their achievements fade in comparison.
<coldspark29[m]>
qschulz: Alright alright
<coldspark29[m]>
You can always PM me :)
zpfvo has quit [Ping timeout: 252 seconds]
zpfvo has joined #yocto
Vonter has joined #yocto
radsquirrel has joined #yocto
zpfvo has quit [Ping timeout: 268 seconds]
zpfvo has joined #yocto
salutlesbg has joined #yocto
Vonter has quit [Ping timeout: 250 seconds]
rob_w has joined #yocto
<RP>
coldspark29[m]: remember that the problem Yocto Project solves is complex. Would your bosses expect you to perform brain surgery tomorrow with no prior experience? Probably not. Some software problems are similar - skills take time to learn
Vonter has joined #yocto
<coldspark29[m]>
RP: Yes you are right. I guess I just have the same character trait as Quentin ;)
radsquirrel has quit [Quit: radsquirrel]
radsquirrel has joined #yocto
<LetoThe2nd>
yo dudX
goliath has quit [Quit: SIGSEGV]
<qschulz>
o/
TundraMan is now known as marka
rob_w has quit [Quit: Leaving]
<radsquirrel>
hi all. I'm trying to use mkimage/openssl/libp11/p11-kit in native context.
Schlumpf has joined #yocto
<radsquirrel>
The issue I face is that when mkimage runs and I tell it to use the pkcs11 engine, it looks for that in the openssl sysroot rather than the libp11 sysroot. I suspect that if I get past this issue, I'll run into it again when libp11 (provided by libp11) looks for the p11 kit proxy library (provided by p11-kit).
<radsquirrel>
Am I breaking new ground here or is this a solved problem?
<rburton>
there's only one sysroot when you actually run something
<rburton>
each recipe contributes a piece
<rburton>
if something is hard-coding a path to the build sysroot then that needs to be fixed up when the sysroot is used
<rburton>
typically, environment variables are used
<radsquirrel>
rburton:thanks...I'm still processing what you said :-)
<radsquirrel>
so I guess openssl should provide an env var for its search path for engine plugins?
<rburton>
if you grep for create_wrapper you'll find lots of wrapper scripts that are generated to do that
<radsquirrel>
rburton: good stuff, thanks for those hints.
zpfvo has quit [Ping timeout: 256 seconds]
zpfvo has joined #yocto
mariusz1 has quit [Ping timeout: 256 seconds]
florian has quit [Quit: Ex-Chat]
<rburton>
the basic problem is that some libraries hardcode their search paths
<rburton>
which doesn't work too well when you take those libraries and build a new sysroot with them
lucaceresoli has quit [Quit: Leaving]
<radsquirrel>
rburton that was exactly the hint I needed, thanks. if I wrap mkimage and specify OPENSSL_ENGINES I'm off to the races.
<radsquirrel>
I'll send a patch...
hpsy[m] has quit [Quit: You have been kicked for being idle]
akiCA has joined #yocto
codavi has joined #yocto
akiCA has quit [Ping timeout: 250 seconds]
<JPEW>
RP: For Yocto #14685, do you want a targeted "add a dependency on zstd" or a more general solution like we discussed eariler?
ctxnop has joined #yocto
<moto-timo>
michaelo: I'm also hoping to get to finishing the kernel-lab docs this week
<moto-timo>
michaelo: that takes a special "attention to detail" mindset to do it right
Vonter has quit [Read error: Connection reset by peer]
Vonter has joined #yocto
ctxnop has quit [Quit: Client closed]
goliath has joined #yocto
zpfvo has quit [Quit: Leaving.]
goliath has quit [Quit: SIGSEGV]
Schlumpf has quit [Quit: Client closed]
<RP>
JPEW: I think we'll need a general solution
<RP>
JPEW: this issue is just a symptom
<JPEW>
RP: OK
Tokamak has joined #yocto
mckoan is now known as mckoan|away
tnovotny has quit [Quit: Leaving]
<JPEW>
RP: I was trying to think if it was possible (or wise) to try and "roll down" the dependencies into the final task instead of having each intermediate change it's output based on dependencies... basically automate the process of making do_package_write_rpm depend on zstd instead of making rpm do it
<RP>
JPEW: I wondered about that but I think rolling them into the outhash is going to be the practical approach
<JPEW>
RP: K, I'll give that a go
<JPEW>
That doesn't somehow defeat hashequiv in some way I can't comprehend, does it?
<JPEW>
I don't *think* it would....
gsalazar_ has quit [Ping timeout: 240 seconds]
JaMa has joined #yocto
<JPEW>
I guess it's no different that if the dependency does actually change a recipe (e.g. header change or whatever), you'r just forcing it
Vonter has quit [Ping timeout: 240 seconds]
<ad__>
hi, i am in dunfell, getting a "multiple versions are due to be built" error, but i am setting the PREFERRED_VERSION, anyway, still getting the error. What can be wrong ?
jmiehe has quit [Quit: jmiehe]
mariusz1 has joined #yocto
frieder has quit [Remote host closed the connection]
<RP>
JPEW: I don't think so, it just adds a constraint (which we want)
<JPEW>
OK, I'll draft something up for that
mariusz1 has quit [Ping timeout: 250 seconds]
wooosaii has joined #yocto
leonanavi has joined #yocto
ziga_ has joined #yocto
ziga__ has quit [Ping timeout: 256 seconds]
leon-anavi has quit [Ping timeout: 256 seconds]
wooosaiii has quit [Ping timeout: 256 seconds]
sakoman has quit [Ping timeout: 256 seconds]
sakoman has joined #yocto
salutlesbg has quit [Quit: Client closed]
manuel1985 has quit [Remote host closed the connection]
manuel1985 has joined #yocto
florian has joined #yocto
<vmeson>
tgamblin: and vmeson are a bit flummox about cmake-native not building on a ubu-18.04.6 system whereas it works on 18.04.3
<zeddii>
speaking in the 3rd person, and using flummox .. two crimes, one statement
<vmeson>
symptom is: Error when bootstrapping CMake: Problem while running initial CMake in cmake-native do_configure in case anyone else is having similar issues.
<vmeson>
zeddii: you aren't flummoxed by stap still ?
* vmeson
runs
<vmeson>
anyway, if anyone else sees this let us know.
davidinux has quit [Ping timeout: 256 seconds]
<vd_>
which package provides sfdisk?
florian has quit [Ping timeout: 250 seconds]
<grembeter[m]>
util-linux
mauro_anjo has joined #yocto
<vd_>
thank you
mauro_anjo has quit [Client Quit]
mauro_anjo has joined #yocto
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
mauro_anjo has quit [Ping timeout: 256 seconds]
ziga_ has quit [Ping timeout: 250 seconds]
<RP>
Does anyone use TUNEABI_WHITELIST or TUNEABI_OVERRIDE ?
<RP>
Or TUNEABI for that matter
<RP>
vmeson: could you check if WR use these anywhere?
<vmeson>
RP I just did! There's no sign of it in our layers on master.
<vmeson>
s/it/them/
<RP>
vmeson: cool. It was seebs who added these but I know of no use of them anywhere so I think we'll just remove them
mvlad has quit [Remote host closed the connection]
<vmeson>
RP, makes sense I suppose, I did see seebs using it in email from many years ago.
<RP>
vmeson: If people need them, they can implement this in their layer now ;-)
<vmeson>
Nothing since 2015!
* RP
sends a nice deletion patch
<rburton>
RP: good news: systemtap upstream are fixing some issues i've found in debugging the problem
Tokamak has joined #yocto
florian has joined #yocto
Tokamak has quit [Read error: Connection reset by peer]
<RP>
rburton: that is very cool :)
Tokamak has joined #yocto
Tokamak has quit [Read error: Connection reset by peer]
florian has quit [Ping timeout: 250 seconds]
Tokamak_ has joined #yocto
Tokamak_ has quit [Read error: Connection reset by peer]
Tokamak has joined #yocto
Tokamak has quit [Read error: Connection reset by peer]
<kergoth>
its like wsl for mac basically, just with qemu under it instead of a vm. can run contianers under it also, though that has some limitations right now
amitk_ has quit [Ping timeout: 256 seconds]
Tokamak_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Tokamak has joined #yocto
florian has quit [Ping timeout: 250 seconds]
dmoseley has quit [Ping timeout: 256 seconds]
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]