<zedd>
drop the series completely. that script misfired, and ran on the bbappend.
<zedd>
it's complete garbage.
<RP>
zedd: ah :/ I'd best stop that build too!
florian has quit [Ping timeout: 268 seconds]
<RP>
zedd: the update for the main recipe is also there, just missing the kernel_version
<zedd>
no. don't use any of them. I'll send a v2 later.
<RP>
zedd: ok
goliath has quit [Quit: SIGSEGV]
warthog9 has quit [Remote host closed the connection]
warthog9 has joined #yocto
jonah1024 has joined #yocto
florian has joined #yocto
florian has quit [Ping timeout: 252 seconds]
<paulg>
Good help is hard to find.
<marex>
paulg: was it you who was working on the linux 5.10.y and co. backports for dunfell ?
<marex>
I recall seeing such discussion before fosdem time here
<marex>
also, unrelated -- is there some way to speed up yocto-check-layer in CI setting ? it takes about as long as the whole build for me, is there some trick to that ?
<marex>
I basically want to make sure the layers dont start to pile up broken bbappends and such
<paulg>
marex, I did the 4.8, 4.12, 4.18 and 5.2 updates; things shuffled around that I didn't need to do v5.8 and we get v5.10 "for free" as an LTS from gregKH's team.
<marex>
paulg: so how does that work now ? I maintain my own repo with linux lts for dunfell (and u-boot too)
<marex>
and mesa
<marex>
paulg: I mean, the OE integration
<paulg>
marex, zedd grabs the stable updates from gregKH's team directly ; the versions I mentioned above had been declared EOL by gregKH but we (yocto) needed ongoing maintenance a little longer.
<marex>
paulg: I mostly care about 5.10.y anyway
<marex>
paulg: is there a metalayer or something ?
<marex>
paulg: so, yes, I know where to get the sources , I was asking whether there is some metalayer already
<marex>
paulg: if not, I'll stick to my own, which does exactly what I need
<marex>
it just seems like this is something that would be useful to others as well
<marex>
and I was under the impression there was some ongoing work to put these updated recipes upstream
<paulg>
you don't need any special anything if you just want vanilla v5.10.<latest> as zedd has that on v5.10/standard/base
<RP>
marex: you can get a plain mainline kernel out of the linux-yocto recipes
<marex>
RP: ah nice ... I must've missed it in oe-core/dunfell
<marex>
hmmm ... no, I only see 5.4.y there
<RP>
marex: sorry, I missed you were looking for this in dunfell
<marex>
RP: yep :)
<RP>
marex: I think denys is lookin at experimenting with that though, shouldn't be hard
<marex>
RP: so far I rolled my own layer, see above, with u-boot/linux/mesa and I think I will soon add gstreamer 1.18.y
<marex>
RP: I thought someone was looking into that too, but maybe it got nowhere
<paulg>
ah okay - I suck at code names ; also didn't realize dumbell was v5.4-only...
<marex>
paulg: well, I started adding version to the branch names because i was getting lost in it, hence the dunfell-3.1
<RP>
paulg: we're getting a ton of "complaints" that the LTS has been stable ;-)
<paulg>
so, no - AFAIK, I wasn't disucssing backporting the 5.10 recipe to releases that didnt have it by default - must have been someone else.
<paulg>
that said, I would expect it to largely be a drop in and maybe check for updates that landed in recipes-kernel/linux/linux-yocto.inc since 5.10 was added?
<marex>
RP: I wonder, would it be possible to put some of those updated recipes into contrib or something ?
<marex>
and that's another thing I was wondering about -- why not use stock linux-stable , why keep this linux-yocto with patches ?
<RP>
marex: sure, definitely possible. The TSC did also say they'd support the idea of mixin layers for exactly this kind of thing
sakoman has joined #yocto
<RP>
marex: you can select either from linux-yocto and some of these patches you appear to hate actually let us do things like the qemu testing so they do kind of help ;-)
<marex>
RP: I never said anything about hating
<marex>
RP: they just seemed like something which needs to be constantly maintained
<marex>
and something most boards dont really need
<marex>
I wonder if those patches couldn't be isolated to the qemu machines then ?
<RP>
marex: I'm going to get annoyed with this conversation so I'm just going to walk away from it
<RP>
I'll leave with the question of whether you think we just make work for ourselves by doing it or whether there are actual reasons?
<marex>
RP: I was curious about the reasons
<RP>
marex: it has been discussed many times before. We should probably try and write it up somewhere
<marex>
RP: hmmmm, that might be a good idea
<marex>
RP: btw while you bring up testing, I have one more question about this yocto-check-layer
<marex>
RP: it just takes too long, roughly the same time it takes to do my CI build with primed sstate cache, is there some trick to speeding it up?
<marex>
I can imagine the OE CI does check the layers, right ?
<RP>
marex: It should be equivalent to parsing the metadata a couple of times and it does do a build dry run