Asus akmods builds failing
hey folks - noticed the akmods f40 asus builder is failing. I am pretty sure its because the rtl8814au-kmod package is out of date. I would appreciate some eyes on a few PRs and some COPR builds since I don't have the permissions.
GitHub
chore(ci): Update builder to 24.04 · ublue-os/akmods@7fecd52
A caching layer for pre-built Fedora akmod RPMs. Contribute to ublue-os/akmods development by creating an account on GitHub.
62 Replies
@Kyle Gospo do you handle these coprs? I don't have access to them.
pulling into the thread for reference: I think we will need to do a few things:
1) https://github.com/ublue-os/packages/pull/25
2) rtl8814au-kmod COPR package & rtl8814au COPR package builds
3) kick the akmods 40 build
GitHub
chore: update srccommit in rtl8814au-kmod.spec by mulderje · Pull R...
Update rtl8814au to latest commit to hopefully fix the akmods f40 asus builder
Will likely need someone to kick the COPR build?
Potentially closes: ublue-os/akmods#185
looks like there are a few people
just requested build perms as well
(feel free to ignore that last if preferred)
I will include @EyeCantCU and @bsherman on this thread.
thanks!
no problem! Thanks for pointing this out!
Can take a look at this in half an hour or so
thanks! lmk if you have any thoughts/questions
FYI just noticed this is also hitting bluefin asus 40. eg. https://github.com/ublue-os/bluefin/actions/runs/9099556968/job/25012367053
GitHub
bluefin 40 · ublue-os/bluefin@6b38313
An interpretation of the Ubuntu spirit built on Fedora technology - bluefin 40 · ublue-os/bluefin@6b38313
so that'll also need a kick at the end
Yeah. World will have to be rebuilt
yep. fingers crossed that spec update should fix it all. the upstream diff seems to indicate it should
Sorry. Sidetracked. Pulling up now
no worries. lmk if anything i can do
Thank you! Updating the package might help resolve the failure.
I'm thinking we probably need to bump the version and reset the epoch too. I'll push a commit to your existing PR 🙂
sounds good. will take a look. fyi the version upstream didn't change at all, so maybe just epoch?
or actually, wouldn't that just be release
Apparently there aren't any releases. Needs at least an epoch bump
Bumped the 'release' and merged (not epoch sorry, in Wolfi mode)
yeah exactly the spec "release" field is what i meant 🙂
Kicking off a Copr build now
perfect. thanks
thanks for catch
if bumping the release in
rtl8814au-kmod does it also need to be bumped to match in rtl8814au?
nvm you already got it 🙂No, you don't. It looks like rtl8814au was just building from HEAD. Just good to know when something was updated
Speaking of AK mod changes
ryzen_smu and I'm sure some others need to be x86 only
As they fail to build for arm
Can have a look at that too 🙂
Still failing. About to sit down for dinner but will look after
hmm
ok thanks
will take a quick look before dinner
its the other one -
rtl88xxau
the source in that files just pulling head of the "v5.6.4.2" branch at build time. so if i'm reading that right, it looks like it'd have the source from the build from 22 days ago. maybe just hit those two builds again for now to pick up HEAD?
looks like there have been a few commits since then, but haven't looked beyond that
also heading for dinner now though
should probably look at adding in something like packit to auto bump these
yeah, @EyeCantCU - can you just bump the rev number for those two packages and build them in COPR? i think that'll fix for nowcould set up something like https://packit.dev/posts/monorepos to auto-build the COPRs to get them building
Introducing monorepository support | Packit
We are very happy to announce a major enhancement to Packit! We have now added support for
ive never used before, but could try to mock up a PR if interest
but that may not do anything without there being releases upstream
could also maybe do something like a cron to pull the latest commit revs in a GH action and then edit the files, and kick the builds
either way a rev bump/build for now will hopefully fix
I'll give it a try
Thanks! I’d try myself but don’t have permissions
Still failing. Looks like zenergy now
@Kyle Gospo - any thoughts there? looks like you own the repo. current build failure on ASUS 40 in the c code
GitHub
ublue akmods 40 · ublue-os/akmods@9f48cad
A caching layer for pre-built Fedora akmod RPMs. Contribute to ublue-os/akmods development by creating an account on GitHub.
re-run the build or think you need to make changes? could also block on the asus build
if it's only failing on asus, they might have broken something in ther kernel
probably best to pull it from there
It's only asus + nvidia that has failures
on 40
is zenergy being used by any of the images?
bazzite atm
ok
but that's fsync
should we only build for fsync?
ie 1) only build fsync or 2) turn off for asus
I think zenergy is useful, others may want it
proper power monitoring for AMD CPUs
no preference here. will put it on no asus to start and can limit further later if it causes issues
pr up shortly
GitHub
fix(zenergy): remove from ASUS build to fix builder by mulderje · P...
Thank you for contributing to the Universal Blue project!
Please read the Contributor's Guide before submitting a pull request.
will need a few acks there and then someone to do the builder dance for me
with that though it should unbreak the 40 build since zenergy was the last on the list being built
@M2 - that should unbreak the asus build and everything downstream once in fyi
Change lgtm, but you're missing a backslash. Added a suggestion to the PR 🙂
doh
added in from GH UI
Sounds good 🙂
thanks for the catch. hate it when i save after the git commit and dont pay attention
i've never used that UI feature before. super handy!
It's great for quick edits. If you don't have it set up yet, I'd highly recommend VS Code. Tons of extensions that are helpful. I use a combination of that, nano, and Zed (my absolute favorite)
i've been toying around with vs code and helix lately. historically have liked vim for console editing since its what i'm used to. heard great things about zed
been trying to figure out a good dev container workflow
with vs code
very much a git novice for anything more advanced than a basic merge, so the UI stuff is helpful for learning all that
is there a way for me to kick off a PR build somehow? i've seen some projects where people can type in things like "/build" or whatever in a PR comment if they dont have commit access yet
I approved the runs. Let's see how this goes...
thanks! looks all green now
Merging!
great! hopefully we see the green trickle through everything
thanks for going down the rabbit hole
we need something to keep those specs up-to-date or will likely just happen again soon
@EyeCantCU - is it intentional to not have a GH action/job for a push on main to kick the build?
wondering if that should be added to the workflow
Looks like everything pushed fine: https://github.com/ublue-os/akmods/actions/runs/9116899744/job/25066540089
GitHub
ublue akmods 40 · ublue-os/akmods@2ead2b3
A caching layer for pre-built Fedora akmod RPMs. Contribute to ublue-os/akmods development by creating an account on GitHub.
yep the merge queue run worked, but once merged on main there isn't a build for "main" branch and 40 still shows as failing overall so far as i can tell
ie not like the one on the bottom
i think there needs to be something in the workflow file for bazzite. eg on --> push --> branches --> main
think being the operative word there 🙂
and assuming you want that vs just the daily cron
Oh, I see what you mean. I believe it's set up this way to prevent us from having a gazzillion concurrent queued builds. So if we introduce a change that's small, we aren't wasting runners rebuilding everything each time
got it. makes sense