04:05 <NishanthMenon> javierm_: sorry about the tardy response, been stuck with some workshop here.. glad you got wifi up and running :)

04:08 <NishanthMenon> generic brainstorming question to the community: we have been trying to use yocto to test upstream (master, next etc).. from the feel, yocto vs arch vs debian sid - are there any preference and pros or cons that folks can think of? i am a bit more partial to debian sid.. I am thinking about beyond just linux kernel or base components to userspace stacks: upstream tip of mesa etc.. thoughts?

04:10 <NishanthMenon> gaah.. disclaimer on the above note: ^^ above is trying to rethink an easier to put together full stack configuration for upstream testing.. our product base: no change (yocto etc..)

04:11 <NishanthMenon> rcn-ee: ^^ ;)

05:38 <javierm_> NishanthMenon: IMO yocto is good to build images for vertically integrated appliances but for testing I prefer to use an image built from distro packages indeed

05:39 <javierm_> NishanthMenon: using tools such as https://github.com/go-debos/debos

05:39 <NishanthMenon> javierm_: yeah.. somewhere along my thought process.. ideally a distro default component should "just work". and we just deal with putting an image together - like how armbian does..

05:40 <NishanthMenon> yeah - debos or armbian stuff kind of lines up.. but arch folks are arguing with me that sid is slower than arch ;) ...

05:40 <javierm_> NishanthMenon: yeah, and if the component doesn't need customization, then there's really no need for you to built it and could just leverage the distro package

05:41 <javierm_> NishanthMenon: if you are going to argue about distros, I of course would suggest Fedora :)

05:42 <javierm_> but seriously, I think that Fedora finds a good balance between tracking the latest upstream projects but while also trying to be stable

05:42 <NishanthMenon> rofl../me is dumb: do we have a bleeding edge fedora fork.. i am keeping my mind open about the distro.. at least to weigh pros and cons

05:43 <javierm_> my experience with rolling release distros such as arch is that its too bleeding edge

05:44 <javierm_> NishanthMenon: but maybe that's an advantage for testing to find issues early :)

05:45 <NishanthMenon> yeah - that was the point.. ahead of stable distros (even the "latest stable" ones)..

05:45 <NishanthMenon> flip side: too often broken ... we are already facing that in our yocto attempts :(

05:46 <javierm_> yeah...

05:58 <NishanthMenon> Another community question: hypothetical question: if we start a public meeting for folks to directly talk with TI team on opensource: Provide overview of what TI did for previous month and what will happen for next month then Q&A to get issues / opinions - would folks be interested?

08:53 <pivi> NishanthMenon: we do this kind of integration testing using OE master branches, and on top of it we do integrate current mainline U-Boot and Linux. It breaks a lot, on the other hand this is fine, since we do want OE to work for us, so we fix bug also there

08:54 <pivi> NishanthMenon: the trouble is that you are testing all at once, sometime is overwelming and we endup letting it rot because of other priorities. This recently happened with the change in U-Boot requiring new packages for the capsule update, we were able to fix it on our side only yesterday

08:56 <NishanthMenon> pivi: you HIT exactly my org's pain. I am trying to see if there are alternatives to optimize cost of testing upstream here (ofcourse) by looking for a distro that tracks the key upstream components (in effect spread the cost of maintenance) as we'd like - without bringing that pain in the path of "production target" distros. looking at the record of issues that ryan has fixed on our end (probably duplicated effort on your

08:56 <NishanthMenon> end). intent is to try and lower the cost of fixing yocto and other distros by piggy backing on a "prebuilt" package group that we assemble only.

09:44 <pivi> NishanthMenon: I do not think there is much duplication, we do sent fixes upstream, wherever we found them. unless you do bbappend ;-)

09:44 <NishanthMenon> pivi: been a bit of a while since i dug at oe.. :(

09:45 <pivi> BTW, we do have a way to mitigate it. We endup building various combination. for example we build our stable branches with the git tip of stuff we integrate and the other way around

09:45 <pivi> this way we achieve some decoupling

09:46 <pivi> what we are not doing, but probably we should, would be to integrate the latest OE release and not master

09:46 <pivi> so far we are tracking the LTS and master tip, with nothing in between

09:47 <NishanthMenon> yep.. we are on master.. :( - kernel, u-boot etc, we test with master and next.. (varied success rates)

09:51 <javierm_> NishanthMenon: anwwering your question about public meetings with the TI team - I think is a great idea and I see lot of people joining on a monthly cadence

09:53 <javierm_> NishanthMenon: another thing I saw other orgs to do that IMO is quite useful info is to publish a blog post with what the team has done in the last month / Linux kernel release

10:00 <NishanthMenon> aah yes, we are working towards https://timinds.blogspot.com/ https://www.youtube.com/@timinds-nt9nr as the venue - (still pending TI internal hurdles approvals - so please take the links with a pinch of salt atm).. (if folks dont like timinds - blame khasim ;) )..

10:01 <NishanthMenon> javierm_: any links will be helpful (I know of the bootlin and baylibre ones :D )

10:17 <javierm_> NishanthMenon: those were exactly what I was thinking, also collabora

10:17 <NishanthMenon> true.. :)

10:18 <javierm_> NishanthMenon: https://www.collabora.com/news-and-blog/news-and-events/kernel-67-new-year-new-linux-kernel.html for example

10:18 <NishanthMenon> aah thanks :)

10:19 <javierm_> NishanthMenon: exactly! That's why is exciting :)

10:19 <NishanthMenon> hehe.. lets see how this plays out :)

10:20 <NishanthMenon> i have also privately reached out to more folks.. lets see how it pans out.. will keep the channel posted..

10:24 <javierm_> NishanthMenon: great, thanks a lot for the heads up

10:24 <NishanthMenon> javierm_: is there any other way to do it? :) thank you for collaborating with us

10:26 <javierm_> you are welcome :)

13:29 <bryanb> do we need to keep it to one distro?

14:04 <bryanb> many of these distros are great at different things. buildroot for brining up a new board, arch for bleading edge packaging, debian for stability, and they all package things differently which in my opinion increases testing coverage ;)

15:51 <NishanthMenon> it is a cost optimization - i would really love to do all the distros - but i look at it 15+ years of sustained system..

19:12 <khilman> imo, also depends on what the focus of your testing. If you're focused on testing kernel, u-boot, boot firmware, etc., then you don't want the distro to get in the way, or be changing rapidly, so distro stability is really important. This is why in KernelCI we picked debian.

21:47 <NishanthMenon> khilman: we are finally able to achieve the place where mesa zink etc will start to matter.. (it is kinda cool to be have the challenge in the first place.. dont ever remember getting to that level at TI before in upstream) - that is where we are thinking.. ok how do we make sure this entire thing does'nt bitrot - because some day in a decade or so, we wont be here to guide this specific platforms around..

21:49 <NishanthMenon> libcamera hopefully should one day follow suite.. and hopefully... (fingers crossed) openCL... or what ever ....

22:24 <javierm_> NishanthMenon: as a distro developer I'm happy to hear that you are thinking of leveraging the integration work that's done by distributions, regardless of what distro you choose

22:24 <javierm_> I guess the main question is about cadence and stability

22:26 <NishanthMenon> javierm_: yes - distros are what real people use :) .. yes stability vs usability.. upstream testing for me is to expose in-stability so that "product distros" can spend less effort on stability - but we want to expose it only on areas that are at risk.. problem is the space spread varies based on individual platforms.. (some dont care about libcamera, and some dont even have display support)..

22:27 <javierm_> NishanthMenon: yeah, and some distros are more x86-centric while for others aarch64 is a first class citizen

22:28 <NishanthMenon> oh yes.. BUT, embedded (note - i am respectful of industry and not locking this down to aarch64 even though my products are aarch64) had always had to scratch our way up ;)

22:28 <javierm_> indeed