Sourcing of third party RPMs about main HOT 5 CLOSED

Main will stay relativly faithful to upstream. While adding QoL additions to make life easier for general user

from main.

I'm personally not a fan of the idea of adding xone or xpadeno but I did reconize the thrid party repo as a known eninity. While the Ubuntu build, and what I assume its replacement Bluefin, both use Tailscale.

I think it is important to declere if any repos are used outsdie of the defualts; and how a set standard on how those are added the the build. The main build script seems to be a perfectly fine way to do it, one block with everything listed and nothing else happening in that code block.

from main.

Yea, we need to make sure the end user can trace and know exactly what's on the image.

from main.

Quick note from an impromptu postmortem on the build failures. New 6.3.1 kernel needed a fix for xone to build, which was committed upstream 2 weeks ago but xone never released a new version, so negativo didn't pick it up because they're packaging the latest upstream. That caused the failure which led to main also not building.

For akmods we might consider just building them in our copr to remove a 3rd party dep, but also do git builds so we can rev faster if need be, and then we just need to decide if we gate in the build step or the rpm step.

from main.

I would like to focus that main images should stay as minimal as possible. Firejail doesnt work for me, so even having RPM Firefox is a bit bloat for me.

COPRS I use:

• gocryptfs
• ryzenadj

I would really like a minimal, hardened Kernel, hardened malloc version.

from main.