<yocton>
Xogium: What we need to fix this are clear and precises steps (which files to change, which bitbake commands) starting from scratch. I know this is not quick to do. I'm also curious to see if you can reproduce this problem from scratch.
camus has quit [Read error: Connection reset by peer]
camus1 has joined #yocto
camus1 is now known as camus
<Xogium>
yocton: I'll try again. But mostly what I've done is as you did yesterday, but I built the stompduck machine before then
<Xogium>
so I tried a stompduck build, found it was working, then decided to copy that machine into a stompduck2.conf file and to modify it there... And the issue started
<Xogium>
but maybe my tree has gotten something in it, or my build tree has a problem... I will try again from scratch
<derRichard>
maybe it's only me but the faq on kas reads a lot like handwaving
vladest has quit [Ping timeout: 264 seconds]
<kanavin>
there's no way kas is at all realistic, I agree with that at least
<frieder>
derRichard: I agree (having only read the FAQ point for now)
Vonter has quit [Ping timeout: 246 seconds]
<kanavin>
we'd have to basically rewrite kas, and break all backwards compatibility
<kanavin>
and it isn't clear if kas upstream is going to be interested or helping, in all likelihood they won't
Vonter has joined #yocto
<frieder>
kanavin: Can you elaborate on that? Why would kas need to be rewritten? Why would the kas community not be interested?
<derRichard>
it
<kanavin>
because it needs to integrate with all existing code in bitbake and oe-core, and not be a self-contained, isolated thing it is now. It also needs to drop all the opinionated, idiosyncratic ways it does build config management.
<derRichard>
's just that my clients *love* kas so much and *hate* setting up yocto with passion
<kanavin>
if they love kas, they can continue to use kas. They are not the target audience for this project, rather users new to yocto are.
<derRichard>
but you don't you love it? ;-)
<derRichard>
it just works
<kanavin>
I don't love it, at all. Bloated mess.
<frieder>
kanavin: I've been using Yocto for about 10 years and I love kas, too. So what?
<Xogium>
hmm what is wrong with it ? Honestly asking. I haven't read thefaq or anything yet. I just used it in setting up the simplest-yocto-setup repo from bootlin, and I mean, as far as I'm aware it did fine with that task ?
prabhakarlad has quit [Quit: Client closed]
<Xogium>
*the faq
<kanavin>
Xogium, I tried to give an answer above.
alessioigor has quit [Quit: alessioigor]
<kanavin>
'just works' is not good enough
alessioigor has joined #yocto
<frieder>
kas does indeed provide a user-friendly way to interact with Yocto without needing to deep-dive into the system. And I agree that this is not what everyone wants/needs. But it is what the majority of everyday users benefit from.
<Xogium>
tbh I just used it with kas checkout ;) that is the only command I've actually used from it
<kanavin>
it's not that it works. It's that we can't have it as official way to set up builds for multiple reasons.
<Xogium>
so what to use then, if not kas ? I'm not against manual setting up of repositories, far from it. But what if you want a somewhat easier way for users to just get started with your things ?
<derRichard>
and adding missing features to kas was impossible?
<frieder>
kanavin: That's ok, though I don't really see/understand these reasons, yet.
<kanavin>
that's the gap we're aiming to fill. The tools to set up layer repos are in master. The tools to handle build configurations are in master. What isn't there is a high level interface that ties it all together in a single ui.
<frieder>
Still we will be promoting/using kas as setup tool and any alternative from the OE community will likely not be interesting for us at all.
<kanavin>
we who?
<frieder>
Kontron Electronics and our customers
<kanavin>
frieder, you should at least evaluate the official tooling, because people will ask you about it, and 'we don't know' is not the answer
<kanavin>
derRichard, kas needs to be largely rewritten, it's not about missing features
<derRichard>
kanavin: hmmm.
<derRichard>
does the official tooling have a tool such as kas-container?
pvogelaar has joined #yocto
<frieder>
kanavin: We evaluated the tools a year ago and decided in favor of kas. We will evaluate again if kas fails to meet any upcoming requirements and our enough of our customers ask us for alternatives.
<frieder>
kanavin: This won't happen as our customers only care if the tools are easy to use and work for their purpose.
vladest has joined #yocto
<kanavin>
derRichard, official tooling doesn't cover that yet: the UI to tie the specific pieces together into a single command doesn't exist yet.
<kanavin>
frieder, can you specify what you evaluated?
<jclsn>
JPEW: If I want to set BB_ENV_EXTRAWHITE in the pyrex.ini, I have to use envvars, right?
<derRichard>
i can only say what i have evaluated, so far every single customer was in need for a tool to setup/start a yocto build with a single command (and config file!) in a deterministic environment (e.g. a container). kas gives us all of that.
<kanavin>
yes that is a gap in the official offering. but saying 'we'll continue to use kas' is not helping to close that gap.
<frieder>
derRichard: Same here!
<derRichard>
kanavin: "kas sucks and needs a rewrite" does not help either, IMHO.
<kanavin>
I mean, if you seriously want to elevate kas to official status, you need to get buy-in and a promise to help from its maintainers, and you need to read RP's proposal and make a technical plan to make it happen. And find developer resources for all of it.
<kanavin>
As things are, we're better off coming up with our own proof of concept, which can be done quicker and easier, and then gradually develop it into a full-featured solution.
<kanavin>
if kas users don't want to help, that's ok, but please don't gaslight the effort like you do here.
<derRichard>
nobody want's to gaslight, no need to worry. i just fail to understand why kas is not an option. and yes, i read rp's mail. anyway, i better go to lunch, i start to get hangry ;-)
<kanavin>
derRichard, I don't understand why the reasons I listed aren't clear to you.
<frieder>
kanavin: You are misjudging our intentions. We don't want to gaslight and if you think this is the way to go that's totally fine.
<frieder>
kanavin: It's just that we don't really understand why kas can't be promoted to be official Yocto/OE tooling.
jmiehe has quit [Quit: jmiehe]
<frieder>
I will read RP's mail in its full length and maybe I get a better understanding.
<kanavin>
I suppose you better write a response there. I'd also advice against writing and sending it hastily: let the draft sit in your mailbox for at least 24 hours. The subject is very touchy, and the 'why not kas' question the most likely to result in a flamewar.
<frieder>
kanavin: "We will continue to use kas" is what I say because that is what is likely going to happen in our case. But anyone can do as they want and I won't argue against alternative efforts if people decide they are needed.
pvogelaar has quit [Quit: Client closed]
<kanavin>
frieder, the target audience is really users which are new to the project. We can't put kas in the official documentation until it's maintained under the yocto project umbrella, and for that to happen, all of the thigs I listed (or tried to) above need to happen. It's just more effort than actually building a proof of concept from official pieces that already exist.
<kanavin>
frieder, on the other hand the core project funding and resources are extremely limited. Everyone likes to use yocto (and derive an income from that), very few people care about sustainability of it.
prabhakarlad has joined #yocto
<frieder>
kanavin: I totally understand these points.
DvorkinDmitry has joined #yocto
<kanavin>
(I mean, care to the degree that they actively contribute
<DvorkinDmitry>
In order to build I have to copy the uw-imap recipe from the Kirkstone
<JaMa>
dunfell is almost out of support but there is still time to send a fix :)
Ad0 has quit [Ping timeout: 255 seconds]
<kanavin>
I can't wait to see dunfell users realizing it's out of support and they have a mountain of tech debt to clear to move forward to a newer yocto.
<frieder>
kanavin: The problem is the timing. Now that kas is kind of established in many cases, it will be very hard to compete with when providing an official tooling alternative.
Ad0 has joined #yocto
<frieder>
kanavin: And this will increase the gap between the communities as there are even less people who care about the sustainability of the official tooling when they use only kas and contribute to kas.
<kanavin>
frieder, we're not aiming to compete with it in established projects. The target audience is primarily users new to yocto. The idea is that over time there'll be enough of those to make the official tooling self-sustaining - and it gets a boost merely by being provided out of the box, and being documented in yocto docs (kas is neither).
* derRichard
returns less grumpy
<frieder>
kanavin: The problem is that people like our customers (being new to Yocto) don't look into the Yocto docs first. First they ask us (the hardware vendor) or look at our docs and we will tell them to use kas primarily.
<frieder>
Or rather "hardware and BSP vendor"
<derRichard>
while chewing my meal, i thought about what i don't understand. i can see that kas does not fulfill all your current requirements. but what i don't get is why it's less work to implement your own tooling instead of embracing kas.
<frieder>
kanavin: So in the end, because of kas' existing "share" in the "market" you will compete with kas anyway, like it or not.
<kanavin>
derRichard, embracing kas is not just declaring it 'official'. I just told frieder and I guess I have to repeat: We can't put kas in the official documentation until it's maintained under the yocto project umbrella, and for that to happen, all of the thigs I listed (or tried to) above need to happen.
<kanavin>
And we need agreement and support from kas upstream as well, which is highly unlikely, as we basically never interact with them. They're their own bubble.
<derRichard>
so, it's politics.
<frieder>
kanavin: Not having interacted with them in the past is barely a good reason for not interacting with them in the future...
<kanavin>
frieder, derRichard if you want to help, then reach out to them please
<derRichard>
this surprises me, jan (the kas maintainer) is very open and friendly. i will talk to him about this. maybe the bubble get merged :-D
<kanavin>
point him to RP's email then
<derRichard>
kanavin: didn't you talk to jan at ELCE 2023? both of you had talks on yocto tooling.
<kanavin>
derRichard, we never discussed the subject because it didn't exist back then. What I mean is that they're rarely if ever seen on the mailing lists, or here.
<kanavin>
or rather it existed as a long term aspiration, nothing more than a bullet point
<derRichard>
interesting.
* derRichard
reaches out to jan
<kanavin>
frieder, the point about vendors imposing things on their customers is fair. But customers do have their own minds too, and they may ask you to support official tooling, and not include anything 3rd party in the offer.
<frieder>
kanavin: Yes customers might ask this. Customers might ask a lot of things. But believe me, most of our customers ask about features, bugs and results, but not about tooling.
<kanavin>
and then they hire folks like me to sort the mess vendors created for them with the tooling and configurations.
<frieder>
kanavin: And from there point of view basically everything they use is third-party. They don't care if there is one institution/community more or less involved.
<kanavin>
it pays money, but isn't fun
<frieder>
kanavin: I now these kind of jobs. And we are doing as much as we can to avoid downstream vendor mess.
otavio has joined #yocto
<frieder>
s/now/know
<kanavin>
I have to add that kas per se is rarely the source of the vendor mess, although it does things that would never be accepted in yocto upstream (and what to do with those features is another difficult question).
<kanavin>
build configuration management (rewriting local.conf in opinionated ways) is one such
ptsneves has joined #yocto
<Xogium>
yocton: so, whatever this was, I can't reproduce it anymore. I have no clue what this was about. I did everything from scratch again, built stompduck2 first and it worked. I also tried building stompduck first then building stompduck2, and it worked too. I think whatever went wrong, I atomized it when I removed the entire build dir
<Xogium>
the weirdest thing is that before then it was consistent
<Xogium>
either there's just that one thing that make it fail, whatever it is, or it's an issue that can show up but so intermitantly that it is virtually impossible to debug it
lexano has joined #yocto
<JaMa>
is there easy way to list all inherits (not INHERIT variable) with bitbake-getvar or bitbake -e? I'm trying to check "WARNING: Recipe.inherits: recipes-webos-ose/luna-service2/luna-service2.bb: length 262 exceeds maximum (255), truncating" from layerindex
<yocton>
JaMa: We used bb.data.inherits_class('ptest', d)
<yocton>
JaMa: ...and I misread your question sorry. (You wanted "with bitbake-getvar or bitbake -e")
<JaMa>
yocton: that doesn't give me the list of inherrited unless I walk over all bbclasses listed in BBINCLUDED (or listing only those in BBINCLUDED which exist (as it shows them in all possible layers))
<JaMa>
yocton: I guess I need __inherit_cache
jmiehe has joined #yocto
Xagen has quit [Ping timeout: 276 seconds]
<JaMa>
will have to look at layerindex code as list created from BBINCLUDED as well as __inherit_cache gives me 551 chars and global INHERIT list is less than 150 chars, so it doesn't match with 262 shown in warning
<RP>
derRichard: FWIW I've an open mind about kas. If we were to talk to them, the first question would be "what are we looking for?" or "how would kas need to change?". The proposal therefore makes the logical first step. We wouldn't want to be accused of trying to subvert an existing tool :/
<JaMa>
moto-timo: if you're going to update the model for recipe-subdirectory, can you bump the lenght of inherits in https://git.yoctoproject.org/layerindex-web/tree/layerindex/models.py#n475 as well? this is what triggered that warning in last layerindex update: env.luna-service2.__inherit_cache.py | xargs
GNUmoon has quit [Remote host closed the connection]
rcw has joined #yocto
GNUmoon has joined #yocto
<Siecje>
Is there a good starting point for building for the RaspberryPi Compute Module 4?
<derRichard>
meta-raspberrypi?
marka has quit [Ping timeout: 240 seconds]
vmeson has quit [Ping timeout: 268 seconds]
<JPEW>
jclsn: No, that one (along with BB_ENV_PASSTHROUGH_ADDITIONS) is special cased in pyrex
<rburton>
Siecje: if you're using the Pi CM in a commercial sense, it would be good to tell the Pi foundation this. if they have more customers using it with yocto then they might actually support it.
<Siecje>
rburton: Will do!
frosteyes has joined #yocto
<frosteyes>
Hello folks. A small question. I am working on Kirkstone, and having a new kernel (6.6) where I would do a populate_sdk on a image. It fails with "Error: Problem: conflicting requests - nothing provides /usr/bin/make needed by kernel-devsrc"
jatedev has quit [Quit: Client closed]
<frosteyes>
It seems that the reason is that in newer kernel, the debian package part is split up with a seperate "rules" file in scripts/package/debian
<frosteyes>
I guess kernel-devsrc somehow include the packing part for debian
<frosteyes>
Would you recommend a sed in kernel-devsrc do_install like the patching for the python stuff
<frosteyes>
Or should we add "make" RDEPENDS
vmeson has joined #yocto
<moto-timo>
JaMa: I’m less worried about warnings at the moment. We see a lot of truncation warnings. But I can take a look.
<moto-timo>
Field length impacts the size of the database storage…
goliath has quit [Quit: SIGSEGV]
zeddii has quit [Ping timeout: 252 seconds]
<moto-timo>
frieder: if kas works for your needs, by all means keep using it. Folks that like using repo tool are also welcome to keep using that. But, fundamentally, we need a tool in bitbake itself to do the layer setup.
jatedev has joined #yocto
<derRichard>
moto-timo: why does bitbake itself need this?
<derRichard>
...this was the frist wtf that came up in my head while reading the mail on tooling
zeddii has joined #yocto
<moto-timo>
derRichard: because that is where all the low level support for layers lives in the first place. It is also where tools like bitbake-layers and the code to interface with the layerindex rest api lives.
vladest has joined #yocto
<moto-timo>
derRichard: there is nothing political here. This is a fundamental problem we have been kicking down the road for many years now and it is precisely the bike shedding about other tools that has prevented us making any headway. But the proposal will in no way break any existing tooling. In fact, plugins to support kas and repo tool and git submodules have already been taken into consideration
<derRichard>
moto-timo: but this makes a "single command to setup/build" approach almost impossible.
<moto-timo>
derRichard: we are not trying to create one ring to rule them all.
<derRichard>
but this is what users want, this is why kas is much loved.
<moto-timo>
derRichard: I have given talks about using kas. I use it a lot. I have maintained projects with repo tool, git submodules and even combolayer. I understand the strengths and weaknesses of all of them.
<derRichard>
moto-timo: i didn't question your competence. sorry for that if you had such a impression. just from my experience a tool like kas is missed most by the kind of yocto users i come across.
<moto-timo>
derRichard: many of us have recommended kas and I have setup many customers with kas if they had nothing else (or something horrible).
<rburton>
man i've got about 8 hours of backchat to read here
rfuentess has quit [Remote host closed the connection]
prabhakarlad has quit [Quit: Client closed]
linfax has quit [Ping timeout: 260 seconds]
Xagen has joined #yocto
<kanavin>
rburton, or just jan's statement on oe-architecture
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<derRichard>
exactly :-)
mckoan is now known as mckoan|away
vladest has quit [Remote host closed the connection]
vladest has joined #yocto
jmd has joined #yocto
wooosaiiii1 has joined #yocto
rcw has quit [Remote host closed the connection]
wooosaiiii has quit [Ping timeout: 252 seconds]
rcw has joined #yocto
wooosaiiii1 is now known as wooosaiiii
sakman has quit [Ping timeout: 260 seconds]
rcw has quit [Remote host closed the connection]
RobW has joined #yocto
ederibaucourt has quit [Ping timeout: 252 seconds]
ederibaucourt has joined #yocto
Ad0 has quit [Ping timeout: 260 seconds]
simonew has joined #yocto
zpfvo has quit [Remote host closed the connection]
goliath has joined #yocto
florian has quit [Quit: Ex-Chat]
<simonew>
Hi, I have a question, say I want to "adopt" a package from meta/conf/distro/include/maintainers.inc. I was thinking about libseccomp or gnutls, to keep them up2date... What would be the prereqs? I'll accept a no of course as well
simonew has quit [Quit: Client closed]
simonew has joined #yocto
simonew22 has joined #yocto
simonew22 has quit [Client Quit]
<kanavin>
simonew, there are no prereqs, other than you acting in a timely manner with version updates (we run a bot called AUH twice a month that checks upstreams if they made new releases, and it can also send you a patch if the update is trivial)
simonew78 has joined #yocto
simonew has quit [Ping timeout: 250 seconds]
simonew78 is now known as simonew
<simonew>
Ok, so I would like to try if this is fine. I would just send a patch then to add myself there and take care of the recipes :)
<simonew>
About AUH I am aware
Ad0 has joined #yocto
<simonew>
Just one thing still: timely manner means? 1d / 3d/ 7d?
Siecje has quit [Remote host closed the connection]
<kanavin>
simonew, two weeks I'd say, as that's how often AUH runs. if you are subscribed to oe-core list, you've seen its output
xmn has joined #yocto
<simonew>
Jep, saw it. Ok, then I would just try, if thats ok
<kanavin>
sure, please do
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<simonew>
Ok, thx for answers I have sent a patch to make it "real" ;D
khazakar has joined #yocto
florian_kc has joined #yocto
sakman has joined #yocto
<kanavin>
simonew, cheers. if there are other already assigned recipes you're particularly interested in, you can ask the current maintainers if they'd like to hand them over.
frieder has quit [Remote host closed the connection]
Haxxa has quit [Quit: Haxxa flies away.]
Haxxa has joined #yocto
Minvera has quit [Remote host closed the connection]
sakman has quit [Read error: Connection reset by peer]
rcw has joined #yocto
goliath has quit [Quit: SIGSEGV]
RobW has quit [Ping timeout: 252 seconds]
<simonew>
Ok, I will first see how it goes with those 2 :)
<moto-timo>
simonew: thank you for helping out
ptsneves has joined #yocto
sakman has joined #yocto
jmd has quit [Remote host closed the connection]
<khem>
if anyone is brave enough and has compute cycles, I have put together a gcc-14 branch, although we wont be shipping gcc-14 in next release, but it will run on distros which will be built using gcc-14 e.g. f40 and so on, so it will be good to weed out package issues that we may run into for native nativesdk etc.