/tmp/build-kmod-nvidia.sh kernel-open && \ vs /tmp/build-kmod-nvidia.sh kernel && \
/tmp/build-kmod-nvidia.sh kernel-open && \
vs
/tmp/build-kmod-nvidia.sh kernel && \
vs
/tmp/build-kmod-nvidia.sh kernel && \
E
DI think something like this might work. Let me test this before I ask you to review. https://github.com/ublue-os/akmods/pull/225
J
Byes
Jmissed it the first time, just happened to see a github notification on it
DCan someone approve this workflow? I want to see if it builds. https://github.com/ublue-os/akmods/pull/225
GitHub
This PR attempts to build both containers using the same file. Not yet tested, just submitting for some early feedback.
Mcheck your bash first. It has at least one syntax error
DAre you sure? It shows 40 successful
D
DLooks to be working 
D^ legacy is showing NVIDIA_FLAVOR=nvidia; open is showing open.
DI think this might be good to go in.
RThe builds look to be only the proprietary builds.
https://github.com/ublue-os/akmods/actions/runs/10303593550/job/28521223762?pr=225#step:12:2110
Whereas if you look at an existing open kernel module build:
https://github.com/ublue-os/akmods/actions/runs/10294789438/job/28493399255#step:12:2111
https://github.com/ublue-os/akmods/actions/runs/10303593550/job/28521223762?pr=225#step:12:2110
Whereas if you look at an existing open kernel module build:
https://github.com/ublue-os/akmods/actions/runs/10294789438/job/28493399255#step:12:2111
DLooking
DThe NVIDIA_FLAVOR variable is making it to the build. I wonder if it is not being consumed right.
DAs it is getting used in the containerfile
DOhhhhhhhh I'm passing the wrong thing to the build kmod
DIt expects kernel-open or kernel not nvidia or nvidia-open
DI think I have a fix in for it now
DCan you reapprove the workflow
DThis was almost certainly it. https://github.com/ublue-os/akmods/pull/225/commits/fcbdaa304b60faa5e577ddaed499480030986108
DOkay now it has a syntax error.
DOh, I think I see it. else instead of fi here.
DLet me dig into that some more. Looks to still be failing
DThe if statement parsing was a bit hard, so I'm trying a different way to see if that works.
DThat should function as intended.
DI want to say it's probably good now and might work when the workflow is reapproved, but I can't get it to build on my personal fork - so no promises
RWhere are the container policies being added to the images? I know they are defined in ublue-os/config, but wondering how we should get them over to Cosmic.
I kinda expected them to be added in ublue-os/main, which cosmic inherits
I kinda expected them to be added in ublue-os/main, which cosmic inherits
DI'm seeing
Dual MIT/GPL
Dual MIT/GPL
Dual MIT/GPL
Dual BSD/GPL
Dual MIT/GPL
on both now. Which is better than it failing but something is off.
Dual MIT/GPL
Dual MIT/GPL
Dual MIT/GPL
Dual BSD/GPL
Dual MIT/GPL
on both now. Which is better than it failing but something is off.
Mthey should be in ublue-os/main
DI think this is really close. Need to figure out why it's building the wrong one on legacy then fix that
RAh, so I can see the public key in the image (maybe from the ISO?) but there's strangely just the default InsecureAcceptAnything container policy.
Min cosmic or main?
RIn cosmic
RBut I guess since it's the default policy in cosmic, it's also in main-base?
Mcosmic-base should be base-main + copr repos
Mmain-base has our policy in /usr/etc/containers/policy.json. It has the default in /etc/containers/policy.json
RIn cosmic
Arechunk 0.8.1 will use /usr/etc and 0.8.0 will use /etc
Awe verified 0.8.1 will use the correct policy on bazzite and i prd it yesterday
Afor cosmic
RIt was whatever the ISOs were built with.
Will spin some new ISOs
Will spin some new ISOs
Acheck the container image by booting with bash
Athe correct oen should be in /etc
Anot booting by running bash on it
Athere should not be a /usr/etc dir
K@M2 @Robert (p5) got an interesting issue we need to fix
Kas part of moving /usr/etc to /etc, it turns out we were replacing a file in /etc/ provided by a core package by putting the replacement in /usr/etc
Kthat's the container update policy
