guh? I only see your question about the coprs
guh? I only see your question about the coprs
Bhmm... am i being a github newb?
BBit says "Pending" for me... maybe that means you can't see it?
KI got nothing
KI think so, yea
Bweird... i don't know how to make it show for you, but that explains why you didn't respond 
Boh "show comments"?
B
K
Bweird
Kah well, I'll make that change now
B"Would be nice to add the "(akmod from copr)" similar to the other ublue-os COPR sourced RPMs."
KGoing to alphabetize this list too, and in the containerfile
Byep, thats all... I was just trying to think of some consistent way to show from where we get 1) the source (project repo) 2) the rpms (eg, copr, negativo17) if not from rpmfusion
Byes, i was being a github newb... needed to submit the comment via "Request changes" on the review
KGitHub
Driver needed for Google's Coral TPU hardware on Linux, useful for home servers since it can do ML image processing at very low power usage.
https://coral.ai/products/
Version actually being bu...
https://coral.ai/products/
Version actually being bu...
Khere's the new one, requested change made + alphabetized
Kthese two I'm still working on, getting close I think
Klikely finish OpenRGB first, then work on Aura-GPU since it's also used by OpenRGB
Kand then finish that goofy steam deck OC driver
KGitHub
Provides modified i2c-piix4 and new i2c-nct6775 for controlling RGB on certain motherboards.
Kthere's OpenRGB, Aura-GPU next
K@j0rge May or may not be something you want in Main, same with Aura-GPU
KIt's a supporting mod for OpenRGB, but they've caused bricked RGB controllers in the past
Jlet's keep it vanilla for now and reinvestigate later?
Ksure
Jwe're only explicitly copying 2 into main right?
Kyeah, iirc it's an xbox driver and loopback
Jyeah I think if we have a bunch in there, give it some time to see how they shake out, I'm especially keen to find out what happens the next major kernel and distro versions
Ksounds good
JI have a question for you RPM nerds though
JSomeone (I think it was you kyle?) mentioned that we could just keep the spec files in a repo and have an action that just builds the RPMs on the spot. That sounds way cleaner to me than having to manage a COPR or do OBS or whatever. Am I missing a downside?
Kspec files in-repo is definitely me
Kbut I'm a huge proponent of copr due to it making a proper repo
Kso failed builds aren't an issue
Kthere's a happy middle ground there to be sure
Ksince you can make webhooks in github to trigger rebuilds in copr, that's how all of mine work
KI don't even merge stuff half the time because the pull bot does it for me
Jwhen you say "failed builds aren't an issue" what do you mean by that?
Kif a build fails the previous successful result will be what you/others download
Kgithub releases of course are the same way, but I find it's a little harder to make use of those in a containerfile
Kand being on copr means the wider fedora community gets to play with it too
Jyeah so my line of thinking was - if it doesn't have to be a proper repo since it's used specifically for image building, you could attach the rpms to github releases and then just consume them from the containerfile. Though I guess you'd have to figure out versioning and stuff instead of just having a repo file ...
Kcould do what copr (optionally) does and use the latest git commit id as the version
Kunless what you're building is stable enough to bother with proper version numbers
KGitHub
Allows i2c communication with certain Aura capable GPUs, allowing them to be controlled from OpenRGB
Khere's that aura driver as well
J"Merge when ready" ftw
Kty
KGitHub
Provides modified i2c-piix4 and new i2c-nct6775 for controlling RGB on certain motherboards.
