NSo... I found this about setting up an RPM repository in Github pages: https://jon.sprig.gs/blog/post/2835
A nice guy's view on life
Last week I created a post talking about the new project I’ve started on Github called “Terminate-Notice” (which in hindsight isn’t very accurate – at best it’s …
Nthis may be a solution for us? I'm not sure if there is a max size for static content in a Github pages site.
N@j0rge @bsherman @Kyle Gospo
BI know I've seen something like this before, though maybe not this particular post.
BBut this is exactly one of the things I wanted to investigate.
NI'm assuming we are using Github CI to build our existing RPMs?
Nprobably in configs repo?
BWe build some in config some in akmods, some in ucore-kmods
BAnd beyond that anything we build is a COPR. But I’m also curious about building a few more things that currently in negativo17 repos
KI'm down to try it with Mesa, we need a va-drivers package that doesn't randomly break
KCopr in my case
KWe build only a couple things in GitHub
KOnly thing is that opens us up to h264 licensing issues
KSo maybe it's better to just deal w/ RPM fusion....
BI have not imagined replacing rpmfusion
BOnly negativo17, and putting our ublue nvidia, just, adding, config and kmod builds into some kind of repo instead of being layers
KI bring it up because right now hardware video decode is broken on main
KBecause rpmfusion hasn't built Mesa yet
BGotcha.
KMight be fixed as of today since Fedora updated mesa
KBut those sorts of hiccups keep happening
BYeah, I would say test this concept iteratively
I can work on it. And try pushing just our config/addons/just type rpms. If that’s good, add the kmods , and if that’s all working good, start on negativo17.
Finally if all that is solid for us we can think about rpmfusion, but that’s a lot to bite off and definitely not plausible until the model is proven.
I can work on it. And try pushing just our config/addons/just type rpms. If that’s good, add the kmods , and if that’s all working good, start on negativo17.
Finally if all that is solid for us we can think about rpmfusion, but that’s a lot to bite off and definitely not plausible until the model is proven.
Jnod, and didn't we start a packages repo as a start to this?
Bthat's spec files for COPRs
Jyeah I was hoping we'd have one nice centralized thing
Bi would like that too...
if no one is in a rush ... i'm happy to work on this...
if no one is in a rush ... i'm happy to work on this...
J
Bi'm eager to finish some workflow changes on ucore, then this is my next goal
Jlike, if anything just to have the rpm's building in our infra so we can see them all going along with the images would be awesome
JWhat a glorious merge queue it would be
Bi can't find a suitably glorious emoji for that comment
NI might be able to try and help on this too. Good opportunity to shoulder surf to learn GitHub workflows?
Bhappy to work with you on it
NNI'm gonna start poking at this for a little bit.
NNOK. Have had a few thoughts since looking over the github workflows that this blog uses: https://jon.sprig.gs/blog/post/2835
NHe has 2 different workflows to make his setup happen.
NHe has 1 workflow which actually builds the RPM and deb packages and makes them available in Github Releases.
NHe has a 2nd workflow which builds the actual repository here: https://github.com/terminate-notice/terminate-notice.github.io/blob/main/.github/workflows/repo.yml
NTLDR: He is building the packages using his source code through Github Action, making them available as a release, and then ingesting them into a repo that has a front end page available with Jekyll.
NSo a couple questions...
NWe build some of our packages in Copr, we have some in RPMFusion, and some from Negativo.
NWhat amount of effort would it take to retool what we are doing in Copr and making it available in our Github Repo? OR another thought I just had is what if we just grab the RPMs directly from our sources we use and just mirror them?
Nbecause realistically all I see the repo action doing is grabbing the RPM from the github releases page, ingesting it, and signing it.
NIn the second scenario, as long as we can grab the RPMs we need directly, we could just mirror them? Not really sure what the maximum amount of space you can store in a single Github Repo.
NAnd I know we don't want to rebuild all of RPMFusion 
NAlso this is a note for myself on how I built my hello-world rpm spec file. Figured we could use it as a test: https://earthly.dev/blog/creating-and-hosting-your-own-rpm-packages-and-yum-repo/
