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

angeldm/vscode

Visual Studio Code - Open Source VS Code is a type of tool that combines the simplicity of a code editor with what developers need for their core edit-build-debug cycle. It provides comprehensive editing and debugging support, an extensibility model, and lightweight integration with existing tools. VS Code is updated monthly with new features and bug fixes. You can download it for Windows, macOS, and Linux on VS Code's website. To get the latest releases every day, you can install the Insiders version of VS Code. This builds from the master branch and is updated daily at the very least. The vscode repository is where VS Code is developed and there are many ways you can participate in the project, for example: Submit bugs and feature requests and help us verify as they are checked in. Review source code changes. Review the documentation and make pull requests for anything from typos to new content. Contributing If you are interested in fixing issues and contributing directly to the code base, please see the document How to Contribute, which covers the following: How to build and run from source The development workflow, including debugging and running tests Coding Guidelines Submitting pull requests Contributing to translations Please also see our Code of Conduct. Feedback Ask a question on Stack Overflow. Request a new feature on GitHub. Vote for Popular Feature Requests. File a bug in GitHub Issues. Tweet us with any other feedback. Related Projects Many of the core components and extensions to Code live in their own repositories on GitHub. For example, the node debug adapter and the mono debug adapter have their own repositories. For a complete list, please visit the Related Projects page on our wiki. Bundled Extensions Code ships with a set of extensions. These extensions are located in the extensions folder. These extensions include grammars and snippets for several languages. Extensions that provide rich language support (code completion, go to definition) for a language have the suffix 'language-features'. For example, the 'json' extension provides coloring for JSON and the 'json-language-features' provides rich language support for JSON. License Copyright (c) Microsoft Corporation. All rights reserved. Licensed under the MIT License.
  • Fedora 29 : x86_64
  • Fedora rawhide : x86_64

tripledes/fedora-rpms

RPMs I personally use on my systems: minishift: Run OpenShift locally minikube: Run Kubernetes locally docker-machine-driver-kvm: KVM driver for docker-machine, required by minishift. docker-machine-driver-kvm2: KVM driver for docker-machine v2, specifically maintained for minikube. Sources at GitHub
  • Fedora 29 : x86_64

jasonbrooks/origin

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

landgraf/kea_epel

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

kempniu/bind-esv

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

galihrahayu/grel-release

Extra Packages for My Extra Packages.
  • Epel for CentOS 7 : x86_64

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