Copr is an easy-to-use automatic build system providing a package repository as its output.

Start with making your own repository in these three steps:

  1. choose a system and architecture you want to build for
  2. provide Copr with src.rpm packages available online
  3. let Copr do all the work and wait for your new repo

NOTE: Copr is not yet officially supported by Fedora Infrastructure.

Projects

fmatejic/Task-spooler

task spooler is a Unix batch system where the tasks spooled run one after the other. The amount of jobs to run at once can be set at any time. Each user in each system has his own job queue. The tasks are run in the correct context (that of enqueue) from any shell/process, and its output/results can be easily watched. It is very useful when you know that your commands depend on a lot of RAM, a lot of disk use, give a lot of output, or for whatever reason it's better not to run them all at the same time, while you want to keep your resources busy for maximum benfit. Its interface allows using it easily in scripts.
  • Epel for CentOS 6 : x86_64
  • Epel for CentOS 7 : x86_64

rfairley/add-motd-directories

Description not filled in by author. Very likely personal repository for testing purpose, which you should not use.
  • Epel for CentOS 7 : ppc64le, x86_64
  • Fedora 28 : i386, ppc64le, x86_64
  • Fedora 29 : i386, ppc64le, x86_64
  • Fedora rawhide : i386, ppc64le, x86_64

angeldm/efitools

How to use these files simply typing make will build you everything including sample certificates for PK, KEK and db. The prerequisites are the standard development environment, gnu-efi version 3.0q or later, help2man and sbsigntools. There will be one file called LockDown.efi. If run on your efi platform in Setup Mode, this binary will replace all the values in the PK, KEK and db variables with the ones you just generated and place the platform back into User Mode (booting securely). If you don't want to replace all the variables, take a dump of your current variables, see sig-list-to-cert(1), and add them to the EFI signature list files before creating LockDown.efi Say you want to concatenate an existing platform-db.esl file, do this: make DB.esl cat platform.esl DB.esl > newDB.esl mv newDB.esl DB.esl and then make LockDown.efi in the usual way. All of the EFI programs are also generated in signed form (signed by both db and KEK). Loader.efi This EFI binary is created to boot an unsigned EFI file on the platform. Since this explicitly breaks the security of the platform, it will first check to see if the boot binary is naturally executable and execute it if it is (either it's properly signed or the platform isn't in Secure Boot mode). If the binary gives an EFI_ACCESS_DENIED error meaning it isn't properly signed, Loader.efi will request present user authorisation before proceeding to boot. The idea is that Loader.efi may serve as a chain for elilo.efi or another boot loader on distributed linux live and install CDs and even as the boot loader for the distribution on the hard disk assuming the user does not wish to take control of the platform and replace the keys. To build a secure bootable CD, simply use Loader.efi as the usual /efi/boot/bootX64.efi and place the usual loader in the same directory as the file boot.efi. In order to add further convenience, if the user places the platform in setup mode and re-runs the loader, it will ask permission to add the signature the unsigned boot loader, boot.efi, to the authorised signatures database, meaning Loader.efi will now no longer ask for present user authorisation every time the system is started. Creating, using and installing your own keys To create PEM files with the certificate and the key for PK for example, do openssl req -new -x509 -newkey rsa:2048 -subj "/CN=PK/" -keyout PK.key -out PK.crt -days 3650 -nodes -sha256 Which will create a self signed X509 certificate for PK in PK.crt (using unprotected key PK.key with the subject common name PK (that's what the CN=PK is doing). You need to create at least three sets of certificates: one for PK, one for KEK and one for db. Now you need to take all the efi binaries in /usr/share/efitools/efi and sign them with your own db key using sbsign --key db.key --cert db.crt --output HelloWorld-signed.efi HelloWorld.efi To install your new keys on the platform, first create your authorised update bundles: cert-to-sig-list PK.crt PK.esl sign-efi-sig-list -k PK.key -c PK.crt PK PK.esl PK.auth And repeat for KEK and db. In setup mode, it only matters that the PK update PK.auth is signed by the new platform key. None of the other variables will have their signatures checked. Now on your platform update the variables, remembering to do PK last because an update to PK usually puts the platform into secure mode UpdateVars db db.auth UpdateVars KEK KEK.auth UpdateVars PK PK.auth And you should now be running in secure mode with your own keys.
  • Fedora 29 : x86_64
  • Fedora rawhide : x86_64

adelarch/project_one

exemple
  • openSUSE Leap 15.0 : x86_64

adrian/ohpc

Description not filled in by author. Very likely personal repository for testing purpose, which you should not use.
  • Epel for CentOS 7 : x86_64

msuchy/asdfadsgsdfgsfdgsdfg

Description not filled in by author. Very likely personal repository for testing purpose, which you should not use.
  • Custom 1 : i386

kdudka/build-fedora-pkgs-on-el6

Description not filled in by author. Very likely personal repository for testing purpose, which you should not use.
  • Fedora 28 : x86_64
  • Fedora 29 : x86_64
  • Fedora rawhide : x86_64

ssabchew/nagstamon

Rebuild from source for fedora 28 version 3.0.2 Will keep bulding updates from latest stable.
  • Fedora 27 : i386, ppc64le, x86_64
  • Fedora 28 : i386, ppc64le, x86_64
  • Fedora 29 : i386, ppc64le, x86_64
  • Fedora rawhide : i386, ppc64le, x86_64
  • Mageia 6 : i586, x86_64
  • Mageia cauldron : i586, x86_64
  • openSUSE Leap 15.0 : x86_64
  • openSUSE Tumbleweed : i586, ppc64le, x86_64

metastore/fedora-nginx

Description not filled in by author. Very likely personal repository for testing purpose, which you should not use.
  • Fedora 29 : x86_64

metastore/fedora-httpd

Description not filled in by author. Very likely personal repository for testing purpose, which you should not use.
  • Fedora 29 : x86_64