Jno one's ever mentioned it on r/kde, people don't talk about it, there was one youtube review but it was basically a ujust video lol
Jyeah! in the text I'll link to the methodology, etc.
JCan the "statistics start" thing be removed?
Aremoved
Acan you make a repo and give me write access?
Acountme or something
Athen link me
ZIf anyone is bored, here is some food for the brain
https://crates.io/crates/wyrcan
For me didn't work, interesting concept though
https://crates.io/crates/wyrcan
For me didn't work, interesting concept though
NThis looks amazing
Aok i cleaned it up and made it run in 6 seconds
NThis looks wild.
NInteresting concept for having kiosk machines.
ZThat, or, a bootc installer
ZWould pull the image, and with kernel args you would enable a systemd service that starts anaconda or whatever frontend
NOnly issue is the project hasn't been updated for 3 years.
ZYep, kinda missed opportunity
ZWe were too late:dispair:
CAwesome! I've been wanting and occasionally manually calculating the estimated number of unique machines. Great to have it as an automated visual 
Bhttps://github.com/ublue-os/akmods/pull/295
significant PR for combining kernel-cache and akmods build processes...
not a quick +1 and merge, needs some
please 
significant PR for combining kernel-cache and akmods build processes...
not a quick +1 and merge, needs some
please GitHub
This incorporates the functional bits from kernel-cache repo such that the kernel caching and akmod build processes are tightly coupled, as they should be.
Getting the appropriate version for diffe...
Getting the appropriate version for diffe...
Jmerging
J(jk)
Nthat button looks appealing right
RHow does this work? I couldn't see any podman push or artifact upload steps after building the kernels, so how are these used by the akmods?
Tclosed wontfix
Bi mean, it builds green
Nthe commit msgs are hilarious
Bfirst stage of workflow caches Kernel RPMs using a github cache... then the second stage is basically the old akmods process, except using the github cached artifacts rather than OCI images...
in the end, the kernel RPMs are added to
in the end, the kernel RPMs are added to
/kernel-rpms
Mthis is a community project.
Bthat's how you know this had a lot of TLC 
Ni mean it in a good way :D
Nnot in a bad one
Bunderstood
Jlol I woulda squashed
J"perfect in one go."
Bhonestly, i think its nice to see that stuff but the final will squash
but the final will squashTimagine someone reading the commits later and that shows up. ahhahaha at least it shows the history of the changes and how you were feeling about the commit at the time LOL
Boh, i know what you mean... why don't you see the kernels fetched? because an earlier build successfully cached them already
Nyou should use more sobs in your ones
RNo - I'm meaning you're calling the cache action before making the kernels. But I guess the cache action saves the data in a post-workflow step?
Byes, that's how it works by default.
there's a way you can be more specific and "retrieve from cache" and "save to cache" but this seems fine
there's a way you can be more specific and "retrieve from cache" and "save to cache" but this seems fine
Mthis looks like it is nontrivial to build locally now...
Bhere's an example of that post-workflow step NOT saving due to cache-hit https://github.com/ublue-os/akmods/actions/runs/13102055564/job/36551528729#step:17:2
Bthat IS the downside
MProbably can throw together a Justfile as part of the testing
Byeah, i do something like this already at work, and i use just file to prep a local cache which matches up like this
BI'd like to convert this to Just and clean it up a lot, but I felt it more important to move forward iteratively
Bless overall change makes it easier to grok the set of changes... I hope.
Myeah i think being tied first to github actions is fine given that we are relying on the cache action
B@p5 here's where the cache was last saved: https://github.com/ublue-os/akmods/actions/runs/13101891946/job/36551158340#step:17:1
