**** BEGIN LOGGING AT Sun Apr 24 02:59:56 2022 Apr 24 17:18:26 zeddii: do you happen to be around? Apr 24 17:34:11 sakoman: kanavin_: hey, so I started looking at the mixin layers again -- https://git.yoctoproject.org/meta-lts-mixins/ -- because that seems like the recommended way to get newer kernel versions of older OE releases, but ... Apr 24 17:34:15 they layer seems dead Apr 24 17:34:23 denix: ^ Apr 24 17:34:46 would it make sense to plug it into AUH somehow, so it gets timely updates for example ? Apr 24 17:37:00 marex: to be honest I don't monitor that layer, so I can't say whether it is alive or dead! Apr 24 17:37:32 its dead all right Apr 24 18:08:17 marex: i don't think it's dead Apr 24 18:08:32 on jan 14 the 5.10 kernel was updated to 5.10.91 Apr 24 18:08:58 the latest commits were to the dunfell/go layer on feb 3 Apr 24 18:09:49 marex: perhaps a little neglected, but a bit early to call it dead Apr 24 18:10:28 sakoman: zeddii: denix: will 5.15 get a dunfell mixin branch? Apr 24 18:14:40 Am I the only one who really hates autotools, grrr. Apr 24 18:16:05 I am trying to fix this, https://bugzilla.yoctoproject.org/show_bug.cgi?id=14681, as gcc in the SDK fails when gcc plugins are used. Apr 24 18:16:22 tlwoerner: that's 21 linux-stable releases behind ... which is like hundreds of fixes that are missing Apr 24 18:17:03 oh, the usual gcc plugins issue, heh Apr 24 18:18:07 tlwoerner: it's impossible to measure demand for mixin layers. unlike kernel, my understanding that kanavin's go and docker layers were special-purpose one-off and won't be updated Apr 24 18:18:17 that is caused by https://github.com/gcc-mirror/gcc/blob/master/gcc/configure#L32124 Apr 24 18:19:14 since it ends in https://github.com/gcc-mirror/gcc/blob/master/gcc/configure#L32157, and -rdynamic is not added.. Apr 24 18:19:27 marex: kernel is up-to-date now - there were 7 update commits, 1 RT commit and 6 config fixes. I fell behind updating it, since there's no feedback Apr 24 18:20:19 denix: the mixin layer isn't great, so I keep linux-stable , mesa , mainline u-boot layer and just keep it up to date Apr 24 18:20:36 https://source.denx.de/denx/meta-mainline-common/-/commits/dunfell-3.1 here Apr 24 18:20:56 and I just keep rolling it forward using a script, there are users who need timely updates, so they consume that Apr 24 18:21:01 So I changed that check configure.ac, but for some reason configure isn't update. Which magic command do I need for that? Apr 24 18:22:09 denix: I would like to switch to something more upstream, but it seems the mixin layer isn't an option , because outdated all the time Apr 24 18:26:33 marex: unlike your own rolling linux-stable layer where you keep updating it often, mixin layer policy is to only take backports, i.e. zeddii's commits that propagated through other stable branches after some massaging due to different structure... Apr 24 18:27:27 denix: so the mixin kernel layer would take linux 5.10 (.0) and then take backports from linux-stable which is all backports of stable fixes to linux 5.10 anyway ? Apr 24 18:27:44 maybe I don't quite understand this policy Apr 24 18:28:36 sure, 3 months delay is my fault. but don't expect rolling updates. zeddii makes updates to 5.10 about once a month or even less - last update was over a month ago - March 22 Apr 24 18:29:03 those updates could be automated with a 10 line script or AUH Apr 24 18:29:12 I think oe-core does that already Apr 24 18:30:00 marex: backport policy is due to testing - only commits that went into oe-core master are being tested, plus commits that went into stable branches like hardknott, honister, gatesgarth get some testing too Apr 24 18:32:23 denix: but we're not talking about oe-core here, the mixin layers are supposed to provide up-to-date software for older OE releases Apr 24 18:32:36 denix: does that mean the mixin layers are assembled from commits which are in newer oe-core releases ? Apr 24 18:34:06 marex: yes, check for yourself - https://git.yoctoproject.org/meta-lts-mixins/log/?h=dunfell/kernel Apr 24 18:34:49 since mixin layers don't have their own QA Apr 24 18:36:01 I see, I think I will stick to rolling my own then, it runs through multiple CI instances and it is kept up to date with linux-stable and mesa releases Apr 24 18:36:40 would it make sense to somehow have something more "rolling" more official ? Apr 24 18:36:52 marex: there's 5.10.112 already, but master has 5.10.109 and hardknott only has 5.10.107 Apr 24 18:37:43 yes, if you need the very latest "rolling", right now you have to do it yourself Apr 24 18:38:27 marex: how about adding dunfell branch to meta-linux-mainline? Apr 24 18:38:39 denix: what's meta-linux-mainline ? Apr 24 18:39:14 maybe you can offer paulbarker maintenance help with dunfell branch Apr 24 18:39:26 marex: https://sr.ht/~pbarker/meta-linux-mainline/ Apr 24 18:39:36 denix: oh, that, I tried talking to paul before, but it got nowhere Apr 24 18:40:46 it seems like there is demand then, everyone is rolling their own thing, none of it is really upstream Apr 24 18:44:49 heh, and everyone is calling it linux-stable_5.10.bb :) I thought you were using meta-linux-mainline at least, but apparently that's completely your own? Apr 24 18:48:52 marex: what's the demand for the very cutting-edge stable release? I can only see 2 reasons - a timely security fix or you are part of stable development Apr 24 18:55:57 denix: no, the layer I use actually predates the one from paul Apr 24 18:56:19 denix: paul apparently did something similar later Apr 24 18:56:27 also, the layer from paul is outdated too ... Apr 24 18:56:37 I dont see any reason to use it Apr 24 19:01:47 marex: yeah, I understand Apr 24 19:02:37 denix: and its not just kernel, I also have up to date mesa there, which is needed for various drivers Apr 24 19:03:12 marex: it all boils down to testing. sure, you can completely rely on kernel stable testing, but we've seen issues and platforms not booting with such updates in yocto QA Apr 24 19:07:11 denix: well could AUH and the QA help spot such bad updates and report/skip them ? Apr 24 19:07:24 that could all be automated, right ? Apr 24 19:14:49 marex: up-to-date url: https://github.com/unnecessary-abstraction/meta-linux-mainline Apr 24 19:15:53 marex: there are no official builds or tests for dunfell+5.10 at all, since Yocto QA is at the limit with existing builds and releases. ask RP about all the intermittent issues, mosly in ptest or qemu - that's why kirkstone had to be rebuilt and re-tested 3 times... Apr 24 19:32:52 oh well Apr 24 21:03:00 for what is worth, autoconf has an -f option, which seem to help.. Apr 24 22:31:13 marex: I have wanted to do more cutting edge testing but we struggle to have the people to monitor it Apr 24 22:32:52 RP: with that meta-mainline-common, I just let a couple of CIs chew on it and if something breaks, I just fix it and move on Apr 24 22:33:26 but all the users I am aware of are arm32 and arm64 Apr 24 22:33:47 marex: I have so many things I need to "just" fix already :/ Apr 24 22:34:59 RP: in case of that layer, I am talking about me fixing it Apr 24 22:37:48 marex: I think I was looking at the discussion from a different direction so I'll not go further :) Apr 24 22:38:21 * RP wonders why reproducibility builds are still failing on ubuntu1804-ty-3 Apr 24 22:39:29 I pushed https://github.com/victronenergy/openembedded-core/commit/59c3a48d1102d388858452a3b788fdc08291f02c (for dunfell) Apr 24 22:40:41 zeddii: you might like that, since it fixes a bug assigned to you, https://bugzilla.yoctoproject.org/show_bug.cgi?id=14681 Apr 24 22:46:11 RP: I guess I might just be willing to keep an eye on those builds, because, well, I already do anyway Apr 24 22:46:20 RP: that's all I'm trying to say Apr 24 22:47:09 marex: that is handy to know, I'll keep it in mind thanks. I would like to do something like than and I know some others would too Apr 24 23:00:01 RP: indeed **** ENDING LOGGING AT Mon Apr 25 02:59:56 2022