#357 Remove docs from this repository.
Merged a month ago by dherrera. Opened a month ago by dherrera.
dherrera/epel migration  into  main

file removed
-4
@@ -1,4 +0,0 @@ 

- /build/

- /cache/

- /public/

- /preview.pid

file modified
+11 -15
@@ -1,11 +1,4 @@ 

- # EPEL Documentation and Issue Tracker

- 

- ## Documentation

- 

- This repository contains documentation related to Fedora EPEL project.

- It is published via Fedora Docs:

- 

- * https://docs.fedoraproject.org/en-US/epel/

+ # EPEL Issue Tracker

  

  ## Issue Tracker

  
@@ -19,17 +12,20 @@ 

  Infrastructure related issues should be reported in the [fedora-infrastructure

  issue tracker][infra].

  

- ## Contributions

- 

- The project welcomes contributions to our documentation.  If your pull request

- is describing a yet to be implemented change, or if you would like to iterate

- on feedback before merging, please include the word `DRAFT` in the pull request

- title to indicate to others that it is not ready to be merged yet.

- 

  [bugzilla]: https://bugzilla.redhat.com/

  [releng]: https://pagure.io/releng/issues

  [infra]: https://pagure.io/fedora-infrastructure/issues

  

+ ## Documentation

+ 

+ EPEL documentation sources are being hosted in the following repository.

+ 

+ * https://forge.fedoraproject.org/epel/docs

+ 

+ The results are published via Fedora Docs:

+ 

+ * https://docs.fedoraproject.org/en-US/epel/

+ 

  # License

  

  SPDX-License-Identifier: CC-BY-SA-4.0

file removed
-22
@@ -1,22 +0,0 @@ 

- # Name will be mostly visible in the URL. Treat it as an identifier.

- # Tip: If you want to use the local preview scripts that come with this

- # repository, please change this value in the site.yml file as well (under

- # site/start_page)

- name: epel

- 

- # Title will be visible on the page.

- title: EPEL

- 

- # If you don't plan to have multiple versions of the docs (for example, to

- # document multiple versions of some software), you can ignore this field.

- # Otherwise, change "~" to a specific version.

- version: ~

- 

- # We encourage you to name the index page as "index.adoc". If you absolutely

- # have to use a different name, please reflect it here. You can ignore this

- # field otherwise.

- start_page: ROOT:index.adoc

- 

- # This lists all the menu definitions of your component.

- nav:

- - modules/ROOT/nav.adoc

file removed
-292
@@ -1,292 +0,0 @@ 

- #!/bin/bash

- # script to watch source directory for changes, and re-run build and preview

- #

- # License: MIT

- # https://fedoraproject.org/wiki/Licensing:MIT#Another_Minimal_variant_(found_in_libatomic_ops)

- #

- # Copyright (c) Fedora community contributors.

- #

- # THIS MATERIAL IS PROVIDED AS IS, WITH ABSOLUTELY NO WARRANTY EXPRESSED OR

- # IMPLIED. ANY USE IS AT YOUR OWN RISK.

- #

- # Permission is hereby granted to use or copy this program for any purpose,

- # provided the above notices are retained on all copies.  Permission to modify

- # the code and to distribute modified code is granted, provided the above

- # notices are retained, and a notice that the code was modified is included

- # with the above copyright notice.

- 

- 

- script_name="docsbuilder.sh"

- script_source="https://gitlab.com/fedora/docs/templates/fedora-docs-template/-/raw/main/${script_name}"

- version="1.2.0"

- image="registry.gitlab.com/fedora/docs/docs-website/docs-fp-o:latest"

- cmd="--html-url-extension-style=indexify site.yml"

- srcdir="modules"

- buildir="public"

- previewpidfile="preview.pid"

- 

- # 4913: for vim users, vim creates a temporary file to test it can write to

- # directory

- # https://groups.google.com/g/vim_dev/c/sppdpElxY44

- # .git: so we don't get rebuilds each time git metadata changes

- inotifyignore="\.git.*|4913"

- 

- watch_and_build () {

-     if ! command -v inotifywait > /dev/null

-     then

-         echo "inotifywait command could not be found. Please install inotify-tools."

-         echo "On Fedora, run: sudo dnf install inotify-tools"

-         stop_preview_and_exit

-     else

-         # check for git

-         # required to get ignorelist

-         if ! command -v git > /dev/null

-         then

-             echo "git command could not be found. Please install git."

-             echo "On Fedora, run: sudo dnf install git-core"

-             stop_preview_and_exit

-         else

-             # Get files not being tracked, we don't watch for changes in these.

-             # Could hard code, but people use different editors that may create

-             # temporary files that are updated regularly and so on, so better

-             # to get the list from git. It'll also look at global gitingore

-             # settings and so on.

-             inotifyignore="$(git status -s --ignored | grep '^!!' | sed -e 's/^!! //' | tr '\n' '|')${inotifyignore}"

-         fi

- 

-         while true

-         do

-             echo "Watching current directory (excluding: ${inotifyignore}) for changes and re-building as required. Use Ctrl C to stop."

-             inotifywait -q --exclude "($inotifyignore)" -e modify,create,delete,move -r . && echo "Change detected, rebuilding.." && build

-         done

-     fi

- }

- 

- build () {

-     if [ "$(uname)" == "Darwin" ]; then

-         # Running on macOS.

-         # Let's assume that the user has the Docker CE installed

-         # which doesn't require a root password.

-         echo ""

-         echo "This build script is using Docker container runtime to run the build in an isolated environment."

-         echo ""

-         docker run --rm -it -v $(pwd):/antora $image $cmd

- 

-     elif [ "$(expr substr $(uname -s) 1 5)" == "Linux" ]; then

-         # Running on Linux.

-         # Check whether podman is available, else faill back to docker

-         # which requires root.

- 

-         if [ -n "$(command -v podman)" ]; then

-             echo ""

-             echo "This build script is using Podman to run the build in an isolated environment."

-             echo ""

-             podman run --rm -it -v $(pwd):/antora:z $image $cmd --stacktrace

- 

-         elif [ -n "$(command -v docker)" ]; then

-             echo ""

-             echo "This build script is using Docker to run the build in an isolated environment."

-             echo ""

- 

-             if groups | grep -wq "docker"; then

-                 docker run --rm -it -v $(pwd):/antora:z $image $cmd

-             else

-                     echo ""

-                     echo "This build script is using $runtime to run the build in an isolated environment. You might be asked for your password."

-                     echo "You can avoid this by adding your user to the 'docker' group, but be aware of the security implications. See https://docs.docker.com/install/linux/linux-postinstall/."

-                     echo ""

-                     sudo docker run --rm -it -v $(pwd):/antora:z $image $cmd

-             fi

- 

-         else

-             echo ""

-         echo "Error: Container runtime haven't been found on your system. Fix it by:"

-         echo "$ sudo dnf install podman"

-         exit 1

-         fi

-     fi

- }

- 

- start_preview () {

- 

-     # clean up a preview that may be running

-     stop_preview

- 

-     # always run an initial build so preview shows latest version

-     build

- 

-     if [ "$(uname)" == "Darwin" ]; then

-         # Running on macOS.

-         # Let's assume that the user has the Docker CE installed

-         # which doesn't require a root password.

-         echo "The preview will be available at http://localhost:8080/"

-         docker run --rm -v $(pwd):/antora:ro -v $(pwd)/nginx.conf:/etc/nginx/conf.d/default.conf:ro -p 8080:80 nginx

- 

-     elif [ "$(expr substr $(uname -s) 1 5)" == "Linux" ]; then

-         # Running on Linux.

-         # Fedora Workstation has python3 installed as a default, so using that

-         echo ""

-         echo "The preview is available at http://localhost:8080"

-         echo ""

-         pushd "${buildir}"  > /dev/null 2>&1

-             python3 -m http.server 8080 &

-             echo "$!" > ../"${previewpidfile}"

-         popd > /dev/null 2>&1

-     fi

- }

- 

- stop_preview () {

-     if [ -e "${previewpidfile}" ]

-     then

-         PID=$(cat "${previewpidfile}")

-         kill $PID

-         echo "Stopping preview server (running with PID ${PID}).."

-         rm -f "${previewpidfile}"

-     else

-         echo "No running preview server found to stop: no ${previewpidfile} file found."

-     fi

- }

- 

- stop_preview_and_exit ()

- {

-     # stop and also exit the script

- 

-     # if stop_preview is trapped, then SIGINT doesn't stop the build loop. So

-     # we need to make sure we also exit the script.

- 

-     # stop_preview is called before other functions, so we cannot add exit to

-     # it.

-     stop_preview

-     exit 0

- }

- 

- 

- # https://apple.stackexchange.com/questions/83939/compare-multi-digit-version-numbers-in-bash/123408#123408

- version () { echo "$@" | awk -F. '{ printf("%d%03d%03d%03d\n", $1,$2,$3,$4);  }';  }

- 

- 

- check_update () {

-     if ! command -v curl > /dev/null

-     then

-         echo "curl command could not be found. Please install curl."

-         echo "On Fedora, run: sudo dnf install curl"

-         exit 0

-     fi

-     script_version="$(grep "^version=" ${script_name} | cut -d '=' -f2 | tr --delete '"')"

-     tempdir="$(mktemp -d)"

-     echo "$tempdir"

-     pushd "$tempdir" > /dev/null 2>&1

-         curl "$script_source" --silent --output "${script_name}"

-         upstream_version="$(grep "^version=" ${script_name} | cut -d '=' -f2 | tr --delete '"')"

-         echo "${upstream_version}"

-         if [ $(version $upstream_version) -gt $(version $script_version)  ]; then

-             echo "Update available"

-             echo "Script version $upstream_version is available at $script_source"

-             echo "This version is $script_version."

-             echo "Please use the '-U' option to update."

-             echo

-         fi

-     popd > /dev/null 2&>1

- }

- 

- install_update () {

-     if ! command -v curl > /dev/null

-     then

-         echo "curl command could not be found. Please install curl."

-         echo "On Fedora, run: sudo dnf install curl"

-         exit 0

-     fi

-     curl "$script_source" --silent --output "${script_name}.new"

-     mv "${script_name}.new" "${script_name}"

-     chmod +x "${script_name}"

- }

- 

- usage() {

-     echo "$0: Build and preview Fedora antora based documentation"

-     echo

-     echo "Usage: $0 [-awbpkh]"

-     echo

-     echo "-a: start preview, start watcher and rebuilder"

-     echo "-w: start watcher and rebuilder"

-     echo "-b: rebuild"

-     echo "-p: start_preview"

-     echo "-k: stop_preview"

-     echo "-h: print this usage text and exit"

-     echo "-u: check builder script update"

-     echo "-U: install builder script from upstream"

-     echo

-     echo "Maintained by the Fedora documentation team."

-     echo "Please contact on our channels: https://docs.fedoraproject.org/en-US/fedora-docs/#find-docs"

- }

- 

- # check if the script is being run in a Fedora docs repository

- if [ ! -e "site.yml" ]

- then

-     echo "site.yml not be found."

-     echo "This does not appear to be a Fedora Antora based documentation repository."

-     echo "Exiting."

-     echo

-     usage

-     exit 1

- fi

- 

- 

- if [ $# -lt 1 ]

- then

-     echo "No options provided, running preview with watch and build."

-     echo "Run script with '-h' to see all available options."

-     echo

-     echo

-     trap stop_preview_and_exit INT

-     start_preview

-     watch_and_build

-     stop_preview

- fi

- 

- # parse options

- while getopts "awbpkhuU" OPTION

- do

-     case $OPTION in

-         a)

-             # handle sig INT to stop the preview

-             trap stop_preview_and_exit INT

-             start_preview

-             watch_and_build

-             stop_preview

-             exit 0

-             ;;

-         w)

-             watch_and_build

-             exit 0

-             ;;

-         b)

-             build

-             exit 0

-             ;;

-         p)

-             start_preview

-             echo "Please run ./${script_name} -k to stop the preview server"

-             exit 0

-             ;;

-         k)

-             stop_preview

-             exit 0

-             ;;

-         h)

-             usage

-             exit 0

-             ;;

-         u)

-             check_update

-             exit 0

-             ;;

-         U)

-             install_update

-             exit 0

-             ;;

-         ?)

-             usage

-             exit 1

-             ;;

-     esac

- done

@@ -1,150 +0,0 @@ 

- <?xml version="1.0" encoding="UTF-8" standalone="no"?>

- <!-- Created with Inkscape (http://www.inkscape.org/) -->

- 

- <svg

-    xmlns:dc="http://purl.org/dc/elements/1.1/"

-    xmlns:cc="http://creativecommons.org/ns#"

-    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

-    xmlns:svg="http://www.w3.org/2000/svg"

-    xmlns="http://www.w3.org/2000/svg"

-    xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"

-    xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"

-    width="79.375mm"

-    height="105.83334mm"

-    viewBox="0 0 79.375 105.83334"

-    version="1.1"

-    id="svg2794"

-    inkscape:version="0.92.3 (2405546, 2018-03-11)"

-    sodipodi:docname="epel-logo-4.wbackground.svg">

-   <metadata

-      id="metadata17">

-     <rdf:RDF>

-       <cc:Work

-          rdf:about="">

-         <dc:format>image/svg+xml</dc:format>

-         <dc:type

-            rdf:resource="http://purl.org/dc/dcmitype/StillImage" />

-         <dc:title></dc:title>

-       </cc:Work>

-     </rdf:RDF>

-   </metadata>

-   <sodipodi:namedview

-      id="namedview2796"

-      pagecolor="#ffffff"

-      bordercolor="#999999"

-      borderopacity="1"

-      inkscape:pageshadow="0"

-      inkscape:pageopacity="0"

-      inkscape:pagecheckerboard="0"

-      inkscape:document-units="mm"

-      showgrid="false"

-      lock-margins="true"

-      fit-margin-top="0"

-      fit-margin-left="0"

-      fit-margin-right="0"

-      fit-margin-bottom="0"

-      inkscape:zoom="0.95499439"

-      inkscape:cx="263.08967"

-      inkscape:cy="202.09427"

-      inkscape:window-width="1441"

-      inkscape:window-height="745"

-      inkscape:window-x="2145"

-      inkscape:window-y="88"

-      inkscape:window-maximized="0"

-      inkscape:current-layer="layer1"

-      inkscape:snap-nodes="false"

-      inkscape:snap-global="false" />

-   <defs

-      id="defs2791" />

-   <g

-      inkscape:groupmode="layer"

-      id="layer2"

-      inkscape:label="background"

-      transform="translate(142.77219,27.923905)" />

-   <g

-      inkscape:label="Layer 1"

-      inkscape:groupmode="layer"

-      id="layer1"

-      transform="translate(11.617268,-55.791218)">

-     <g

-        id="g932"

-        transform="translate(53.19403,0.27705257)">

-       <g

-          transform="translate(18.671711,82.883966)"

-          id="g912">

-         <rect

-            style="fill:#dfdfdf;fill-opacity:1;stroke:none;stroke-width:5.29166651;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"

-            id="rect891"

-            width="79.375"

-            height="105.83334"

-            x="-83.483009"

-            y="-27.369801"

-            ry="5.6719646" />

-         <rect

-            ry="5.2017727"

-            y="-22.983147"

-            x="-80.193016"

-            height="97.060036"

-            width="72.795013"

-            id="rect908"

-            style="fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:4.85300064;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />

-       </g>

-       <g

-          transform="matrix(1.9956578,0,0,1.9956578,-329.77171,-109.41234)"

-          id="g843">

-         <g

-            transform="matrix(0.26458333,0,0,0.26458333,200.40036,-167.46327)"

-            id="g56815"

-            style="display:inline">

-           <g

-              id="g56813"

-              transform="translate(15.434597,40)">

-             <g

-                aria-label="EPEL"

-                id="text56811"

-                style="font-size:18.18989944px;line-height:0%;letter-spacing:0px;word-spacing:0px;fill:#294172;stroke-width:1.06666994">

-               <path

-                  d="m -228.70596,1059.1423 v -3.9544 h 9.60776 v -4.5721 h -9.60776 v -3.6454 h 10.90527 v -4.7267 h -16.96032 v 21.6252 h 17.36193 v -4.7266 z"

-                  style="font-weight:800;font-size:30.89310074px;line-height:125%;font-family:Montserrat;-inkscape-font-specification:'Montserrat Ultra-Bold'"

-                  id="path3016"

-                  inkscape:connector-curvature="0" />

-               <path

-                  d="m -204.11508,1042.2437 h -9.88579 v 21.6252 h 6.11683 v -5.6534 h 3.76896 c 5.90058,0 9.60775,-3.0585 9.60775,-7.9705 0,-4.9429 -3.70717,-8.0013 -9.60775,-8.0013 z m -0.37072,11.1524 h -3.39824 v -6.3331 h 3.39824 c 2.53324,0 3.79985,1.174 3.79985,3.182 0,1.9772 -1.26661,3.1511 -3.79985,3.1511 z"

-                  style="font-weight:800;font-size:30.89310074px;line-height:125%;font-family:Montserrat;-inkscape-font-specification:'Montserrat Ultra-Bold'"

-                  id="path3018"

-                  inkscape:connector-curvature="0" />

-               <path

-                  d="m -185.48656,1059.1423 v -3.9544 h 9.60775 v -4.5721 h -9.60775 v -3.6454 h 10.90526 v -4.7267 h -16.96031 v 21.6252 h 17.36192 v -4.7266 z"

-                  style="font-weight:800;font-size:30.89310074px;line-height:125%;font-family:Montserrat;-inkscape-font-specification:'Montserrat Ultra-Bold'"

-                  id="path3020"

-                  inkscape:connector-curvature="0" />

-               <path

-                  d="m -170.78148,1063.8689 h 16.43513 v -4.8502 h -10.3183 v -16.775 h -6.11683 z"

-                  style="font-weight:800;font-size:30.89310074px;line-height:125%;font-family:Montserrat;-inkscape-font-specification:'Montserrat Ultra-Bold'"

-                  id="path3022"

-                  inkscape:connector-curvature="0" />

-             </g>

-           </g>

-         </g>

-         <g

-            id="g830">

-           <path

-              id="path57241"

-              style="fill:#51a2da;fill-opacity:1;stroke:none;stroke-width:0.89758563"

-              d="m 149.44371,93.715204 c -0.741,0 -1.33773,0.596709 -1.33773,1.337694 v 1.337704 c 0,0.741003 0.59673,1.33677 1.33773,1.336779 h 1.21522 v 0.769034 c 0,0.219171 0.21735,0.397106 0.49632,0.41653 0.0166,8.88e-4 0.0335,0.0027 0.0505,0.0027 0.002,2.6e-5 0.004,0 0.005,0 h 2.49033 c 0.002,0 0.004,2.6e-5 0.005,0 0.30282,1.8e-5 0.54688,-0.186589 0.54688,-0.418837 V 97.7273 h 8.56518 c 0.741,0 1.33768,-0.595785 1.33771,-1.336779 v -1.337703 c 0,-0.740977 -0.59671,-1.337695 -1.33771,-1.337695 z"

-              inkscape:connector-curvature="0" />

-           <path

-              id="path57243"

-              style="fill:#51a2da;fill-opacity:1;stroke:none;stroke-width:0.89758676"

-              d="m 149.17187,100.09573 c -0.741,1e-5 -1.3377,0.59671 -1.3377,1.33771 v 2.99591 c 0,0.74099 0.5967,1.3377 1.3377,1.3377 h 0.45457 v 0.0134 h 1.03063 v 0.77786 c 0,0.21918 0.21737,0.39707 0.49632,0.41652 0.0166,9.5e-4 0.0335,0.002 0.0506,0.002 h 0.005 2.49035 0.005 c 0.30281,0 0.54685,-0.18659 0.54685,-0.41885 v -0.77785 h 1.03066 v -0.0139 h 0.44343 c 0.741,0 1.33677,-0.59625 1.33677,-1.33724 v -2.99545 c 0,-0.74102 -0.59573,-1.33822 -1.33677,-1.33816 h -1.47221 v 0.77599 c 0,0.23225 -0.24406,0.41886 -0.54688,0.41885 -0.002,2e-5 -0.004,0 -0.005,0 h -2.49033 c -0.002,0 -0.003,2e-5 -0.005,0 -0.0171,0 -0.034,-0.002 -0.0506,-0.003 -0.27897,-0.0194 -0.49632,-0.19736 -0.49632,-0.41653 v -0.77553 z"

-              inkscape:connector-curvature="0" />

-           <path

-              id="path57245"

-              style="fill:#db3279;fill-opacity:1;stroke:none;stroke-width:0.89758563"

-              d="m 142.49261,108.25437 c -0.74099,0 -1.33769,0.59671 -1.33769,1.33771 v 1.33769 c 0,0.74101 0.5967,1.33677 1.33769,1.33678 h 13.37517 c 0.74099,-10e-6 1.33769,-0.59578 1.33769,-1.33677 v -1.33771 c 0,-0.74098 -0.5967,-1.33769 -1.33769,-1.3377 l -0.58538,1e-5 v 0.005 h -1.03064 v 0.77785 c 1e-5,0.23225 -0.24403,0.41885 -0.54684,0.41884 -9e-4,0 -0.004,0 -0.005,0 h -2.49033 c -8.9e-4,0 -0.004,0 -0.005,0 -0.017,0 -0.0339,-0.002 -0.0505,-0.003 -0.27898,-0.0194 -0.4963,-0.19735 -0.49627,-0.41655 v -0.77785 h -1.03065 v -0.004 z"

-              inkscape:connector-curvature="0" />

-         </g>

-       </g>

-     </g>

-   </g>

- </svg>

@@ -1,9 +0,0 @@ 

- This is an example of a example file. Unlike files in `pages/`, files in this directory are not built as standalone pages, but only if they are included in a file within `pages/`. Also unlike examples,

- A file in this directory can be included within any file in the `pages/` directory.

- 

- Most common use cases for examples is using output from an external script (for example, translation string statistics) in docs. You can use an external script to update the example, and when the site is rebuilt, it will show updated output.

- 

- If you want to include this particular example somewhere, you can use the following syntax: `include::example$example-example.adoc[]`.

- Note the use of `example$` instead of an actual file location.

- 

- See link:++https://docs.antora.org/antora/3.0/examples-directory/++[Antora docs on examples] for more information about partials.

file removed
-26
@@ -1,26 +0,0 @@ 

- * xref:getting-started.adoc[How to use EPEL]

- ** xref:available-packages.adoc[Available packages]

- ** xref:epel-testing.adoc[The EPEL-testing repository]

- * xref:epel-package-request.adoc[Requesting a new package]

- * xref:epel-communication.adoc[Communicating with EPEL]

- * xref:epel-help.adoc[Helping EPEL]

- ** xref:epel-qa.adoc[EPEL QA/Testing]

- ** xref:epel-packaging.adoc[Packaging]

- *** xref:epel-packaging-examples.adoc[Packaging examples]

- ** xref:epel-package-maintainers.adoc[Package maintainers]

- *** xref:epel-packagers-sig.adoc[Packagers Special Interest Group]

- *** xref:epel-about-next.adoc[EPEL-Next]

- *** xref:epel-about-playground.adoc[EPEL-Playground]

- *** xref:epel-package-maintainer-generic-description.adoc[EPEL package maintainer generic job description]

- *** xref:epel-rhel-entitlements.adoc[RHEL entitlements]

- * xref:epel-policy.adoc[Guidelines and policies]

- ** xref:branches.adoc[Branches]

- ** xref:epel-policy-updates.adoc[Updates]

- ** xref:epel-policy-incompatible-upgrades.adoc[Incompatible upgrades]

- ** xref:epel-policy-retirement.adoc[Package retirement]

- ** xref:epel-policy-scl.adoc[Software Collections (SCL)]

- ** xref:epel-policy-missing-sub-packages.adoc[Missing RHEL sub-packages]

- ** xref:epel-policy-steering-committee.adoc[Steering committee]

- * xref:epel-about.adoc[About EPEL]

- ** xref:epel-about-history-philosophy.adoc[History and philosophy]

- * xref:epel-faq.adoc[FAQ]

@@ -1,35 +0,0 @@ 

- include::partial$attributes.adoc[]

- :experimental:

- 

- [[available_packages_and_versions_in_epel]]

- == Available packages in EPEL

- 

- Since EPEL is part of the Fedora project, you can search the available packages in the

- link:++https://packages.fedoraproject.org/++[Fedora Packages web app].

- This provides an overview of available versions across various EPEL branches.

- If you find a package that is not yet available in the EPEL branch you would like it to be,

- please follow xref:epel-package-request.adoc[this guide] to request it.

- 

- Alternately, you can browse the repo files directly:

- 

- * EPEL 10:

- link:++https://dl.fedoraproject.org/pub/epel/10/Everything/x86_64/++[x86_64],

- link:++https://dl.fedoraproject.org/pub/epel/10/Everything/s390x/++[s390x],

- link:++https://dl.fedoraproject.org/pub/epel/10/Everything/ppc64le/++[ppc64le],

- link:++https://dl.fedoraproject.org/pub/epel/10/Everything/aarch64/++[aarch64],

- link:++https://dl.fedoraproject.org/pub/epel/10/Everything/source/tree/++[sources]

- * EPEL 9:

- link:++https://dl.fedoraproject.org/pub/epel/9/Everything/x86_64/++[x86_64],

- link:++https://dl.fedoraproject.org/pub/epel/9/Everything/s390x/++[s390x],

- link:++https://dl.fedoraproject.org/pub/epel/9/Everything/ppc64le/++[ppc64le],

- link:++https://dl.fedoraproject.org/pub/epel/9/Everything/aarch64/++[aarch64],

- link:++https://dl.fedoraproject.org/pub/epel/9/Everything/source/tree/++[sources]

- * EPEL 8:

- link:++https://dl.fedoraproject.org/pub/epel/8/Everything/x86_64/++[x86_64],

- link:++https://dl.fedoraproject.org/pub/epel/8/Everything/s390x/++[s390x],

- link:++https://dl.fedoraproject.org/pub/epel/8/Everything/ppc64le/++[ppc64le],

- link:++https://dl.fedoraproject.org/pub/epel/8/Everything/aarch64/++[aarch64],

- link:++https://dl.fedoraproject.org/pub/epel/8/Everything/SRPMS/++[sources]

- 

- You can also browse these same directories on any of our

- link:++https://admin.fedoraproject.org/mirrormanager/mirrors/EPEL++[mirrors].

@@ -1,132 +0,0 @@ 

- include::partial$attributes.adoc[]

- :experimental:

- 

- = EPEL branches

- 

- Fedora and EPEL package sources are maintained in

- link:++https://src.fedoraproject.org++[Fedora's dist-git].

- The default branch is `rawhide`, corresponding to

- xref:releases::rawhide.adoc[Fedora Rawhide].

- Additional branches are used for other Fedora and EPEL releases.

- 

- The rest of this page will describe the specific branches that are used for EPEL packages.

- The general mechanics of working with dist-git branches is covered in greater detail in the

- xref:package-maintainers::Package_Maintenance_Guide.adoc#working_with_branches[Package Maintenance Guide].

- 

- == EPEL 10

- 

- EPEL 10 has separate dnf repositories and dist-git branches

- for each minor version of RHEL 10.

- 

- === epel10

- 

- The `epel10` branch is used to create builds for the leading EPEL 10 minor version repository.

- Prior to the CentOS Stream 10 end of life

- (which corresponds to the end of the RHEL 10

- link:++https://access.redhat.com/support/policy/updates/errata#Life_Cycle_Dates++[Full Support Phase]),

- these builds are built against external repositories of the matching major version of CentOS Stream 10.

- 

- * CentOS Stream 10 BaseOS

- * CentOS Stream 10 AppStream

- * CentOS Stream 10 CRB

- 

- These builds will indicate the minor version they are targeting in their

- xref:packaging-guidelines::DistTag.adoc[dist tag]

- using the format of `.el10_x`,

- where `x` is the minor version.

- They are published in the `pub/epel/10` dnf repository for consumption by CentOS Stream 10,

- which is a symbolic link to the latest `pub/epel/10.x` dnf repository.

- 

- After the CentOS Stream 10 end of life

- (which corresponds to the beginning of the RHEL 10

- link:++https://access.redhat.com/support/policy/updates/errata#Life_Cycle_Dates++[Maintenance Support Phase]),

- these builds are built against external repositories of the final minor version of RHEL 10.

- 

- * RHEL 10.10 BaseOS

- * RHEL 10.10 AppStream

- * RHEL 10.10 CRB

- 

- === epel10.x

- 

- The `epel10.x` branches

- (where `x` is the minor version, e.g. `epel10.0`)

- are used to create builds for the trailing EPEL 10 minor version repositories.

- These builds are built against external repositories of the matching minor version of RHEL 10.

- 

- * RHEL 10.x BaseOS

- * RHEL 10.x AppStream

- * RHEL 10.x CRB

- 

- These builds will indicate the minor version they are targeting in their

- xref:packaging-guidelines::DistTag.adoc[dist tag]

- using the format of `.el10_x`,

- where `x` is the minor version.

- They are published in `pub/epel/10.x` dnf repositories for consumption by the corresponding RHEL 10 minor version.

- 

- === minor branch lifetime

- 

- Each epel10.x branch lifetime depends on its corresponding RHEL 10 minor development and release process.

- 

- Before CentOS 10 starts receiving changes corresponding to a new RHEL minor release,

- a new epel10.x+1 branch is created by cloning the packages of the current active epel10.x branch.

- During this period, new builds against the epel10 branch will start landing in the new epel10.x+1 tag

- to become candidates for the new epel10.x+1 Bodhi release.

- New updates on the epel10.x branch are built against a CentOS 10 snapshot

- until its corresponding RHEL 10 minor release is available.

- 

- When a RHEL10 minor version stops being the leading release, its corresponding

- epel10.x branch goes end-of-life. This means that new package builds won't be

- accepted and its contents will be archived.

- 

- Exceptions to this are the first minor branch, which is made arround the CentOS 10 release,

- and the one associated to the last RHEL minor release, which follows the regular EPEL branch lifetime policies.

- 

- == EPEL 9

- 

- EPEL 9 has two dnf repositories and dist-git branches.

- 

- === epel9

- 

- The `epel9` branch is used to create builds for the EPEL 9 repository.

- These builds are built against external repositories of the matching major version of RHEL 9.

- 

- * RHEL 9 BaseOS

- * RHEL 9 AppStream

- * RHEL 9 CRB

- 

- They are published in the `pub/epel/9` dnf repository for consumption by both RHEL 9 and CentOS Stream 9.

- EPEL 9 has no connection to RHEL 9 minor versions,

- and is always built against the current RHEL 9 minor version.

- 

- === epel9-next

- 

- The `epel9-next` branch is used to create builds for the EPEL 9 Next repository.

- These builds are built against external repositories of the matching major version of CentOS Stream 9.

- 

- * CentOS Stream 9 BaseOS

- * CentOS Stream 9 AppStream

- * CentOS Stream 9 CRB

- 

- They are published in the `pub/epel/next/9` dnf repository for consumption by CentOS Stream 9.

- 

- `epel9-next` branches are optional,

- and maintainers usually do not need to create them.

- You can read more about EPEL 9 Next and when it is needed

- xref:epel-about-next.adoc[here].

- 

- == EPEL 8

- 

- EPEL 8 has a single dnf repository and dist-git branch.

- 

- === epel8

- 

- The `epel8` branch is used to create builds for the EPEL 8 repository.

- These builds are built against external repositories of the matching major version of RHEL 8.

- 

- * RHEL 8 BaseOS

- * RHEL 8 AppStream

- * RHEL 8 CRB

- 

- They are published in the `pub/epel/8` dnf repository for consumption by RHEL 8.

- EPEL 8 has no connection to RHEL 8 minor versions,

- and is always built against the current RHEL 8 minor version.

@@ -1,32 +0,0 @@ 

- include::partial$attributes.adoc[]

- :experimental:

- 

- = History and philosophy of EPEL (Extra Packages for Enterprise Linux)

- 

- [[history_and_philosophy_of_epel_extra_packages_for_enterprise_linux]]

- 

- == History

- 

- The EPEL project was born out of Fedora. There was a need for quality

- 3rd party packages for Enterprise Linux using the already existing

- Fedora infrastructure. Early on there was a move to help consolidate

- existing 3rd parties, which for various reasons ended up mostly failing.

- The EPEL project was formed as a Project rather than a special interest

- group. This entailed a steering committee, formal votes and regular

- progress reports to FESCo. After several years, it was determined that

- EPEL could function just as well as a SIG where folks just got things

- done and reached consensus, so EPEL moved to that model.

- 

- //TODO: Add dates and times and more info here.

- 

- == Philosophy

- 

- EPEL strives to never replace or interfere with packages shipped by

- Enterprise Linux. Packages in EPEL should be supported for the full life

- cycle of the Enterprise Linux they are build against. Additionally, they

- should strive to never require manual update procedures or processes.

- During the stable part of the EPEL cycle, packages shouldn't update in a

- way that changes the user experience or otherwise adds more than

- bugfixes.

- 

- //TODO: add more here. Pull from old faq/update document.

@@ -1,148 +0,0 @@ 

- include::partial$attributes.adoc[]

- :experimental:

- 

- = EPEL Next

- 

- [[epel_next]]

- 

- == Introduction

- 

- EPEL packages are built against RHEL. EPEL Next is an additional

- repository that allows package maintainers to alternatively build

- against CentOS Stream. This is sometimes necessary when CentOS Stream

- contains an upcoming RHEL library rebase, or if an EPEL package has a

- minimum version build requirement that is already in CentOS Stream but

- not yet in RHEL. EPEL Next has its own distgit branches, koji build

- targets, and bodhi releases.

- 

- EPEL Next packages have `.next` appended to the disttag (e.g. a disttag

- of `.el9.next` for epel9-next) to provide an upgrade path from an EPEL

- package that was built from the same distgit commit. A package

- maintainer can rebuild the same commit for both EPEL and EPEL Next and

- get two different NVRs in koji. Within six months, the build requirement

- necessitating building in EPEL Next should be in RHEL, and at that time

- the package maintainer can do a normal release bump commit in the EPEL

- branch and get a newer NVR than both the previous EPEL and EPEL Next

- packages.

- 

- To get started with EPEL Next, request the corresponding branch for the

- EPEL release you are targeting, e.g. request an epel9-next branch to

- rebuild an EPEL 9 package against CentOS Stream 9. Once the branch is

- created you can merge commits from other branches and submit a build

- just like you would for other EPEL or Fedora branches.

- 

- [[example_workflow]]

- == Example workflow

- 

- The workflow for building and releasing a package in EPEL Next is

- intentionally very similar to EPEL itself.

- 

- In this example, the scenario is that you have an EPEL package (built

- against RHEL) that installs on RHEL, but not on CentOS Stream, due to a

- dependency that was rebased in the distro which is destined for the next

- minor release of RHEL. You can use EPEL Next to build a compatible

- package now.

- 

- * `fedpkg request-branch epel9-next` and wait for the branch to be

- created

- * `git checkout epel9-next`

- * `git merge epel9`

- * `git push`

- * `fedpkg build`

- * submit bodhi update via web interface or cli

- 

- This will result in an EPEL Next package that is the same as the

- existing EPEL package, except for the `.next` suffix on the disttag and

- being built against CentOS Stream 9. Your `epel9-next` branches can

- diverge from the corresponding epel9 branches as needed. If an update

- for your EPEL package requires a minimum version of a dependency that is

- only in CentOS Stream so far, you can update in the `epel9-next` branch

- first, then merge from `epel9-next` to `epel9` when the dependency is added

- to the next RHEL minor release.

- 

- == FAQ

- 

- [[how_do_i_enable_epel_next]]

- === How do I enable EPEL Next?

- 

- `dnf install epel-next-release`

- 

- [[if_i_build_my_package_in_epel_do_i_also_need_to_build_my_package_in_epel_next]]

- === If I build my package in EPEL do I also need to build my package in EPEL Next?

- 

- Probably not. Due to the strong compatibility guarantees of RHEL, most

- EPEL packages built against RHEL install just fine on CentOS Stream. But

- there are some situations where it is necessary to rebuild an EPEL

- package to get it to install on CentOS Stream, and EPEL Next exists to

- provide package maintainers a place to do just that.

- 

- [[are_all_epel_packages_also_in_epel_next]]

- === Are all EPEL packages also in EPEL Next?

- 

- No. EPEL Next is designed to be a small overlay on top of EPEL. The

- epel-next-release package requires epel-release.

- 

- [[why_isnt_this_called_epel_stream]]

- === Why isn't this called EPEL Stream?

- 

- The term stream is already massively overloaded. "Next" correctly

- describes the purpose of the repository, which is providing packages

- compatible with the next minor release of RHEL. Additionally, EPEL Next

- isn't exclusively useful for CentOS Stream. It's also useful for:

- 

- * RHEL Beta releases.

- * RHEL itself temporarily at minor release time when an EPEL package was

- already rebuilt for a library change in EPEL Next but hasn't been

- rebuilt in EPEL yet.

- 

- [[when_i_request_an_epel9_branch_will_an_epel9_next_branch_be_requested_automatically]]

- === When I request an epel9 branch, will an epel9-next branch be requested automatically?

- 

- No. That is something that used to happen for xref:epel-about-playground.adoc[EPEL

- Playground]. Most maintainers didn't like it. EPEL Next is opt-in.

- 

- [[can_i_use_epel_next_to_provide_a_newer_version_of_a_package_than_whats_in_epel]]

- === Can I use EPEL Next to provide a newer version of a package than what's in EPEL?

- 

- EPEL Next is bound by the same

- xref:epel-policy.adoc[guidelines and policies] as regular

- EPEL. If a version upgrade is inappropriate for EPEL, it's inappropriate

- for EPEL Next. If a version upgrade is unavoidable because of upcoming

- changes in RHEL, then you must follow the

- xref:epel-policy-incompatible-upgrades.adoc[incompatible upgrades process].

- 

- [[why_is_the_package_im_looking_for_in_epel_but_not_in_epel_next]]

- === Why is the package I'm looking for in EPEL but not in EPEL Next?

- 

- EPEL Next is *not* a complete rebuild of all EPEL packages. Most EPEL

- packages already install on CentOS Stream correctly. EPEL Next is an

- additional repository to be used with regular EPEL (not instead of) to

- resolve the occasional compatibility issue. If you install both

- epel-release and epel-next-release, `dnf install ` should pick the

- correct available package from the appropriate repository. If that

- doesn't work, please file a

- link:++https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora%20EPEL++[bug] to

- let the maintainer know.

- 

- [[how_do_i_report_a_package_that_needs_to_be_rebuilt_in_epel_next]]

- === How do I report a package that needs to be rebuilt in EPEL Next?

- 

- File a

- link:++https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora%20EPEL++[bug] to

- let the maintainer know.

- 

- [[why_does_epel_next_release_require_epel_release]]

- === Why does epel-next-release require epel-release?

- 

- If you try to install only epel-next-release without epel-release

- available, you'll see an error like this.

- 

- ----

- Error:

-  Problem: conflicting requests

-   - nothing provides epel-release = 9-7.el9 needed by epel-next-release-9-7.el9.noarch from @commandline

- ----

- 

- This is because epel-next-release intentionally requires epel-release. EPEL

- Next is designed to be used _with_ EPEL, not as a replacement. EPEL Next

- packages will often require other packages in EPEL. 

@@ -1,16 +0,0 @@ 

- include::partial$attributes.adoc[]

- :experimental:

- 

- = EPEL Playground

- 

- [WARNING]

- ====

- *EPEL Playground was shut down in January 2022*

- ====

- 

- EPEL 8 Playground was a place that developers and maintainers could "play around"

- with updated, or changed packages in epel.  EPEL Playground never really worked

- out and ended up being more burden than helpful.

- 

- If developers or maintainers want something similar to EPEL Playground we

- recommend link:++https://copr.fedorainfracloud.org/++[Fedora COPR], which has availability for EPEL builds.

@@ -1,131 +0,0 @@ 

- include::partial$attributes.adoc[]

- :experimental:

- 

- = About EPEL

- 

- [[about_epel]]

- 

- EPEL was started because many Fedora contributors wanted to use the

- Fedora packages they maintain on Red Hat Enterprise Linux (RHEL) and its

- compatible derivatives.

- 

- [[goals_of_the_epel_effort]]

- == Goals of the EPEL effort

- 

- Make high quality packages that have been developed, tested, and

- improved in Fedora available for RHEL and compatible derivatives such as

- Alma and Rocky Linux.

- 

- Work closely with the Fedora Project to achieve this goal -- use the

- same guidelines, rules, policies, and infrastructure, as far as

- possible.

- 

- If we hit problems, solve the problems with the other parties and groups

- of Fedora, such as Packaging Committee, instead of creating EPEL-only

- solutions; EPEL-only solutions introduce confusion for packagers and

- users, and make porting packages between Fedora and EPEL harder.

- 

- For the rare cases where it is not possible or desired to remain

- synchronized with Fedora, maintain add-on documents for EPEL that

- describe the differences and the reasons for them.

- 

- [[who_needs_these_packages]]

- == Who needs these packages

- 

- [[enterprise_linux_useradministrator_perspective]]

- === Enterprise Linux user/administrator perspective

- 

- Every user and admin has experienced at least one desired package not

- being included and supported in RHEL. This project gives you a place to

- promote, support, and benefit from packages that exist in Fedora and

- were not included in a RHEL version.

- 

- Whether it is a package your company needs as part of its standard

- install, or software you want available so you and your users can do

- your work and have your fun, Fedora enterprise packages are a good

- method to build support and community around particular software needs.

- 

- [[community_perspective]]

- === Community perspective

- 

- Many members of the Fedora community

- are also users/administrators of Enterprise Linux distributions that are derived from Fedora,

- such as CentOS Stream and RHEL.

- Everyone has their own reasons for promoting a particular piece of software.

- EPEL packages are the best way to gain users and support from Enterprise Linux users.

- 

- [[isvihv_perspective]]

- === ISV/IHV perspective

- 

- The benefits of building upon EPEL as an ISV or IHV have great

- potential. If your software package currently packages its own copies of

- open source libraries or well-known tools, you can rely upon EPEL to

- provide those packages. For example, Perl modules are often needed and

- repackaged, yet can be available through EPEL instead. You let

- dependencies be met by EPEL, and your team concentrates on what they do

- best: develop, support, and provide your product(s).

- 

- Additionally, if you are on an ISV/IHV team that utilizes open source

- software packages to deliver your products, you have the opportunity to

- contribute to EPEL. This ensures a community of support, review, and

- testing for packages that your customers depend on for your products.

- 

- For independent software and hardware vendors, this is how you get your

- software into the enterprise ecosystem:

- 

- . Use the Fedora process to get your favorite software in to the

- repository:

- * Get an entirely new package into Fedora.

- * Become a co-maintainer for the package you want to have

- enterprise-level longevity.

- * Package a free and open source library or other shareable software

- source to build a community around your applications.

- . Gain the additional six to twelve months of Fedora testing and

- feedback.

- . Be ready for RHEL beta testing before the alpha snapshot is taken,

- gaining another three to six months lead time.

- . Ship your enterprise-ready version with the RHEL GA.

- . Ongoing support and package maintenance is a part of your free and

- open source development process, along with advancing the technology in

- parallel in Fedora.

- 

- [[academia_perspective]]

- == Academia perspective

- 

- Aside from the usual need for software that wasn't included in RHEL,

- there is a large opportunity for academia to provide students with

- learning opportunities beyond piecemeal open source project experience.

- 

- Where a typical free and open source learning experience for a student

- might be to dive into coding or documentation, Fedora enterprise

- packaging is one way to gain cross-over experience. The real-world,

- hands-on experience includes supporting a free and open source community

- and user base, creating an enterprise community around the software, and

- managing feature enhancements, bug fixes, and security updates across

- all communities.

- 

- [[red_hat_perspective]]

- == Red Hat perspective

- 

- This is a simple imagination exercise.

- 

- ''Imagine you are a company that enables a large, fully open and free

- Linux based distribution for the general world communities (cf. Fedora),

- while supporting a large, fully open Linux based distribution for its

- customers (cf. RHEL).

- 

- Imagine that what is in your enterprise distribution is what you think

- you can support for your customers, and is influenced by what those

- customers are asking for. Would it be in your best interest, or the best

- interest of your customers, to pull in every single software package you

- possibly could? Would you be able to provide QA and support on such a

- large package set?

- 

- Imagine that it is easier to pick your package set (the ones you

- support), and to enable the promotion and community support of

- enterprise-quality packages.

- 

- If you look around, you see that people have put in great effort to

- provide these packages that did not make it into RHEL. The Fedora

- enterprise packages are a way of enabling, growing, and honoring the

- work that has come before.''

@@ -1,46 +0,0 @@ 

- include::partial$attributes.adoc[]

- :experimental:

- 

- [[communicating_with_epel]]

- == Communicating with EPEL

- 

- There are many ways to communicate with EPEL and its members:

- 

- * The link:++https://matrix.to/#/#epel:fedoraproject.org++[epel:fedoraproject.org] channel on offers real-time

- support for EPEL users and developers.

- 

- * The link:++https://web.libera.chat/?channels=#epel++[#epel] IRC channel on

- link:++https://libera.chat++[Libera Chat] is a secondary chat location, but is not bridged to Matrix.

- 

- * The link:++https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org/++[epel-devel]

- mailing list is for general EPEL discussion.

- link:++https://www.redhat.com/archives/epel-devel-list/++[Historic archives] are available.

- 

- * The

- link:++https://lists.fedoraproject.org/admin/lists/epel-announce@lists.fedoraproject.org/++[epel-announce]

- mailing list is a low volume mailing list for only important announcements.

- 

- * The

- link:++https://lists.fedoraproject.org/admin/lists/epel-package-announce@lists.fedoraproject.org/++[epel-package-announce]

- mailing list is a list that gets information about package updates as they

- happen in the stable repository.

- 

- * If you find a bug in a EPEL maintained package, please report it to

- link:++https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora+EPEL++[https://bugzilla.redhat.com/]

- under the "Fedora EPEL" product.

- 

- * Infrastructure issues (mirrors, repos, etc.) should be reported to

- link:++https://pagure.io/releng/issues++[Fedora releng].

- 

- * The EPEL Steering Committee meets on Wednesday every week in the

- link:++https://chat.fedoraproject.org/#/room/#meeting-1:fedoraproject.org++[Fedora Meeting 1]

- Matrix channel.  The time is **not** tied to U.S. daylight savings time, so it is at 

- 18:00 UTC regardless of the time of year. Please check the time on the

- link:++https://calendar.fedoraproject.org/epel/++[epel calendar]; sometimes

- it can change or a meeting can be skipped. Feel free to join us! Logs of

- past meetings can be viewed in

- link:++https://meetbot.fedoraproject.org/sresults/?group_id=epel&type=team++[meetbot].

- 

- * The EPEL Steering Committee has

- link:++https://discussion.fedoraproject.org/t/join-us-for-the-epel-office-hours-every-month/37235++[monthly

- office hours for the EPEL project].

@@ -1,557 +0,0 @@ 

- include::partial$attributes.adoc[]

- :experimental:

- 

- = Frequently Asked Questions (FAQ)

- 

- == About

- 

- [[what_is_epel]]

- === What is EPEL?

- 

- Extra Packages for Enterprise Linux (EPEL) is an initiative within the

- link:++https://fedoraproject.org/++[Fedora Project]

- to provide high quality additional packages for

- link:++https://centos.org/++[CentOS Stream] and

- link:++https://redhat.com/rhel++[Red Hat Enterprise Linux] (RHEL).

- EPEL packages will also likely work with other distributions

- that target RHEL compatibility.

- 

- As part of the Fedora packaging community, EPEL packages are 100%

- free/libre open source software (FLOSS).

- 

- [[why_is_the_fedora_project_sponsoring_epel]]

- === Why is the Fedora Project sponsoring EPEL?

- 

- A large number of contributors and users of Fedora and Enterprise Linux

- want to work within Fedora to provide these packages.

- 

- The Fedora Project is a user of EPEL packages within the Fedora

- infrastructure itself. The Fedora Project is in a position to know the

- pain of not having a desired piece of software included in the RHEL

- distribution, and also a unique position to do something about it.

- Although RHEL is derived from Fedora, only a commercially supported

- subset of Fedora derived packages are included in the RHEL distribution.

- By sponsoring the EPEL project, Fedora contributors and users gain in

- many ways.

- 

- [[is_epel_commercially_supported_by_red_hat]]

- === Is EPEL commercially supported by Red Hat?

- 

- No. EPEL is a volunteer effort from the Fedora community. Just like

- Fedora itself, Red Hat hosts infrastructure for this project and Red Hat

- engineers are involved as maintainers and leaders but there are no

- commercial support contracts or service level agreements provided by Red

- Hat for packages in EPEL.

- 

- [[which_distributions_and_releases_does_epel_provides_packages_for]]

- === Which distributions and releases does EPEL provides packages for?

- 

- EPEL provides packages for

- CentOS Stream 10,

- CentOS Stream 9,

- Red Hat Enterprise Linux 9,

- and Red Hat Enterprise Linux 8.

- EPEL packages will also likely work with other distributions

- that target RHEL compatibility.

- Packages for earlier versions of CentOS Stream and RHEL are no longer provided

- because these versions are end of life.

- 

- [[how_is_epel_different_from_other_third_party_repositories_for_rhel]]

- === How is EPEL different from other third party repositories for RHEL?

- 

- * EPEL packages are in most cases built or derived from the equivalent

- ones in Fedora repository and maintained by the same people. It has also

- been improved through peer reviews, testing and feedback from end users.

- * EPEL adheres to the well documented xref:packaging-guidelines::index.adoc[Fedora

- Packaging guidelines], which RHEL has started following. This ensures

- good integration.

- * EPEL is purely a complementary add-on repository and does not replace

- packages in RHEL.

- * EPEL has a large team of contributors including Red Hat engineers and

- volunteer community members working together to maintain the repository.

- * EPEL only provides free and open source software unencumbered by

- patents or any legal issues.

- 

- [[can_i_rely_on_these_packages]]

- === Can I rely on these packages?

- 

- The EPEL project strives to provide packages with both high quality and

- stability. However, EPEL is maintained by a community of people who

- generally volunteer their time and no commercial support is provided. It

- is the nature of such a project that packages will come and go from the

- EPEL repositories over the course of a single release. In addition, it

- is possible that occasionally an incompatible update will be released

- such that administrator action is required. By policy these are

- announced in advance in order to give administrators time to test and

- provide suggestions.

- 

- It is strongly recommended that if you make use of EPEL, and especially if you

- rely upon it, that you subscribe to the

- link:++https://lists.fedoraproject.org/admin/lists/epel-announce.lists.fedoraproject.org/++[epel-announce]

- list. Traffic on this list is kept to a minimum needed to notify administrators

- of important updates.

- 

- [[what_is_epel_next]]

- === What is EPEL-Next?

- 

- EPEL packages are built against RHEL. EPEL Next packages are built against CentOS Stream.

- 

- EPEL-Next is not a complete rebuild of all the EPEL packages, but only those packages that need to be rebuilt to install on CentOS Stream. The EPEL-Next repo is meant to be layered on top of the regular EPEL repository.

- 

- Learn more about EPEL-Next on the following page:

- 

- * xref:epel-about-next.adoc[EPEL Next]

- 

- == Packages

- 

- [[does_epel_replace_packages_provided_within_red_hat_enterprise_linux]]

- === Does EPEL replace packages provided within Red Hat Enterprise Linux?

- 

- No. EPEL is purely a complementary repository that provide add-on packages.

- EPEL packages will not conflict with any of the channels that it builds against, with limited exceptions

- (see xref:epel-policy.adoc#conflicts_in_compat_packages[conflicts in compat packages]).

- Those specific channels are listed in the xref:epel-policy.adoc#_policy[EPEL policy].

- 

- It is permitted for EPEL to provide an alternative non-modular package to

- any package found only in a non-default RHEL module.

- 

- EPEL will coordinate with other channels/products to minimize any

- conflicts, but may replace or cause issues with other channels.

- 

- [[what_is_the_policy_on_updates_for_packages_in_epel]]

- === What is the policy on updates for packages in EPEL?

- 

- Refer to the xref:epel-policy.adoc[EPEL package maintenance

- and updates] policy for all the details.

- 

- [[how_does_fedora_project_ensure_the_quality_of_the_packages_in_epel]]

- === How does Fedora Project ensure the quality of the packages in EPEL?

- 

- Packages are peer reviewed against extensive

- xref:packaging-guidelines::index.adoc[packaging guidelines] before being imported into

- the repository. Only updates that fix important bugs get pushed to the

- stable repository directly. Other updates hit a testing repository first

- and get released as an EPEL scheduled update in parallel with the EL

- scheduled updates. Packages often are tested in Fedora, too. The Fedora

- Packaging Guidelines and QA team back up all these efforts, helping to

- avoid errors. There are also discussions for more strict QA policies. Do

- participate and help us.

- 

- [[how_long_are_epel_packages_updated]]

- === How long are EPEL packages updated?

- 

- Ideally EPEL packages are maintained as long as the corresponding RHEL

- release is supported. However, EPEL is a volunteer effort, and a package

- maintainer can retire their EPEL branch at any time.

- 

- [[how_can_we_be_sure_that_someone_will_maintain_the_packages_until_end_of_life_of_the_distribution_the_packages_were_built_for]]

- === How can we be sure that someone will maintain the packages until end of life of the distribution the packages were built for?

- 

- The only way to be sure is to do it yourself, which is coincidentally

- the reason EPEL was started in the first place.

- 

- Software packages in EPEL are maintained on a voluntary basis. If you

- want to ensure that the packages you want remain available, get involved

- directly in the EPEL effort. More experienced maintainers help review

- your packages and you learn about packaging. If you can, get your

- packaging role included as part of your job description; EPEL has

- written a xref:epel-package-maintainer-generic-description.adoc[generic

- description] that you can use as the basis for adding to a job

- description.

- 

- We do our best to make this a healthy project with many contributors who

- take care of the packages in the repository, and the repository as a

- whole, for all releases until RHEL closes support for the distribution

- version the packages were built for. That is ten years after release

- (currently) -- a long time frame, and we know a lot can happen in ten

- years. Your participation is vital for the success of this project.

- 

- [[what_if_my_isvihv_wants_to_maintain_a_package_in_epel]]

- === What if my ISV/IHV wants to maintain a package in EPEL?

- 

- Software and hardware vendors are encouraged to get involved in EPEL.

- For more information, read the xref:epel-about.adoc#isvihv_perspective[

- ISV/IHV perspective].

- 

- [[why_isnt_a_package_in_epel_9_when_it_is_in_epel_8]]

- === Why isn't a package in EPEL 9 when it is in EPEL 8?

- 

- Packages are not automatically branched for each EPEL version.

- Each package must be branched by a packager for each particular release,

- and packagers may or may not be interested in EPEL 9 while they were interested in EPEL 8.

- If you are an EPEL 9 user and want to see a particular package added,

- it's a good idea to ask the existing EPEL or Fedora maintainer.

- This lets the current maintainer know that there are real users who would benefit from the package

- (instead of simply guessing at the size of the user base).

- 

- To request an EPEL package for a particular EPEL branch,

- follow the xref:epel-package-request.adoc[EPEL package request steps].

- 

- [[are_games_or_similar_packages_not_strictly_meant_for_enterprise_users_allowed_and_wanted]]

- === Are games or similar packages not strictly meant for enterprise users allowed and wanted?

- 

- Yes. There are people that use EL distributions on their home desktop or

- similar scenarios because Fedora's release and updates cycle is faster

- than required for them. Some of those people want to play games or use

- other non-enterprise oriented software. Having such packages in the

- repository doesn't affect anyone that uses EL distributions for other

- needs.

- 

- [[why_dont_you_simply_rebuild_all_fedora_packages_for_rhel_that_are_not_part_of_it]]

- === Why don't you simply rebuild all Fedora packages for RHEL that are not part of it?

- 

- We require maintainers to take ownership and commit to maintaining the

- packages in the long term. Merely rebuilding all the packages

- automatically has higher potential for packages being broken or

- orphaned.

- 

- [[what_if_the_epel_package_is_added_to_rhel]]

- === What if the EPEL package is added to RHEL?

- If the package is added to RHEL it must be retired from EPEL as it is no longer

- an "extra package for enterprise linux".  There is some automation in place to

- file a ticket to give the EPEL maintainer a heads up; see the

- xref:package-maintainers::Package_Retirement_Process.adoc#_epel[EPEL package retirement process]

- for more information.

- 

- 

- [[using_epel]]

- == Using EPEL

- 

- [[how_can_i_install_the_packages_from_the_epel_software_repository]]

- === How can I install the packages from the EPEL software repository?

- 

- Follow the instructions on the

- xref:getting-started.adoc[getting started page].

- 

- [[where_is_the_software_repository_located]]

- === Where is the software repository located?

- 

- EPEL packages are located at the link:++https://dl.fedoraproject.org/pub/epel/++[main mirror]. 

- There are mirrors available at the

- link:++https://admin.fedoraproject.org/mirrormanager/mirrors/EPEL++[mirror list].

- 

- The snapshots of the EPEL repository are available in an

- link:++https://archives.fedoraproject.org/pub/archive/epel/++[EPEL archive].

- Those are useful when a package was removed from EPEL, e.g. because the

- package was added into a later RHEL version and you have not yet

- migrated to the latest RHEL version.

- 

- [[ipv6_download_server]]

- === Can an IPv6-only host connect to main download server?

- 

- The main fedora download server is currently ipv4 only.

- 

- * link:++https://dl.fedoraproject.org/pub/epel/++[]

- 

- It is recommended that you find the closest ipv6 mirror from the mirror list.

- 

- *  link:++https://admin.fedoraproject.org/mirrormanager/mirrors/EPEL++[]

- 

- If you must connect directly to a fedora ipv6 download server, go here.

- 

- * link:++https://download-ib01.fedoraproject.org/pub/epel/++[]

- 

- [[where_can_i_find_help_or_report_issues]]

- === Where can I find help or report issues?

- 

- You can find help or discuss issues on the

- link:++https://admin.fedoraproject.org/mailman/listinfo/epel-devel++[epel-devel]

- mailing list or IRC channel #epel on libera.chat. Report issues against

- EPEL via

- link:++https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora%20EPEL++[Bugzilla].

- More options are available to

- xref:epel-communication.adoc[communicate with EPEL].

- 

- [[how_do_i_know_that_a_package_is_a_epel_package]]

- === How do I know that a package is a EPEL package?

- 

- All EPEL packages are signed with an official EPEL gpg-key. The public

- key IDs can be found at link:++https://getfedora.org/security/++[]. The keys are

- included in epel-release and dnf will ask you to import it the first

- time you install an EPEL package.

- 

- [[how_can_i_find_out_if_a_package_is_from_epel]]

- === How can I find out if a package is from EPEL?

- 

- If you want to find out if a package comes from EPEL, use a query such

- as this:

- 

- [,console]

- ----

- $ rpm -qp foo-0.1-5.el5.i386.rpm --qf '%{NAME}-%{VERSION}-%{RELEASE} %{VENDOR}\n'

- foo-0.1-5.el5 Fedora Project

- $ rpm -qp foo-0.1-5.el5.i386.rpm --qf '%{NAME}-%{VERSION}-%{RELEASE} %{DISTRIBUTION}\n'

- foo-0.1-5.el5 Extras Packages for Enterprise Linux

- $ rpm -qp foo-0.1-5.el5.i386.rpm --qf '%{NAME}-%{VERSION}-%{RELEASE} %{SIGPGP}\n'

- foo-0.1-5.el5 883f030500468e3e4e119cc036217521f611025863009f5fe424c6fe4bc81a57f45722e465e71381dda2f6009f7c08e1743794b5b9a5a4cd149081092801a5d935

- ----

- 

- Or you can install and run the 'keychecker' script to list all packages

- signed with a particular key as well as which repo they came from.

- 

- [[is_epel_upstream_or_an_official_package_repository_like_fedora_extras_was]]

- === Is EPEL "upstream" or "an official package repository" (like Fedora Extras was)?

- 

- EPEL is just one of several add-on repositories with RPM packages for RHEL.

- It is not an official repository.

- The different repositories serve different user bases or follow different ideas.

- 

- Just like RHEL itself, EPEL in reality is more a "downstream" in the

- sense that Fedora is upstream and EPEL, just like Red Hat, takes

- packages for its product that are constantly developed, tested and

- receive feedback in Fedora. Red Hat, through their sponsorship for the

- Fedora project and participation of Red Hat maintainers, continues to

- back EPEL, but Red Hat has not endorsed EPEL or commercially supported

- it.

- 

- The EPEL maintainers are well aware that EPEL can't serve all needs, and

- that other repositories are likely needed, for types of software the

- Fedora project won't provide, which currently includes packages for EPEL

- with a rolling release model or non-free and patent encumbered software.

- 

- 

- [[contributing_to_epel]]

- == Contributing to EPEL

- 

- [[who_can_contribute_to_epel]]

- === Who can contribute to EPEL?

- 

- Anyone may contribute to EPEL. If you are using RHEL or compatible spin-offs,

- and you have the required skills for maintaining packages or are

- willing to learn, you are welcome to contribute.

- 

- [[how_do_i_get_my_packages_into_epel]]

- === How do I get my packages into EPEL?

- 

- You have to follow the same

- xref:package-maintainers::Package_Maintenance_Guide.adoc[process]

- as Fedora except that you request an EPEL branch such as epel8, epel9, or epel10.

- 

- [[how_do_i_request_a_epel_branch_for_an_existing_fedora_package]]

- === How do I request a EPEL branch for an existing Fedora package?

- 

- Look xref:epel-package-request.adoc[here for the procedure used

- to get a Fedora package in EPEL].

- 

- [[i_maintain_a_package_in_fedora._do_i_have_to_maintain_it_for_epel]]

- === I maintain a package in Fedora. Do I have to maintain it for EPEL?

- 

- No. You can if you want, or you can ask someone else to maintain the

- package in EPEL for you. In some cases, you may be approached by a

- current EPEL maintainer who wants to maintain your package in EPEL.

- 

- [[i_maintain_a_package_in_fedora_and_want_to_maintain_packages_in_epel_too_but_i_dont_have_a_rhel_subscription_for_testing]]

- === I maintain a package in Fedora and want to maintain packages in EPEL, too, but I don't have a RHEL subscription for testing?

- 

- Please see

- xref:epel-rhel-entitlements.adoc[this page]

- for information about getting a free RHEL subscription for EPEL package maintenance.

- 

- [[im_a_fedora_contributor_and_want_to_maintain_my_packages_in_epel_too._what_do_i_have_to_do_and_what_do_you_expect_from_me]]

- === I'm a Fedora contributor and want to maintain my packages in EPEL, too. What do I have to do and what do you expect from me?

- 

- All Fedora packagers can request EPEL branches in Git via the normal

- procedure. Please keep in mind that by building your packages in EPEL we

- expect that you are aware of the xref:epel-policy.adoc[

- special EPEL guidelines and policies] and that you will adhere to them.

- You should also plan to maintain the packages for the near future --

- ideally for several years, or for the full planned lifetime of EPEL.

- Remember that RHEL has a planned lifetime of 10 years.

- 

- You may want to look into formalizing your packaging role in your

- company or other organization. If you can do that, this

- xref:epel-package-maintainer-generic-description.adoc[generic job

- description] may help. Aside from making sure that you are recognized

- for the value you give your organization, formal role recognition

- ensures that your organization has someone continuing to maintain the

- package, even if someone new is in the role.

- 

- It is the maintainer's responsibility to ensure that their EPEL packages work on RHEL.

- Please see

- xref:epel-rhel-entitlements.adoc[this page]

- for information about getting a free RHEL subscription for EPEL package maintenance.

- 

- [[how_do_you_make_sure_that_packages_in_epel_and_in_fedora_do_not_split]]

- === How do you make sure that packages in EPEL and in Fedora do not split?

- 

- The plan is to have one primary maintainer per package who is

- responsible for making certain that the package enhancements applied to

- one tree find their way into the other trees (for example, Fedora devel).

- 

- This maintainer decides what makes sense to apply for the package in

- general. New EL branches for new EL releases are normally created from

- the associated Fedora branch on which the EL release is based.

- Therefore, the EL maintainer has a genuine interest in getting

- enhancements merged into Fedora.

- 

- [[will_my_packages_from_fedora_simply_build_unchanged_on_epel]]

- === Will my packages from Fedora simply build unchanged on EPEL

- 

- Most likely they will build unchanged. However, there are specific items

- to consider. All your build requirements in the package must be part of

- RHEL or EPEL.

- 

- [[i_need_to_build_a_package_that_in_turn_requires_another_one_i_have_just_added._how_do_i_do_this]]

- === I need to build a package that in turn requires another one I have just added. How do I do this?

- 

- You will need to request a buildroot override in bodhi.

- 

- [[how_can_i_know_which_packages_are_part_of_rhel]]

- === How can I know which packages are part of RHEL?

- 

- The easiest ways to do this are to either use the

- xref:epel-rhel-entitlements.adoc[RHEL developer subscription]

- or check the RHEL package manifests.

- 

- * link:++https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html-single/package_manifest/index++[RHEL 9 package manifest]

- * link:++https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html-single/package_manifest/index++[RHEL 8 package manifest]

- 

- You can also check the package source repos in the

- link:++https://gitlab.com/redhat/centos-stream/rpms++[CentOS Stream GitLab space].

- Note that a GitLab branch corresponds to the same major version of RHEL,

- e.g. the c9s branch for RHEL 9.

- If a branch has a `dead.package` file,

- that means it was removed during development of that RHEL version

- and is thus eligible for EPEL.

- 

- [[i_want_to_build_packages_for_epel_but_some_of_my_packages_dependencies_are_not_available_in_epel____or____id_like_to_see_a_fedora_package_in_epel_that_is_not_yet_available_there]]

- === I want to build packages for EPEL but some of my packages dependencies are not available in EPEL -- or -- I'd like to see a Fedora package in EPEL that is not yet available there

- 

- See xref:epel-package-request.adoc[here how to get a Fedora

- package in EPEL].

- 

- [[rhel_8_has_binaries_in_the_release_but_is_missing_some_corresponding__devel_package._how_do_i_build_a_package_that_needs_that_missing__devel_package]]

- === RHEL 8 has binaries in the release, but is missing some corresponding -devel package. How do I build a package that needs that missing -devel package?

- 

- There is a short term and a long term solution. These two solutions

- should be used together.

- 

- * Short Term: Create an epel package that only has the missing packages.

- ** Be prepared to maintain this package as long as it is needed.

- ** It is recommended that you name it `<package>-epel`

- ** It is recommended that you add the epel-packagers-sig group as a

- co-maintainer

- ** It qualifies for an exception to the xref:packaging-guidelines::ReviewGuidelines.adoc[package review process] so you can request the repo with

- *** `fedpkg request-repo --exception <package>-epel`

- ** Once the repo is created, you must retire the rawhide branch to make it clear that this is an EPEL-only package and it shouldn't be branched for future Fedora releases

- *** `fedpkg retire 'EPEL-only package'`

- ** If you need help building this, ask for help. We have some examples.

- ** When/If the missing package(s) are added to RHEL CRB, retire your

- `-epel` package.

- 

- * Long Term: Request the package be added to RHEL 8 and 9 CRB

- repository.

- ** To initiate this process, please file an issue in

- link:++https://issues.redhat.com++[] and request it be added to RHEL 8 and 9.

- Report the bug against the RHEL project, assign it to the proper 

- CentOS Stream versions and add the source package name in the Component field.

- More details on this can be found in the

- link:++https://docs.centos.org/en-US/stream-contrib/quickstart/#_1_file_an_issue++[CentOS contributor guide].

- ** Be sure to say that it is impacting an EPEL build, and which package

- it is impacting.

- 

- [[can_i_bring_a_modular_package_into_EPEL]]

- === Can I bring a modular package into EPEL? ===

- 

- When EPEL 8 was launched, it came together with the EPEL 8 

- Modular repo as an effort to bring modular packages to EPEL. After years of struggle, 

- link:++https://lists.fedoraproject.org/archives/list/epel-announce@lists.fedoraproject.org/thread/LNNPYQU6OLT2OMGKJM6DXLCE5RIJ57HJ/++[it was decided] 

- to disable by default the EPEL 8 Modular repository on October 31st 2022, and then 

- to archive the repository from Febraury 14th 2023 onward. 

- Currently there is no plan to bring modularity back to EPEL.

- 

- If you want to bring a package that is distributed as modular in Fedora

- you will need to create a 

- link:++https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/#multiple++[non-modular version of the package].

- 

- == Miscellaneous

- 

- [[i_want_to_get_a_package_into_epel._what_do_i_have_to_do]]

- === I want to get a package into EPEL. What do I have to do?

- 

- Get it in Fedora first.  This isn't a strict rule, but all the EPEL

- packages need to meet the Fedora packaging guidelines.  If people

- want it in EPEL, they probably want it in Fedora as well.

- 

- If it is in Fedora, and you are the maintainer, branch and build it

- as you would any other Fedora release.

- 

- If it is in Fedora, and you are NOT the maintainer, follow the

- xref:epel-package-request.adoc[EPEL package request steps].

- 

- [[is_it_possible_to_get_a_package_only_into_epel_and_not_fedora]]

- === Is it possible to get a package only into EPEL and not Fedora?

- 

- Simply go through the review process for Fedora and specify only EL

- targets for the initial import. Due to technical reasons, a main

- branch for Rawhide will always be created. Therefore

- xref:package-maintainers::Package_Retirement_Process.adoc[retire the package] directly

- in Fedora Rawhide to avoid confusion. But note that maintaining packages

- in Fedora has many advantages for you, you should consider maintaining

- the package in both Fedora and EPEL if it makes for the package to be in

- Fedora.

- 

- [[what_do_i_have_to_do_to_get_a_package_removed_from_epel]]

- === What do I have to do to get a package removed from EPEL?

- 

- Please follow the xref:package-maintainers::Package_Retirement_Process.adoc[Package retirement process].

- 

- [[what_do_i_need_to_do_if_i_need_to_get_a_updated_package_quickly_into_the_epel_proper]]

- === What do I need to do if I need to get a updated package quickly into the EPEL proper?

- 

- Please do not try and push your packages directly to stable unless they

- are security updates or critical bug fixes. This is enforced by epel

- rel-eng/signers who will change your request to testing unless your

- update meets the criteria for pushing to stable.

- 

- Normal updates spend a weeks in testing before being pushed to stable.

- If enough people test those updates and give your package sufficient karma in bodhi

- it can be pushed to stable before that week is up.

- 

- [[why_doesnt_epel_use_repotags]]

- === Why doesn't EPEL use repotags?

- 

- There were a lot of long discussions in the months of EPEL about using

- repotags or not. Lots of people from inside and outside of Fedora and

- EPEL, as well as maintainers from other repositories, participated in

- those discussions. No real agreement could be found as to whether the

- benefits outweigh the disadvantages - part of the problem was that

- people sometimes couldn't agree on the benefits or disadvantages

- repotags have (or if there are any). The final decision in three voting

- sessions (one done by FESCo before EPEL had a Steering Committee and

- twice done by EPEL's first Steering Committee) was to go without

- repotags in EPEL.

- 

- [[is_epel_willing_to_cooperate_with_other_third_party_repositories]]

- === Is EPEL willing to cooperate with other third party repositories?

- 

- EPEL is always willing to discuss cooperation with other parties and

- repositories and encourages maintainers to do so whenever possible.

- 

- [[what_about_compatibility_with_other_third_party_repositories]]

- === What about compatibility with other third party repositories?

- 

- Mixing different RPM repositories that were not designed to be mixed

- can lead to incompatibilities that often result in dependency resolution problems in dnf.

- Sometimes it even happens that software is not working as expected

- if libraries and applications come from different repositories.

- EPEL is designed as an add-on repository for RHEL.

- The best way to avoid problems is to avoid mixing EPEL

- with other third party repositories that have conflicting packages on the same system.

- Some people nevertheless do it and the dnf priorities plugin can help to avoid the worst problems.

- 

- If you encounter a problem where packages from EPEL are incompatible with another repository,

- or lead dnf to bail out during dependency resolution,

- please report a bug in link:++https://bugzilla.redhat.com++[Bugzilla]

- and contact the maintainer of the other repositories.

- The EPEL project encourages its maintainers to solve such problems together

- with the maintainers from other repositories

- in order to find a solution that is acceptable for both sides.

- However, there is no guarantee such a solution can or will be found in every case,

- as technical solutions to solve a repository-mixing issue

- might have side-effects or drawbacks for one of the repositories involved.

- 

- [[other_questions]]

- == Other questions?

- 

- You can contact the xref:#where_can_i_find_help_or_report_issues[EPEL team].

@@ -1,19 +0,0 @@ 

- include::partial$attributes.adoc[]

- :experimental:

- :page-aliases: help.adoc, contribute.adoc

- 

- = Joining EPEL =

- 

- There are many ways to join in and help out with EPEL. A few are listed below. If you think of another way to help out, feel free to bring it up on our mailing list or at our weekly meetings.

- 

- == Maintaining packages ==

- 

- Package Maintainers update, fix bugs and improve packages in the EPEL collection. See the xref:epel-package-maintainers.adoc[EPEL package maintainers] page for more information on roles and how to join this group.

- 

- == Testing and Quality Assurance ==

- 

- EPEL strives to ship packages that are as stable and bug free as possible. Testing of packages is always welcome. EPEL uses the Bodhi updates system to manage updates. Packages enter the epel-testing repository where they MUST spend 2 weeks or until sufficient testing is done on them. See our xref:epel-qa.adoc[EPEL QA] page for information on helping with testing and quality assurance.

- 

- == Release Engineering ==

- 

- EPEL Release engineering is responsible for making sure packages are built and signed and mirrored out. Currently this group is a subset of the Fedora Release Engineering group. See the link:++https://docs.pagure.org/releng/contributing.html++[Fedora Release Engineering page] for more information.

@@ -1,60 +0,0 @@ 

- include::partial$attributes.adoc[]

- :experimental:

- 

- = EPEL package maintainer generic job description

- 

- This job description is designed to be inserted into an existing job

- description supplied by your employer or sponsoring organization. The

- purpose of this description is to help separate the individual from the

- role. In this way, you can ensure the longevity of package support

- without requiring that you (and only you) are capable of maintaining the

- package.

- 

- You might find this useful in cases where, for example, your employer is

- using an EPEL package in their infrastructure. In such a case, it is

- your duty to your employer and to Fedora to make sure that your package

- lives on in case you do not.

- 

- [[generic_job_description]]

- == Generic job description

- 

- *EPEL Package Maintainer*

- 

- This role includes maintaining one or more packages through the Fedora

- Project. These packages are rebuilt in the Fedora Extra Packages for

- Enterprise Linux (EPEL) repository (link:++https://docs.fedoraproject.org/en-US/epel/++[]).

- The list of packages is not specified here, because it may need to

- fluctuate over time, but a list should be maintained with the group

- manager/project lead.

- 

- This organization is under no obligation to maintain these packages

- beyond the organization's desire to do so. All responsibilities

- undertaken are completely voluntary. If the organization desires to no

- longer support maintaining one or more packages in the future, its only

- responsibility is to follow the normal procedure to orphan a package.

- 

- In this role you are responsible for interacting with the packaging

- community in Fedora, following all guidelines and procedures specified

- by Fedora for building and maintaining packages, and interacting with

- the upstream of your package. The upstream of a package is usually the

- open source project that is producing the software being packaged. In

- some cases, your own organization may be or control the upstream

- project. A very important role in this position is being the conduit for

- patches, fixes, and updates from upstream that resolve security

- problems, fix bugs, and introduce new features.

- 

- The EPEL project synchronizes packages with specific release of Red Hat

- Enterprise Linux. To maintain an EPEL package, you must help maintain

- the synchronization against at least the one specific version of Red Hat

- Enterprise Linux.

- 

- [[job_duties]]

- === Job duties

- 

- * Interact with upstream

- * Interact with Fedora and EPEL sub-group

- * Maintain package throughout the life of the associated Enterprise

- Linux

- * Provide security updates

- * Be active in the appropriate packaging communities

- * Follow all Fedora and EPEL guidelines, procedures, and rules

@@ -1,85 +0,0 @@ 

- include::partial$attributes.adoc[]

- :experimental:

- 

- = EPEL package maintainers

- 

- [[epel_package_maintainers]]

- 

- EPEL packages are maintained by members of the community. These

- maintainers respond to bug reports, update packages and add new packages

- to the collection as needed. EPEL packagers are members of the Fedora

- `packagers` group.

- 

- [[joining_the_epel_package_maintainers]]

- == Joining the EPEL package maintainers

- 

- There are several ways you can join the EPEL package maintainer group:

- 

- . If you are an existing Fedora package maintainer, you can

- maintain EPEL packages by becoming a maintainer or co-maintainer of an

- existing EPEL package, which you can apply for in pkgdb. You can also

- xref:epel-faq.adoc#how_do_i_request_a_epel_branch_for_an_existing_fedora_package[request

- EPEL branches] for your Fedora package and maintain them for EPEL with a

- Package SCM request.

- 

- . If you are not currently in the Fedora packager group, you

- could join that group by submitting one or more new packages for

- Fedora/EPEL, and following the normal Fedora sponsorship process. Then,

- simply

- xref:epel-faq.adoc#how_do_i_request_a_epel_branch_for_an_existing_fedora_package[request

- EPEL branches] for your new packages once they are approved.

- 

- . If you are not currently in the Fedora packager group and wish

- to help co-maintain one or more packages in EPEL, you can try and find

- an existing package and maintainer of that package who wishes to mentor

- you. You can then follow the

- xref:package-maintainers::How_to_Get_Sponsored_into_the_Packager_Group.adoc#become_a_co_maintainer["Become

- a co-maintainer" path to sponsorship].

- 

- . If you are an existing EPEL/Fedora maintainer and wish to

- maintain a package in EPEL that someone else maintains in Fedora, file a

- bug asking them if they would like to maintain it in EPEL, if no

- response in a week or if the Fedora maintainer has no interest in EPEL,

- follow the

- xref:epel-package-request.adoc#stalled_epel_requests[stalled EPEL Request procedure]

- and maintain it yourself.

- 

- [[epel_policies_and_guidelines]]

- == EPEL policies and guidelines

- 

- Where possible, EPEL tries to use and follow any applicable Fedora

- guidelines. There are of course some exceptions due to older packages

- and EPEL seeking stability over newer packages. You can find a list of

- all such guidelines at the xref:epel-packaging.adoc[EPEL Packaging Guidelines]

- page.

- 

- [[epel_updates_policy]]

- == EPEL updates policy

- 

- EPEL strives to provide updates that are compatible and stable to

- compliment the Enterprise Linux packages it's built on. You can find a

- detailed list of updates policies on the xref:epel-policy-updates.adoc[EPEL

- updates policy page] as well as xref:epel-policy-incompatible-upgrades.adoc[a

- page on incompatible updates when they absolutely can't be avoided].

- 

- [[rhel_entitlements_for_epel_package_maintainers]]

- == RHEL entitlements for EPEL package maintainers

- 

- Please see

- xref:epel-rhel-entitlements.adoc[this page]

- for information about getting a free RHEL subscription for EPEL package maintenance.

- 

- [[new_package_wish_list]]

- == New package wish list

- 

- The best way to get a new package into EPEL is to first get it added to

- Fedora. You can add such packages to the

- link:++https://fedoraproject.org/wiki/Package_maintainers_wishlist++[wish list for Fedora].

- 

- It is possible to have packages only in EPEL, for example if the

- functionality has already been merged in a more recent package in

- Fedora, but it should be exceptional. Such packages can be submitted for

- review as per the regular process. Be ready to discuss why your package

- only applies to EPEL.

- 

- If the package is in Fedora but not in EPEL, see above.

@@ -1,202 +0,0 @@ 

- include::partial$attributes.adoc[]

- :experimental:

- :page-aliases: request.adoc

- 

- = Requesting a new package in EPEL

- 

- When requesting a Fedora package for EPEL, the steps are a little different

- depending on your ability or willingness to help.

- 

- If you are already a Fedora contributor, for your own package use the

- xref:package-maintainers::Package_Maintenance_Guide.adoc[standard procedures] 

- for requesting a new branch using `+fedpkg request-branch+`.

- 

- [NOTE]

- ====

- Before requesting a package in EPEL, it must first be in Fedora.

- There are some rare exceptions where an EPEL-only package is necessary,

- but those are out of scope for this guide.

- ====

- 

- [[determine_the_component]]

- == Determine the component

- 

- EPEL package requests are tracked in bugzilla.

- The *source package* name is used as the bugzilla `Component` field.

- This may or may not be the same as the package name you are looking for.

- If you are not sure what the source package name is,

- search for your desired package in the

- link:++https://packages.fedoraproject.org/++[Fedora Packages web app].

- Once you locate the desired package in this app,

- the URL will have the following structure:

- 

- [,console]

- ----

- https://packages.fedoraproject.org/pkgs/<source_package>/<package>/

- ----

- 

- The title of the page will be "<package> Subpackage of <source_package>" if the names are different,

- or just "<package>" if the names are the same.

- Use the source package name for the component in the rest of this guide.

- 

- [[file_a_bug]]

- == File a bug

- 

- Before opening a new bug report,

- check the existing ones to see if the package has already been requested.

- Use the following URL (replacing `<component>` with your component) to view existing open bugs.

- 

- [,console]

- ----

- https://bugz.fedoraproject.org/<component>

- ----

- 

- If there are no open requests for the EPEL version you desire,

- then open a new bug at link:++https://bugzilla.redhat.com/enter_bug.cgi++[].

- 

- [IMPORTANT]

- Please file separate bugs for different EPEL major versions. For EPEL

- 8 and 9 you just need to file a bug for the major versions. For

- EPEL10, please note which

- link:++https://docs.fedoraproject.org/en-US/epel/branches++[EPEL minor versions]

- you are requesting in the bug description.

- 

- [NOTE]

- .Bugzilla fields for an EPEL request

- ====

- * Classification: `Fedora`

- * Product: `Fedora EPEL`

- * Component: `<component>` (if the component is not found, skip to the next note)

- * Version: `epel10` (or `epel9`, `epel8`, etc.)

- * Summary: Please branch and build <package> in epel10 (or epel9, epel8, etc.)

- ====

- 

- If this package has never been in EPEL before,

- the component will not exist in the `Fedora EPEL` Product.

- You can still request the package by using the `Fedora` Product.

- 

- [NOTE]

- .Bugzilla fields for an EPEL request (alternative)

- ====

- * Classification: `Fedora`

- * Product: `Fedora`

- * Component: `<component>`

- * Version: `rawhide`

- * Summary: Please branch and build <package> in epel10 (or epel9, epel8, etc.)

- ====

- 

- If the component isn't found in either the `Fedora EPEL` or `Fedora` Products,

- then it probably doesn't exist in Fedora and needs to be added there first.

- 

- At this point, things change depending on your ability or willingness to help.

- 

- [[end_users]]

- === Consumers/end users

- 

- Clear out `Description` and put in:

- 

- [,console]

- ----

- Please branch and build <package> in epel10.

- ----

- 

- If you desire the package in the current epel10 minor version please

- add that to the description as noted above.

- 

- If there is no response after a week, add the following comment in the bug:

- 

- [,console]

- ----

- Will you be able to branch and build <package> in epel10?

- ----

- 

- If there is no action on the bug after two more weeks, send an email to link:++https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org/++[epel-devel] asking if there are any packagers

- who would like to package and maintain your package in EPEL. Be sure to include the Bugzilla URL in your email.

- 

- [[fedora_packagers]]

- === Fedora/EPEL packagers

- 

- Clear out Description and put in:

- 

- [,console]

- ----

- Please branch and build <package> in epel10.

- 

- If you do not wish to maintain <package> in epel10,

- or do not think you will be able to do this in a timely manner,

- I would be happy to be a co-maintainer of the package (FAS <your FAS Id>);

- please add me through https://src.fedoraproject.org/rpms/<package>/adduser

- ----

- 

- If you desire the package in the current epel10 minor version please

- add that to the description as noted above.

- 

- If there is no response after a week, add the following comment in the bug:

- 

- [,console]

- ----

- Will you be able to branch and build <package> in epel10?

- I would be happy to be a co-maintainer if you do not wish

- to build it on epel10 (FAS: <your FAS Id>).

- ----

- 

- If there is no action on the bug after two more weeks, follow the xref:epel-package-request.adoc#stalled_epel_requests[stalled EPEL request steps], and open a ticket with link:++https://pagure.io/releng/issues/++[releng]:

- 

- * Ticket Title:

- +

- [,console]

- ----

- Stalled EPEL package: <package>

- ----

- 

- * Ticket Body:

- +

- [,console]

- ----

- <package> has a stalled EPEL branch request.

- 

- <bugzilla URL>

- 

- Since this has met the time requirements as outlined in the stalled EPEL request policy,

- please grant my FAS (@<FAS of requester>) commit access to the package.

- 

- cc: @<FAS of maintainer>

- ----

- 

- After you have been given commit permissions, you can then branch, build, and maintain the package in epel.

- 

- [[stalled_epel_requests]]

- == Stalled EPEL requests

- 

- There are times that an EPEL / Fedora package maintainer isn't

- responding to an EPEL package request. If a different packager would

- like to build and maintain that package in EPEL, these are the steps

- they take.

- 

- * Anybody opens a Bugzilla bug requesting a package be added to EPEL-X. A

- packager (the Bugzilla reporter or another person) expresses that they

- are willing to help maintain / co-maintain that package in EPEL-X.

- * A week goes by with no action.

- * They re-say that they are willing to maintain / co-maintain the

- package in EPEL and set a needinfo flag for the maintainer.

- ** This is in case the initial message was missed.

- * Two weeks go by with no response.

- * They file a link:++https://pagure.io/releng/issues/++[rel-eng ticket] requesting appropriate privileges

- to be able to branch and build that package in EPEL-X.

- This ticket must include a link to the bugzilla request

- and mention the maintainer's FAS account.

- ** This part of the policy will adjust as various features get

- implemented in pagure and dist-git.

- * The privileges are given and the packager is made the Bugzilla contact

- for EPEL.

- * They then request a branch, and build the package in EPEL-X following

- normal steps.

- 

- "Action" is considered something that progresses the bug.

- "Action" can be positive or negative. Such as a response of "The code

- has not been updated for 10 years and has security issues" and then they

- close the ticket.

- "No Action" could be no response at all, or it could be a response of

- "I do not want to do epel" and then they do nothing else.

- 

- A template for these steps can be found above.

@@ -1,122 +0,0 @@ 

- include::partial$attributes.adoc[]

- :experimental:

- 

- = EPEL Packagers SIG

- 

- [[epel_packagers_sig]]

- == About

- 

- [NOTE]

- .This SIG is deprecated

- ====

- The EPEL Steering Committee has decided to deprecate this SIG. New requests for

- co-maintainership should no longer request adding this SIG to packages.

- ====

- 

- EPEL Packagers SIG is a dist-git group.  Being a member of that

- group allows you to work with packages that have added the

- link:++https://src.fedoraproject.org/group/epel-packagers-sig++[epel-packagers-sig group]

- as a collaborator on their packages.  You will be able to

- branch, build and work on those EPEL packages.

- 

- You do not need to be a member of the EPEL Packagers SIG to build packages on EPEL.

- 

- link:++https://accounts.fedoraproject.org/group/epel-packagers-sig/++[EPEL Packagers SIG Sponsors] are SIG members that are also

- on the EPEL Steering Committee.

- 

- == Why

- 

- There is often a lag between a new Enterprise Linux release

- being available, and extra packages being available for it:

- 

- * That package has to be branched and built

- * The existing maintainers have to decide if they want to support the latest EPEL or not

- * Rinse and repeat for every dependency

- * Then have years of maintenance and updates for that package

- 

- Adding the epel-packagers-sig group as a collaborator for a package

- gives the regular package maintainer(s) more people to maintain it

- over the years.  It can also help get the package into the latest version

- of EPEL faster.

- 

- == Workflow

- 

- We aim to be somewhere in between the language-based SIGs (e.g. the

- link:++https://fedoraproject.org/wiki/SIGs/Python++[Python SIG]) and being "provenpackagers for EPEL":

- 

- * like the language-based SIG, it's opt in: if a package maintainer

- would like help maintaining their packages for EPEL, they can add

- epel-packagers-sig as co-maintainers

- * SIG members can request new EPEL branches for packages they co-maintain

- * SIG members can mark packages they co-maintain to be automatically

- branched for the next EPEL release

- 

- Existing maintainers can decide whether to give the SIG commit access

- (in which case SIG members can also commit to Rawhide and Fedora

- branches), or only collaborator access (with epel repos allowlisted).

- Collaborator access is now sufficient to both request branches and push

- updates.

- 

- Automatic branching is not implemented yet.

- 

- === Packages

- 

- Candidate packages for onboarding --

- link:++https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&f1=days_elapsed&list_id=11600601&o1=greaterthan&product=Fedora&product=Fedora%20EPEL&query_format=advanced&short_desc=epel&short_desc_type=allwordssubstr&v1=14++[NEW

- branch requests over two weeks old]. We should consider reviewing this

- periodically.

- 

- Branch requests and/or bug requests that need to be brought into the

- SIG's attention should block

- link:++https://bugzilla.redhat.com/show_bug.cgi?id=EPELPackagersSIG++[the

- EPELPackagersSIG tracker].

- 

- See xref:epel-package-request.adoc#stalled_epel_requests[the guidelines

- for stalled requests] for follow-ups if a branch request has been stale

- for at least a week.

- 

- == Joining the EPEL Packagers SIG

- 

- Getting added to `epel-packagers-sig` grants collective access to all

- packages this group has access to, so we do need to be more careful when

- adding new contributors to this group.

- 

- A candidate should be a skilled package maintainer who is experienced

- in a wide variety of package types and who are familiar with the

- xref:fesco::Package_maintainer_responsibilities.adoc#[Fedora packaging guidelines]

- and xref:epel-policy.adoc[EPEL package maintainer policies].  They should

- have been packaging with Fedora and/or EPEL for at least a year.

- 

- The procedure is similar to that

- for xref:fesco::Provenpackager_policy.adoc#_becoming_provenpackager[provenpackagers].

- 

- * File a ticket in the link:++https://pagure.io/epel/issues++[EPEL issue tracker] indicating why you wish to

- become a member.

- * A link:++https://accounts.fedoraproject.org/group/epel-packagers-sig/++[Packagers SIG Sponsor] will send an e-mail to the SIG members, so they

- are aware about the ticket.

- * Packagers SIG Sponsors vote in the EPEL ticket.

- * You must get at least 1 positive votes from SIG Sponsor with no negative

- votes, over a one week review period, to be approved.

- 

- If you haven’t been approved after one week, the EPEL Steering Committee will vote

- (normal EPEL voting mechanism applies).

- 

- === Get to work

- 

- * Look through link:++https://pagure.io/epel/issues++[the general EPEL issues] related to packaging and see where you can help.

- * Look through link:++https://bugzilla.redhat.com/show_bug.cgi?id=EPELPackagersSIG++[the EPEL Packagers SIG bug tracker], see if there are any you want to help with.

- * Look through link:++https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&f1=days_elapsed&list_id=11600601&o1=greaterthan&product=Fedora&product=Fedora%20EPEL&query_format=advanced&short_desc=epel&short_desc_type=allwordssubstr&v1=14++[old epel bugs]. Many of them are requesting packages. See if there are any you think should be added to the EPEL Packagers Sig tracker.

- * Look at link:++https://packager-dashboard.fedoraproject.org/dashboard?groups=epel-packagers-sig++[the EPEL Packagers SIG dashboard] to see if there is anything there you can do.

- * Look at link:++https://tdawson.fedorapeople.org/epel/willit/status-overall.html++[Will-It-Install] and see if there are any packages that will not install that you can help with.

- ** link:++https://tdawson.fedorapeople.org/epel/willit/epel9/status-wont-install.html++[EPEL 9 packages that will not install].

- ** link:++https://tdawson.fedorapeople.org/epel/willit/epel8/status-wont-install.html++[EPEL 8 packages that will not install].

- 

- See xref:epel-package-request.adoc#stalled_epel_requests[the guidelines

- for stalled requests] for follow-ups if a branch request has been stale

- for at least a week.

- 

- [[communicating_with_the_epel_packagers_sig]]

- == Communicating with the EPEL Packagers SIG

- 

- We use the same communication channels as EPEL; see

- xref:epel-communication.adoc[Communicating with EPEL] for details.

@@ -1,174 +0,0 @@ 

- include::partial$attributes.adoc[]

- :experimental:

- 

- = EPEL packaging examples

- 

- == Missing-but-built examples

- 

- These examples are for the  xref:epel-policy-missing-sub-packages.adoc#short_term[Missing RHEL sub-packages/missing built sub-packages/short term policy].

- 

- === Missing-but-built workflow

- 

- This is an example workflow.

- 

- . `fedpkg request-repo --exception <package>-epel`

- * For example: fedpkg request-repo --exception pycairo-epel

- . `fedpkg request-branch --repo <package>-epel epel<version>`

- * For example: `fedpkg request-branch --repo pycairo-epel epel9`

- +

- [NOTE]

- ====

- `request-repo` and `request-branch` can be done at the same time as long as `request-repo` is done first.

- ====

- . Wait until you get an email saying the request is done

- . `fedpkg clone <package>-epel ; cd <package>-epel`

- * For example: `fedpkg clone pycairo-epel ; cd pycairo-epel`

- . `fedpkg retire "For epel only, not Fedora"`

- . `fedpkg switch-branch epel<version>`

- * For example: `fedpkg switch-branch epel9`

- . Download the source rpm corresponding to the latest released RHEL build

- . `fedpkg import <full patch to source rpm>`

- * For example: `fedpkg import /tmp/pycairo-1.20.0-4.el9.src.rpm`

- . `fedpkg commit -m "import from CentOS Stream srpm"`

- . `git mv <package>.spec <package>-epel.spec`

- * For example: `git mv pycairo.spec pycairo-epel.spec`

- . `fedpkg commit -m "rename spec file"`

- . Edit the spec file so it builds, but only produces the missing binaries

- . Test build and test install your rpm, which ever way you like to do that

- . `fedpkg commit -m "Convert RHEL<version> <package> to <package>-epel with just <package>-devel subpackage"`

- * For example: `fedpkg commit -m "Convert RHEL9 pycairo to pycairo-epel with just python3-cairo-devel subpackage"`

- . `fedpkg push`

- . `fedpkg build`

- . `fedpkg update`

- 

- === Missing-but-built spec examples

- 

- These examples should help you convert your RHEL spec file to a `-epel` spec file.

- 

- ==== Header/top of spec

- 

- * State where the original spec came from, and where to look to make sure it is 

- in sync.

- * A variable for the original name of the package. It doesn't have to be 

- `rhel_name`, but keep it consistent.

- ** Do a global replacement of `%\{name} to %\{rhel_name}` in your spec file.

- * Turn off debugsource.

- 

- ....

- # This spec file is derived from the RHEL9 pycairo spec file.  They should be kept

- # in sync over time.

- # https://gitlab.com/redhat/centos-stream/rpms/pycairo

- %global rhel_name pycairo

- %global _debugsource_template %{nil}

- ....

- 

- 

- ==== %prep

- 

- Add `-n %\{rhel_name}-%\{version}` to your setup. 

- So the build doesn't think the source is in `<package>-epel-version`.

- 

- ....

- %prep

- %autosetup -p1 -n %{rhel_name}-%{version}

- ....

- 

- 

- ==== %package %description and %files

- 

- You need to add `-n %\{rhel_name}-` to each of these.

- 

- ....

- %package -n %{rhel_name}-devel

- %description -n %{rhel_name}-devel

- %files -n %{rhel_name}-devel

- ....

- 

- ==== Fix Requires:

- 

- Most `-devel` packages have a `Requires:` equal to the Name-Version-Release (NVR)

- ....

- %package -n %{rhel_name}-devel

- Requires: %{rhel_name}%{?_isa} = %{version}-%{release}

- ....

- 

- If this were a perfect world, you could leave your `-epel` package like that.  

- But it's not a perfect world, and there are many times you need to update your 

- `-epel` package separate from the RHEL package being updated.

- 

- The following are two options. It is up to the `-epel` package maintainer to 

- decide which is right for them, or perhaps do things your own way.

- 

- ===== Remove release

- 

- If your -epel package only has some unchanging headers, you usually do not need 

- to keep completely in step with the RHEL release, only the version. If that is 

- the case, simply remove the `-%\{release}` section.

- ....

- %package -n %{rhel_name}-devel

- Requires: %{rhel_name}%{?_isa} = %{version}

- ....

- 

- ===== Rename release

- 

- If your `-epel` package has to be updated each time the RHEL package is updated, 

- no matter what, one way to do this is with a `%\{rhel_release}` that goes along 

- with your `%\{rhel_name}`. If you do this, your `-epel` release must be less than 

- the RHEL release.

- ....

- ...

- %global rhel_name pycairo

- %global rhel_release 4

- %global epel_release 1

- ...

- Name: %{rhel_name}-epel

- Release: 0.%{rhel_release}%{?dist}.%{epel_release}

- ...

- %package -n %{rhel_name}-devel

- Requires: %{rhel_name}%{?_isa} = %{version}-%{rhel_release}

- ...

- ....

- 

- ==== ExcludeArch: (if needed)

- 

- Some sub-packages are only missing in some arches. If that is the case, then you should

- use `ExcludeArch:` to have your package only built on those arches you care about.

- 

- ....

- # This is only for non-x86/POWER architectures

- ExcludeArch: %{ix86} x86_64 %{power64}

- ....

- 

- ==== Remove files shipped in RHEL

- 

- At the end of the `%install` section, remove all the files you will not be shipping.

- 

- ....

- %install

- %py3_install

- 

- # remove files shipped in RHEL

- rm -rf %{buildroot}%{python3_sitearch}

- ....

- 

- ==== Remove un-needed sections

- 

- * *Need to remove*

- ** `%files`

- *** Remove all the `%files` sections you will not be shipping.

- *** Make sure any file listed in those sections is removed in the `%install` section.

- 

- * *Optional remove*

- ** `%package` and `%description`

- ** `%prep`, `%post`, and other scripts

- ** `%check`

- *** This really depends on what you are doing.  If `%check` takes an hour, and all you need is a few headers, feel free to remove it. 

- If the missing package has an actual program in it, leave it in.

- *** When in doubt, leave `%check` in.

- 

- 

- == Missing un-built examples

- 

- These examples are for the  xref:epel-policy-missing-sub-packages.adoc#missing_un-built_sub-packages[Missing RHEL sub-packages/missing un-built sub-packages policy].

- 

- //TODO:Put Examples and Tips Here

@@ -1,127 +0,0 @@ 

- include::partial$attributes.adoc[]

- :experimental:

- 

- = EPEL packaging

- 

- This page contains guidelines which are not relevant

- or are no longer relevant to Fedora,

- but still apply to EPEL packages.

- These guidelines are designed to avoid conflict with the larger

- xref:packaging-guidelines::index.adoc[Fedora Packaging Guidelines],

- but should any conflicts occur,

- these guidelines should take precedence on EPEL packages.

- 

- As a reminder, these guidelines only apply to EPEL packages, not to

- Fedora packages.

- 

- [[package_dependencies]]

- == Package dependencies

- 

- All EPEL package dependencies (build-time or runtime)

- MUST ALWAYS be satisfiable within the Target Base

- (as defined by xref:epel-policy.adoc#_policy[EPEL policy])

- or EPEL itself.

- xref:packaging-guidelines::WeakDependencies.adoc[Weak package dependencies]

- are allowed on packages from other RHEL channels

- that are not part of the Target Base,

- such as the HighAvailability or ResilientStorage channels.

- This allows for repoclosure with only the Target Base,

- but allows EPEL packages to pull in other packages via weak dependencies

- when additional channels are enabled.

- 

- This does not mean that EPEL packages should incorrectly identify

- a dependency as weak (e.g. changing a Requires to a Recommends).

- On a case by case basis, exceptions to this policy may be granted

- by the EPEL Steering Committee.

- To request an exception link:++https://pagure.io/epel/issues++[open an issue]

- and add the "meeting" tag.

- 

- [[eln]]

- == ELN

- 

- link:++https://docs.fedoraproject.org/en-US/eln/++[ELN] is a new buildroot and compose

- process for Fedora that takes Fedora Rawhide dist-git sources and emulate a Red

- Hat Enterprise Linux compose. The packages included are thus based on what is

- planned to be included in the next major RHEL release, and in that way it is

- already useful for EPEL packagers.

- 

- link:++https://docs.fedoraproject.org/en-US/eln/extras/++[ELN Extras], however, is an

- extension that is mostly driven by EPEL packagers. Given that one of the pain

- points in bootstrapping a new EPEL is in processing the dependency graph of the

- packages our packagers are _actually_ interested in (whether they are a library

- that some in-house or ISV software needs, or a tool) and getting them branched

- and built, we can use ELN Extras in this way:

- 

- * add packages to ELN Extras' content resolver input, e.g.

-   link:++https://github.com/minimization/content-resolver-input/blob/master/configs/eln_extras_kde.yaml++[KDE

-   packages]; note that this has sufficient metadata to indicate who will

-   maintain such packages

- * check the

-   link:++https://tiny.distro.builders/workload-dependencies--eln_extras_kde--fedora-empty-base--repository-fedora-eln--x86_64.html++[dependencies]

-   pulled in

- 

- The former list is what packagers actually care about, the latter is just what

- needs to be brought in.

- 

- [[epel_8]]

- == EPEL 8

- 

- === Scriptlets

- 

- Fedora has been moving towards the use of file triggers and away from

- requiring that packagers cut and paste scriptlets into loads of

- packages. At the time of this writing, we are trying to backport all of

- these to EPEL8, so that fedora packages are easily able to build on

- EPEL8 without any changes. When EPEL 8 becomes old enough, that these

- backports are not feasible and/or wanted, we will list them here.

- 

- == RPM macros

- 

- Not all macros defined in (or built into) existing Fedora packages

- will work when a spec is converted for use in EPEL. link:++https://src.fedoraproject.org/rpms/epel-rpm-macros/++[epel-rpm-macros]

- backports the newer macros and is installed by default in EPEL

- mock chroots.

- 

- == Scriptlets

- 

- Fedora has been moving towards the use of file triggers and away from

- requiring that packagers cut and paste scriptlets into loads of

- packages. These scriptlets would still be needed for EPEL, and as

- scriptlets are no longer needed in any Fedora release, they're moved

- here.

- 

- == Python

- 

- The

- xref:packaging-guidelines::Python.adoc[Fedora Python Packaging Guidelines]

- underwent a major overhaul in 2021.

- The macros used in these guidelines are also available in RHEL 9.

- EPEL 9 Python packages *SHOULD* use these guidelines.

- EPEL 9 Python packages *MAY* use the older

- xref:packaging-guidelines::Python_201x.adoc[201x-era Fedora Python Packaging Guidelines].

- EPEL 8 Python packages *MUST* use the older guidelines.

- New Python 2 packages *SHOULD NOT* be added to EPEL 8,

- because the RHEL 8 Python 2.7 Application Stream was

- link:++https://access.redhat.com/support/policy/updates/rhel-app-streams-life-cycle++[retired in June 2024].

- 

- === Automatically generated dependencies

- 

- The Python run-time dependency generator mentioned in the

- xref:packaging-guidelines::Python.adoc[Fedora Python Packaging Guidelines]

- is enabled by default for EPEL 8 and EPEL 9 builds.

- 

- The dependency generator in RHEL 8 is significantly limited compared to the one in Fedora and RHEL 9.

- Simple dependencies and minimum/maximum versions work correctly,

- but more advanced specifications such as

- link:++https://peps.python.org/pep-0508/#environment-markers++[environment markers]

- and

- link:++https://peps.python.org/pep-0440/#compatible-release++[compatible release clauses]

- do not.

- This can lead to missing dependencies,

- included dependencies that should have been skipped,

- or other incorrect behavior.

- The packager *MUST* inspect the generated requires for correctness.

- If the software uses an advanced dependency specification that does not parse correctly,

- the packager *MUST* ensure the dependency is included.

- This can be done either by patching the source to achieve the desired result from the generator,

- or by using an explicit `+Requires:+` statements.

@@ -1,61 +0,0 @@ 

- include::partial$attributes.adoc[]

- :experimental:

- 

- = Incompatible upgrades policy

- 

- [[incompatible_upgrades_policy]]

- 

- == Background

- 

- Incompatible version upgrades in EPEL are to be avoided. However, in

- certain situations, they are unavoidable. An example of such a situation

- would be a security update that is difficult/impossible to backport.

- This policy aims to both discourage incompatible upgrades for trivial

- reasons, while allowing them for security updates where the version of

- the software in question is no longer maintained upstream and the

- maintainer is unable to backport just the security fix.

- 

- [[process_for_incompatible_upgrades]]

- == Process for incompatible upgrades

- 

- . Send e-mail to

- link:++lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/++[epel-devel]

- with details of the proposed upgrade. Include items such as the CVE of

- the security issue to be fixed, and/or an upstream bug tracker reference

- (if applicable). Also reference a bug in

- xref:epel-communication.adoc[Bugzilla] against the

- package.

- . In the case of a critical CVE the maintainer *MAY* build the package

- and submit it to bodhi for testing.  'Auto-request stable?' *MUST NOT* be checked.

- . File an link:++https://pagure.io/epel/issues++[EPEL issue]. This can be done while

- discussion is ongoing; please link to the thread in the mailing list archive so the EPEL

- Steering Committee can monitor the discussion and know when it is ready to be discussed.

- . After a week of mailing list discussion, an EPEL Steering Committee member will add the

- meeting tag and the issue will be discussed at the next weekly meeting.

- . If a majority of Steering Committee members present at the EPEL meeting concur, the

- incompatible upgrade can be built, if it has not been already.

- . At the same time that the update is submitted to bodhi for testing,

- the maintainer is responsible for sending e-mail to epel-announce

- announcing the incompatible upgrade and specific actions that users must

- take in order to continue using the software.

- . Package MUST remain in testing for at least 1 week, regardless of

- received karma. In bodhi, 'Auto-request stable?' *MUST NOT* be checked.

- . When pushing the package to stable, the maintainer *MUST* send another

- e-mail to epel-announce.

- 

- [[procedure_for_other_packages]]

- == Procedure for other packages

- 

- For other - non-security - incompatible updates, the maintainer *MUST

- NOT* push those types of changes. Consider shipping an alternatively

- named new package (e.g. foo2) to provide the newer version.

- 

- [[discussion_points]]

- == Discussion points

- 

- . Approval process - majority of those present seems to be lax, but

- being there's no body such as FESCo in "charge" of EPEL (yes, I realize

- that FESCo has oversight, but oversight != make day-to-day decisions

- such as these), I'm not sure what else to put there.

- . How to enforce the mail to epel-announce? Maybe have the chair of the

- EPEL meeting send it?

@@ -1,89 +0,0 @@ 

- include::partial$attributes.adoc[]

- :experimental:

- 

- = Missing RHEL sub-packages

- 

- When a RHEL source package is built, it often creates more than one binary package.  These

- extra packages are generally called sub-packages.

- 

- Sometimes RHEL sub-packages that are built are not published.  Sometimes packages are built

- for all arches, but only published on one or two arches.

- We call these two types "missing built sub-packages".

- 

- Sometimes when a RHEL source package is built, it does not create all the sub-packages 

- that it potentially could.  We call these types "missing un-built sub-packages".

- 

- EPEL cannot have a package with the same name as a source or binary package published in RHEL.

- To solve the problem of missing built and un-built sub-packages, the following policy and 

- procedures have been setup.

- 

- [[shared_guidelines]]

- == Shared guidelines

- 

- * You MUST name your source package `<package>-epel`

- * You MUST NOT conflict with any RHEL packages or files

- 

- [[missing_built_sub-packages]]

- == Missing built sub-packages

- 

- [[short_term]]

- === Short term

- 

- Create an EPEL package that only has the missing packages, or missing arches.

- 

- * Be prepared to maintain this package as long as it is needed.

- ** It is recommended that you add the epel-packagers-sig group as a co-maintainer.

- * A package review is not required, but it is a good idea to have someone look at the updated spec file.

- * If you need help building this, ask for help. We have xref:epel-packaging-examples.adoc#_missing_but_built_examples[some examples].

- * It qualifies for an exception to the package review process so you can request the repo with.

- ** `fedpkg request-repo --exception <package>-epel`

- * Once the repo is created, you must retire the rawhide branch to make it clear that this is an EPEL-only package and shouldn't be branched for future Fedora releases.

- ** `fedpkg retire 'EPEL-only package'`

- * When/If the missing package(s) are added to RHEL CRB, retire your -epel package following the xref:epel-policy-retirement.adoc#process_package_in_rhel[EPEL retirement policy].

- 

- xref:epel-packaging-examples.adoc#_missing_but_built_examples[Short term examples and workflow]

- 

- [[long_term]]

- === Long term

- 

- Request the package be added to the appropriate RHEL CRB repository.

- 

- * To initiate this process,

- please file an issue in link:++https://issues.redhat.com++ and request it be added to RHEL.

- Report the bug against the RHEL project,

- assign it to the proper CentOS Stream versions,

- and add the source package name in the Component field.

- More details on this can be found in the

- link:++https://docs.centos.org/en-US/stream-contrib/quickstart/#_1_file_an_issue++[CentOS contributor guide].

- * Be sure to say that it is impacting an EPEL build, and which package it is impacting.

- 

- [,console]

- ----

- Please add <sub-package> to CRB in RHEL9

- 

- I am building <my package> in EPEL9.

- <my package> requires <sub-package> to build in EPEL9.

- 

- (Optional)

- <my package> is important because these other packages depend on it:

- <other packages>

- 

- (Optional)

- <my package> is important because <my company> uses it for <reason>

- ----

- 

- In the past, the default answer for a request like this was "no".

- But in mid-2021 the RHEL policy changed to allow the RHEL package 

- maintainer to make the decision.  There are still packages where 

- the answer might be "no", but many maintainers are choosing to add 

- the sub-packages to the RHEL CRB repo.

- 

- [[missing_un-built_sub-packages]]

- == Missing un-built sub-packages

- 

- You can create packages that supply missing sub-packages that were not built in RHEL but are built in Fedora.

- 

- In the past these were named <package>-extra, but these are now named `<package>-epel` to avoid confusion.

- 

- 

- xref:epel-packaging-examples.adoc#_missing_un_built_examples[Missing but un-built examples]

@@ -1,93 +0,0 @@ 

- include::partial$attributes.adoc[]

- :experimental:

- 

- = Retirement policy

- 

- [[retirement_policy]]

- 

- == Background

- 

- There are three reasons for retiring a package in EPEL.

- 

- * The package is now included in RHEL.

- * Security reasons.

- * Maintainer no longer has time and/or desire.

- 

- [[process_package_in_rhel]]

- == Process: Package in RHEL

- 

- If a package is in RHEL, you should have received a bug telling you your package

- is going to be in RHEL.  It should also say which RHEL release it will be in (e.g. RHEL 8.8).

- 

- *Do not remove your EPEL package until you have verified that it is in RHEL.*

- 

- * If the package version in RHEL is older than the version in EPEL, send an e-mail to link:++https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/++[epel-devel], documenting the potential loss of functionality. If the package version in RHEL is the same or newer, sending the e-mail is optional

- * Once your package is in RHEL, you should link:++https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#_procedure++[retire the package from EPEL].

- ** fedpkg switch-branch epel8 (or whichever epel branch is correct)

- ** fedpkg retire "REASON FOR RETIREMENT"

- 

- [[process_security_reasons]]

- == Process: Security reasons

- 

- If a package has a severe security issue, and the fix cannot be backported, usually

- this can be fixed xref:epel-policy-incompatible-upgrades.adoc#process_for_incompatible_upgrades[with

- an incompatible upgrade].  If the EPEL version is fairly old, and a newer version

- cannot be built, it's possible that the only choice of action is to remove the package.

- 

- . Send e-mail to

- link:++https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/++[epel-devel]

- with details of the proposed retirement. Include items such as the CVE of

- the security issues affecting the existing version, and/or an upstream

- bug tracker reference (if applicable). Also reference a bug in

- xref:epel-communication.adoc[Bugzilla] against the package.

- . Discussion takes place on epel-devel for a minimum period of 1 week, unless this

- is for a critical security update such as remote root.

- . The maintainer is then responsible for sending an e-mail to epel-announce.  It should

- announce the retirement and specific actions that users must

- take in order to continue using the software

- (e.g. install using `pip` or some other delivery mechanism).

- . link:++https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#_procedure++[Retire the package from EPEL].

- ** `fedpkg switch-branch epel8` (or whichever epel branch is correct)

- ** `fedpkg retire "REASON FOR RETIREMENT"`

- 

- [[process_no_time_or_desire]]

- == Process: No time or desire

- 

- EPEL is run and maintained by many volunteers.  A person's life, job,

- and priorities change over time.  It is natural that a time might come that you no

- longer have the time or desire to maintain a package.

- 

- . Check if there are other maintainers of the package. link:++https://src.fedoraproject.org/rpms/nedit++[https://src.fedoraproject.org/rpms/<package>]

- If there are, ask them if they would like to maintain the epel branches.

- . If none of the other maintainers want to maintain the epel branches, send an e-mail to

- link:++https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/++[epel-devel]. Let us

- know you cannot maintain the package anymore, and none of the other maintainers can either.  If there

- is anything special about the package, or urgent issues such as the package not being installable, let us know that as well.

- . After two weeks, If nobody has volunteered to take over the package for you, send an e-mail to epel-announce.  It should

- announce the retirement and specific actions that users must take in order to continue using the software

- (e.g. install using `pip` or some other delivery mechanism).

- . link:++https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#_procedure++[Retire the package from EPEL].

- ** `fedpkg switch-branch epel8` (or whichever epel branch is correct)

- ** `fedpkg retire "REASON FOR RETIREMENT"`

- 

- [[process_not_installable]]

- == Process: Not installable

- 

- There are times that packages are not installable in EPEL.  These packages fall into two categories.

- Packages that once were installable, but no longer are.  Packages that were never installable.

- 

- [[process_once_installable]]

- === Process: Once installable

- 

- If a package was once installable, but no longer is, try to fix the problem.  If you cannot, or you do not have the

- time or desire to fix it, follow the link:++https://docs.fedoraproject.org/en-US/epel/epel-policy-retirement/#process_no_time_or_desire++[No Time or Desire policy]

- 

- [[process_never_installable]]

- === Process: Never installable

- 

- If a package was never installable in an EPEL repo, try to fix the problem.  If you cannot fix the problem and wish

- to retire the package from that EPEL branch / repo, you can.

- 

- . link:++https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#_procedure++[Retire the package from EPEL].

- ** `fedpkg switch-branch epel8` (or whichever epel branch is correct)

- ** `fedpkg retire "REASON FOR RETIREMENT"`

@@ -1,21 +0,0 @@ 

- include::partial$attributes.adoc[]

- :experimental:

- 

- = Regarding EPEL and Software Collections

- 

- == Background

- 

- RHEL comes with the `+scl-utils+` and `+scl-utils-build+`

- packages -- which contain tools for using and building SCLs. These

- packages appear to function as expected with RHEL and CentOS Stream.

- 

- == Recommendations

- 

- EPEL will not provide SCL support, although it will not prohibit use of

- the SCL tools provided with RHEL.

- 

- EPEL will not provide any SCLs.

- 

- For use cases that require the parallel installation of multiple

- versions of the same component, EPEL recommends the same solution as

- Fedora in the link:++https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/#multiple++[Fedora Packaging Guidelines].

@@ -1,125 +0,0 @@ 

- include::partial$attributes.adoc[]

- :experimental:

- 

- = EPEL Steering Committee

- 

- [[Background]]

- 

- == Background

- 

- The EPEL Steering Committee was formed in 2007 by FESCo as a governing body for EPEL.

- The original committee consisted of 7 members who invested the most time and work for the original EPEL idea.

- In late 2014 the committee was revived with just 5 members, who were doing the most work at the time.

- In 2021 the committee was expanded back to 7.  The new positions going to those members who were most active in the committee meetings.

- In 2023 the committee decided that members would be elected.  The first election of committee members is planned for the spring of 2024.

- 

- [[committee_members]]

- == Committee Members

- 

- [[current_committee_members]]

- === Current Committee Members

- 

- * Kevin Fenzi (nirik) - Start: February 2007

- * Troy Dawson (tdawson) - Start: October 2020

- * Carl George (carlwgeorge) - Start: October 2020

- * Davide Cavalca (dcavalca) - Start: June 2021

- * Neal Gompa (ngompa) - Start: June 2021

- * Jonathan Wright (jonathanspw) - Start: June 2024

- * Robby Callicotte (rcallicotte) - Start: June 2025

- 

- [[past_committee_members]]

- === Past Committee Members

- 

- * Michel Lind (salimma) - Start: June 2021 End: June 2025

- * Pablo Greco (pgreco) - Start: February 2019 End: June 2024

- * Brian Stinson (bstinson) - Start: December 2014 End: June 2021

- * Jim Perrin (jperrin) - Start: December 2014 End: October 2020

- * Stephen J Smoogen (smooge) - Start: February 2008 End: October 2020

- * Anssi Johansson (avij) - Start: April 2015  End: February 2019

- * Dennis Gilmore (ausil) - Start: February 2007 End: February 2019

- * Mike McGrath (mmcgrath) - Start: February 2007 End: December 2014

- * Michael Stahnke (stahnma) - Start: February 2007 End: December 2014

- * Xavier Lamien (SmootherFrOgZ) - Start: February 2007 End: December 2014

- * Andy Gospodarek (Gospo) - Start: February 2007 End: December 2014

- * Jeff Sheltren (Jeff_S) - Start: February 2007 End: December 2014

- * Karsten Wade (quaid) - Start: February 2007 End: December 2014

- * Thorsten Leemhuis - Start: February 2007 End: February 2008

- 

- [[committee_member_selection]]

- === Committee member selection

- 

- From EPEL's beginning (2007) until 2024, committee members were based on the most active members when new seats needed to be filled.

- Starting in 2024, Steering Committee members will be elected for two year terms.

- EPEL Streeing Committee elections will be part of the link:++docs.fedoraproject.org/en-US/program_management/elections/++[Fedora elections process].

- EPEL committee elections will occur during the first Fedora election cycle of a calendar year.

- 

- [[committee_members]]

- == Committee chair

- 

- [[committee_chair_history]]

- === Current committee members

- 

- * Troy Dawson (tdawson ) Start: October 2020

- * Stephen J Smoogen ( smooge ) Start:  February 2008  End: October 2020

- * Thorsten Leemhuis - Start: February 2007 End: February 2008

- 

- [[committee_chair_selection]]

- === Committee chair selection

- From EPEL's beginning (2007) until 2024 the committee chair was a committee volunteer who stayed as chair until they stepped down.

- Starting in 2024, the committee chair will be elected each year, by the committee, after the committee elections.

- 

- [[committee_meeting]]

- == Committee meeting

- 

- The place and time for the EPEL Steering Committee meeting can be found in the

- xref:epel-communication.adoc[Communicating with EPEL] section of our documentation

- 

- The meeting is public and everyone is invited.

- 

- [[committee_meeting_voting]]

- === Committee meeting voting

- 

- The EPEL Steering Committee tracks ongoing decisions using the

- link:++https://pagure.io/epel/issues++[EPEL ticketing system].

- Decisions are voted on at the weekly Steering Committee meeting.

- These decisions usually fall into one of these categories:

- 

- * tickets asking for a change in EPEL policy

- * tickets asking for an exception to EPEL policy

- * tickets requesting approval for an

-   link:++https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/++[incompatible upgrade]

- 

- Eligible voters are all currently-serving members of the Steering Committee.

- If a member is unable to attend a meeting,

- they may relay their vote through another member.

- 

- An official vote must be one of `++1+`, `+0+`, `+-1+`:

- 

- * `++1+` - I am in favor of the proposal as currently written.

- * `+0+` - I am removing myself from the list of voters required for majority for this proposal.

- * `+-1+` - I am opposed to the proposal as currently written.

- 

- A vote of `+0+` reduces the denominator of the fraction required to achieve the 51% majority.

- In effect, it says

- "I am agreeing to vote with the remaining majority, whatever they decide."

- 

- If a vote achieves a 51% majority of eligible voters,

- regardless of their attendance at the meeting and accounting for any explicit `+0+` votes,

- in favor of a proposal,

- that proposal is accepted.

- 

- If a vote fails to achieve a 51% majority of eligible voters,

- regardless of their attendance at the meeting and accounting for any explicit `+0+` votes,

- that proposal is rejected.

- 

- After the meeting where the proposal is voted on,

- a member of the Steering Committee will update the ticket with the results of the vote.

- If the proposal was approved,

- it may proceed with implementation.

- 

- If a matter is urgent,

- the proposer can request a vote within the ticket before the next meeting.

- Steering Committee members will record their votes as comments in the ticket.

- 

- Decisions made by the EPEL Steering Committee may be re-discussed in FESCo meetings, if necessary.

- FESCo retains authority over EPEL Steering Committee decisions and can exercise a veto on a voted-upon topic.

@@ -1,43 +0,0 @@ 

- include::partial$attributes.adoc[]

- :experimental:

- 

- = EPEL updates policy

- 

- [[epel_updates_policy]]

- 

- This document describes the policy for updates to packages in the EPEL

- package collection. For general EPEL package guidelines, refer to the

- xref:epel-policy.adoc[EPEL guidelines and policy] page.

- 

- [[stable_releases]]

- == Stable releases

- 

- * All updates MUST spend at least 1 week in the testing repository, or

- +3 karma from testers.

- 

- * All updates should strive to avoid situations that require manual

- intervention to keep the package functioning after update.

- 

- * Major updates with changes to user experience are to be avoided. If

- they cannot be avoided, the xref:epel-policy-incompatible-upgrades.adoc[EPEL

- incompatible upgrades policy] MUST be followed. This includes two

- separate announcements to the epel-announce mailing list.

- 

- * When new packages enter the Enterprise Linux distribution that is

- already available in EPEL, that package will be marked dead.package and

- blocked in pkgdb and koji.

- 

- == Exceptions

- 

- In some rare cases, exceptions will need to be made. Bring your case

- before the EPEL Steering Committee at one of the weekly meetings and/or the mailing

- list. Possibly grounds for exception might include:

- 

- * Serious security issue that cannot be backported to the existing

- version, so a new major version is required.

- 

- * Serious bugs that cannot be fixed in the existing version.

- 

- In cases of major disruption, EPEL updates will looked to be done along

- with Red Hat Enterprise Linux minor releases (8.1, 8.2, 8.3) so as to

- allow for longer testing or differing beta testing.

@@ -1,342 +0,0 @@ 

- include::partial$attributes.adoc[]

- :experimental:

- 

- = Packaging guidelines and policies for EPEL

- 

- [[packaging_guidelines_and_policies_for_epel]]

- 

- The packages in EPEL follow the Fedora Packaging and Maintenance

- Guidelines -- that includes, but is not limited to the

- xref:packaging-guidelines::index.adoc[packaging guidelines], the

- xref:packaging-guidelines::index.adoc#_naming[package naming guidelines], and the

- xref:packaging-guidelines::ReviewGuidelines.adoc[package review guidelines] that are designed

- and maintained by the xref:fesco::index.adoc[FESCo], and

- link:++https://fedoraproject.org/wiki/Packaging_Committee++[Packaging Committee]. EPEL-specific exceptions

- are documented here and in the xref:epel-packaging.adoc[EPEL packaging] page.

- 

- Please note that the sections "Guidelines" and "Policies" use their

- names on purpose. Consider the guidelines as something that should be

- followed normally, but doesn't have to if there are good reasons not to

- -- please ask EPEL members in case you are in doubt if your

- reasons are good. The word _policies_ has a stronger meaning, and what

- is written in that section should be considered rules that must always

- be followed.

- 

- [[package_maintenance_and_update_policy]]

- == Package maintenance and update policy

- 

- EPEL wants to provide a common "look and feel" to the users of our

- repository. Thus the EPEL Steering Committee wrote this policy that describes the

- regulations for package maintenance and updates in EPEL, that are a bit

- more strictly regulated then they are in Fedora now.

- 

- === Digest

- 

- The goal is to have packages in EPEL that enhances the Enterprise Linux

- distributions the packages were build against without disturbing or

- replacing packages from that distribution. The packages in the

- repository should, if possible, be maintained in similar ways to the

- Enterprise Packages they were built against. In other words: have a

- mostly stable set of packages that normally do not change at all and

- only changes if there are good reasons for it -- so no "hey, there is a

- new version, it builds, let's ship it" mentality.

- 

- === Policy

- 

- EPEL packages should only enhance and never disturb the Enterprise Linux

- distributions they were built for. Thus packages from EPEL should never

- replace packages from the target base distribution.  Kernel modules are not

- allowed, as they can disturb the base kernel easily.

- 

- In EPEL8 or later, it is permitted to provide an alternative non-modular 

- package to any package found only in a non-default RHEL module.

- 

- The Target Base for each distribution has been defined in older mailing

- list discussions as the version of Red Hat Enterprise Linux that the

- Koji builders have access to.

- 

- * EPEL 10's leading minor version is built against CentOS Stream 10 repos

- ** `baseos`

- ** `appstream`

- ** `crb`

- * EPEL 10's trailing minor versions are built against Red Hat Enterprise Linux 10 channels

- ** `rhel-10-for-*-baseos-rpms`

- ** `rhel-10-for-*-appstream-rpms`

- ** `codeready-builder-for-rhel-10-*-rpms`

- * EPEL 9 Next is built against CentOS Stream 9 repos

- ** `baseos`

- ** `appstream`

- ** `crb`

- * EPEL 9 is built against Red Hat Enterprise Linux 9 channels

- ** `rhel-9-for-*-baseos-rpms`

- ** `rhel-9-for-*-appstream-rpms`

- ** `codeready-builder-for-rhel-9-*-rpms`

- * EPEL 8 is built against Red Hat Enterprise Linux 8 channels

- ** `rhel-8-for-*-baseos-rpms`

- ** `rhel-8-for-*-appstream-rpms`

- ** `codeready-builder-for-rhel-8-*-rpms`

- 

- EPEL packages which are known to also exist in other RHEL channels

- should keep a lower `epoch:version-release` (EVR) than the RHEL package.

- This is because packages have been known to move from these other channels into the target base channels.

- Keeping a lower EVR helps ensure a smooth upgrade path.

- 

- The packages in the repository should, if possible, be maintained in

- similar ways to the Enterprise Packages they were built against. In

- other words: have a mostly stable set of packages that normally does not

- change at all and only changes if there are good reasons for changes.

- This is the spirit of a stable enterprise environment.

- 

- The changes that cant be avoided get routed into different release

- trees. Only updates that fix important bugs (say: data-corruption,

- security problems, really annoying bugs) go to a testing branch for a

- short time period and then are pushed to the stable branch; those people

- that sign and push the EPEL packages to the public repo will skim over

- the list of updated packages for the stable repo to make sure that sure

- the goal "only important updates for the stable branch" is fulfilled.

- 

- Other updates get queued up in a testing repository over time. That

- repository becomes the new stable branch after 2 weeks of testing. But

- even these updates should be limited to fixes only as far as possible

- and should be tested in Fedora beforehand if possible. Updated Packages

- that change the ABI or require config file adjustments must be avoided

- if at all possible. Compat- Packages that provide the old ABI need to be

- provided in the repo if there is no way around a package update that

- changes the ABI. Packages in the testing repo for 2 weeks are

- automatically promoted to stable. Packages with sufficient karma are

- also promoted to stable. Update candidates that aren't pushed to stable after 6 months are eligible to be removed by Release Engineering.

- 

- For more information about updating EPEL packages, including minimum

- testing time for packages, refer to the xref:epel-policy-updates.adoc[EPEL

- updates policy].

- 

- [[workflow_examples_information]]

- == Workflow examples/information

- 

- * Maintainer builds the package.

- * Maintainer submits an update for testing using bodhi.

- * If the update gets sufficient karma it is promoted to stable.

- * After 2 weeks, if the package does not have a negative karma, bodhi

- will promote the package to stable.

- * Pushes for both testing and stable take place daily.

- 

- [[guidelines_and_backgrounds_for_this_policy]]

- == Guidelines and backgrounds for this policy

- 

- [[some_examples_of_what_package_updates_that_are_fine_or_not]]

- === Some examples of what package updates that are fine or not

- 

- Examples hopefully help to outline how to actually apply above policy in

- practise.

- 

- [[minor_version_updates]]

- ==== Minor version updates

- 

- Let's assume package foo is shipped in EPEL 8 as version 1.0.1;

- upstream developers now ship 1.0.2

- 

- * build as normal, but wait at least two weeks and possibly more in

- testing.

- 

- [[a_little_bit_bigger_minor_version_updates]]

- ==== A little bit bigger minor version updates

- 

- Let's assume package foo is shipped in EPEL 8 as version 1.0.1;

- upstream developers now ship 1.2.0; the ABI is compatible to 1.0.1 and

- the existing config files continue to work

- 

- * build as normal, but leave in testing until there is sufficient karma

- to go to stable.

- 

- [[a_yet_again_little_bit_bigger_minor_version_updates]]

- ==== A yet again little bit bigger minor version updates

- 

- Let's assume package foo is shipped in EPEL 8 as version 1.0.1;

- upstream developers now ship 1.4.0; the ABI is compatible to 1.0.1, but

- the config files need manual adjustments

- 

- * build for the stable branch is normally not acceptable; a backport

- should be strongly considered if there are any serious bugs that must be

- fixed

- * build for the testing branch is also disliked; but it is acceptable if

- there is no other easy way out to solve serious bugs; but the update and

- the config file adjustments need to be announced to the users properly

- -- use the epel-announce list for this.

- * leave in testing if at all possible.

- 

- [[a_major_version_update]]

- ==== A major version update

- 

- Let's assume package foo is shipped in EPEL 8 as version 1.0.1;

- upstream developers now ship 2.0.0; the ABI changes or the config files

- need manual adjustments

- 

- * This update should be avoided if possible at all. If there really is

- no other way to fix a serious bug then follow the

- xref:epel-policy-incompatible-upgrades.adoc[incompatible upgrades policy]. In

- the case of a library package changing soname, consider shipping a

- compat package that provides the current soname at the same time you

- ship the new soname.

- 

- [[security_updates]]

- ==== Security updates

- 

- Security updates should be marked as such in bodhi and will be pushed to

- stable. Because of this you should always try and make as few changes as

- possible on these sorts of updates. Apply only the backported fix, or if

- you must, the new version that provides only the fix. Try and avoid

- pushing other changes with a security update.

- 

- [[add_more_examples_as_they_show_up]]

- == Add more examples as they show up

- 

- If too many show up, put them into a separate document.

- 

- [[still_unsure_if_a_package_is_fine_for_epel]]

- == Still unsure if a package is fine for EPEL?

- 

- Just ask on

- xref:epel-communication.adoc[epel-devel mailing list or #epel IRC channel]

- for opinions from EPEL members.

- 

- [[why_not_a_rolling_release_with_latest_packages_like_what_was_in_fedora_extras]]

- == Why not a rolling release with latest packages like what was in Fedora Extras?

- 

- Why should we? That would be what Fedora Extras did and worked and works

- well for it -- but that's mainly because Fedora (Core) has lots of

- updates and a nearly rolling-release scheme/quick release cycle, too.

- But the Enterprise Linux we build against is much more careful with

- updates and has longer life-cycle; thus we should do the same for EPEL,

- as most users will properly prefer it that way, as they chose a stable

- distro for some reasons -- if they want the latest packages they might

- have chosen Fedora.

- 

- Sure, there are lots of areas where having a mix of a stable base and a

- set of quite new packages on top of it is wanted. *Maybe* the EPEL

- project will provide a solution (in parallel to the carefully updated

- repository!) for those cases in the long term, but not for the start.

- There are already third party repositories out there that provide

- something in this direction, so users might be served by them already.

- 

- Further: A rolling release scheme like Fedora Extras did is not possible

- for many EPEL packages for another reason, new packages often require

- new versions of certain core libraries. This will cause problems in EPEL

- because we won't be able to provide updated libs as it would replace

- libraries in the core OS.

- 

- Example: This document was written round about when RHEL5 got released;

- many packages that get build for RHEL5 can't be build for RHEL4 at this

- point of time already, as the RHEL4-gtk2-Package is two years old and is

- too old for many current applications, as they depend on a newer gtk2.

- So if even if we would try to have a rolling scheme with quite new

- package we'd fail, as we can't build a bunch of package due to this

- dependencies on libs; in the end we would have a repo with some quite

- new packages while others are still quite old. That mix wouldn't make

- either of the "latest versions" or "careful updates only" sides happy;

- so we try to target the "careful updates only" sides. Remember, EPEL's

- support and updates cycle is much longer then Fedora's.

- 

- [[distribution_specific_guidelines]]

- == Distribution specific guidelines

- 

- The xref:packaging-guidelines::index.adoc[Fedora Packaging Guidelines] are written for

- current Fedora releases. Sometimes there are changes in Fedora that

- cause the packaging guidelines there to not make sense for the older

- software being run in RHEL. When that occurs, we document the

- differences with the Fedora Packaging Guidelines on the

- xref:epel-packaging.adoc[EPEL packaging] page.

- 

- [[policy_for_conflicting_packages]]

- == Policy for conflicting packages

- 

- xref:epel-faq.adoc#does_epel_replace_packages_provided_within_red_hat_enterprise_linux[Per

- RHEL release package conflict channel exclusions]

- 

- * EPEL packages must not conflict with packages in the target base of RHEL.

- See above link for a complete list of channels per RHEL Release that EPEL does not conflict with.

- This includes source package names due to the way that koji deals with packages from external repositories.

- * As an exception to the above rule,

- devel packages in EPEL that are alternate versions of devel packages in RHEL (i.e. compat packages)

- are allowed to conflict with each other.

- See the section about

- xref:epel-policy.adoc#conflicts_in_compat_packages[conflicts in compat packages]

- for more details.

- * EPEL packages can conflict with packages in other RHEL channels outside of the target base.

- * EPEL maintainers should be open to communication from RHEL maintainers

- and try and accommodate them by not shipping specific packages, or by

- adjusting the package in EPEL to better handle a conflicting package in

- a channel on a case by case basis.

- 

- When a package is added to RHEL for that is already in EPEL, it usually

- needs to be removed from EPEL. Please follow the

- xref:package-maintainers::Package_Retirement_Process.adoc[retirement process] to do

- this. If the package is only available for a subset of all

- architectures, it might still be possible to keep the package in EPEL as

- described in the xref:epel-packaging.adoc#limited_arch_packages[EPEL packaging

- guidelines].

- 

- [[conflicts_in_compat_packages]]

- == Conflicts in compat packages

- 

- Due to the EPEL policy of maintaining backwards compatibility,

- EPEL has a greater need for forward compat (i.e. newer alternate version) packages than Fedora.

- There may also be cases where backwards compat (i.e. older alternate version) packages are needed.

- When creating a compat package,

- note that it is okay to set a Conflicts between them as noted in the

- xref:packaging-guidelines::Conflicts.adoc#_compat_package_conflicts[Fedora conflicts guidelines].

- This is allowed both between EPEL packages and between EPEL and RHEL packages.

- The latter is an explicit exception to the general rule for EPEL packages to not conflict with target base RHEL packages.

- 

- [[policy_for_orphan_and_retired_packages]]

- == Policy for orphan and retired packages

- 

- EPEL follows the

- xref:fesco::Policy_for_orphan_and_retired_packages.adoc[Fedora

- policy for orphan and retired packages].

- 

- Unretiring an EPEL-only package requires a re-review.

- 

- No re-review is required to unretire an EPEL branch if the package is

- still in Fedora.

- 

- [[policy_for_end_of_life_releases]]

- == Policy for end-of-life releases

- 

- When a RHEL release reaches the end of the

- link:++https://access.redhat.com/support/policy/updates/errata#Life_Cycle_Dates++[Maintenance Support phase,title=RHEL life cycle],

- the corresponding EPEL release also goes end-of-life.

- On the day maintenance support ends for the RHEL release,

- Koji build targets are removed,

- and it is no longer possible to build or distribute new EPEL packages for that release.

- A short time after that, the now end-of-life EPEL repository is archived,

- and MirrorManager is adjusted to serve that repository from the archives.

- 

- For EPEL releases with minor versions (e.g. EPEL 10) the process is similar.

- When a new RHEL minor version is released, the branch associated to the previous

- minor release goes end-of-life.

- This means that it should go through the same retirement process.

- The final minor release will be active until the end of overall EPEL major release.

- 

- [[upgrade_path_policy]]

- == Upgrade path policy

- 

- Similar to

- xref:fesco::Package_maintainer_responsibilities.adoc#_miscellaneous_items[Fedora],

- EPEL packages *SHOULD* have a valid upgrade path between EPEL major versions.

- 

- * EPEL 8 -> EPEL 9 -> +EPEL 10.*+

- 

- This involves setting the `+Version:+` and `+Release:+` tags as appropriate in spec files,

- as well as the `+Epoch:+` tag if necessary.

- More information about these tags can be found in the

- xref:packaging-guidelines::Versioning.adoc[Fedora versioning guidelines].

- 

- For EPEL releases with minor versions (e.g. EPEL 10),

- EPEL packages *MUST* have a valid upgrade path between EPEL minor versions of the same major version.

- 

- * EPEL 10.0 -> EPEL 10.1 -> EPEL 10.2

- 

- A simple way to achieve this is to push changes to the leading branch (e.g. epel10) first,

- and then selectively fast-forward merge or cherry-pick commits to trailing branches (e.g. epel10.0, epel10.1) if needed.

- Diverging from this pattern is allowed but discouraged,

- as it can easily lead to upgrade path issues and prevent users from getting necessary updates.

@@ -1,42 +0,0 @@ 

- include::partial$attributes.adoc[]

- :experimental:

- 

- = EPEL Quality Assurance

- 

- [[epel_quality_assurance]]

- 

- EPEL strives to produce bug free and stable packages. Testing and

- Quality assurance is vital to this effort.

- 

- [[testing_packages]]

- == Testing packages

- 

- Packages entering the EPEL collection MUST spend 2 weeks or until they

- reach +3 karma in the updates system before being promoted as a stable

- update. During this time they are in the xref:epel-testing.adoc[epel-testing] 

- repository. Everyone is encouraged to install and test packages from this 

- repository and provide feedback. The link:++https://admin.fedoraproject.org/updates++[Bodhi

- web interface] is one place to provide feedback. You can also use the

- 'fedora-easy-karma' package to quickly provide feedback on all the

- packages you have installed from the epel-testing repository.

- 

- [[broken_dependency_reports]]

- == Broken dependency reports

- 

- Running periodic reports to find and note broken dependencies is another

- great way to ensure quality packages. Broken dependencies should never

- appear in the stable repos.

- 

- [[noting_packages_that_appear_in_both_epel_and_rhel]]

- == Noting packages that appear in both EPEL and RHEL

- 

- EPEL strives to never ship packages that are already available in RHEL.

- Noting and removing packages that this is the case for is another great

- way to help out with improving EPEL. Note that over the lifecycle of a

- RHEL release, new packages are sometimes added, so an EPEL package may

- start off as allowed and then need to be later removed.

- 

- [[fedora_qa_resources]]

- == Fedora QA resources

- See the link:++https://docs.fedoraproject.org/en-US/qa-docs/++[Fedora QA] page

- for information about helping with Fedora Quality.

@@ -1,18 +0,0 @@ 

- include::partial$attributes.adoc[]

- :experimental:

- 

- = RHEL entitlements for EPEL maintainers

- 

- EPEL maintainers can use the free

- link:++https://developers.redhat.com++[RHEL developer subscription]

- to develop and test their packages.

- The link:++https://rpm-software-management.github.io/mock/++[mock] tool includes

- `rhel+epel-<version>-<arch>.cfg` configuration files that

- link:++https://rpm-software-management.github.io/mock/Feature-rhelchroots++[integrate with this subscription],

- even on non-RHEL distributions such as Fedora.

- 

- An EPEL maintainer may alternatively use other RHEL-like distributions to develop and test their packages.

- Mock includes several other `<distro>+epel-<version>-<arch>.cfg` configuration files to choose from.

- These distributions will have some differences from RHEL.

- It is the maintainer's responsibility to ensure that their EPEL packages work on RHEL

- in spite of these differences.

@@ -1,102 +0,0 @@ 

- include::partial$attributes.adoc[]

- :experimental:

- 

- = The EPEL testing repository

- 

- The `*epel-testing*` repository contains updates scheduled to be released

- for the maintained releases of EPEL. User testing and feedback provided

- via link:++https://bodhi.fedoraproject.org++[Bodhi], on the

- link:++https://admin.fedoraproject.org/mailman/listinfo/epel-devel++[epel-devel]

- mailing list and the relevant link:++https://bugzilla.redhat.com++[Bugzilla] is

- vital to ensure that good updates are released quickly and bad ones kept

- away from release.

- 

- [[using_the_epel_testing_repository]]

- == Using the epel-testing repository

- 

- [[enabling_the_repository_persistently]]

- === Enabling the repository persistently

- 

- The following command will enable the `epel-testing` repository persistently.

- 

- [,console]

- ----

- $ dnf config-manager --set-enabled epel-testing

- ----

- 

- Use `dnf repolist` to verify.

- If you wish to disable it again,

- run the following command.

- 

- [,console]

- ----

- $ dnf config-manager --set-disabled epel-testing

- ----

- 

- TIP: `dnf distro-sync` will sync the packages to the versions available in the repository.

- This might be useful to run after you disable the testing repository

- to downgrade packages back to the stable versions.

- 

- [NOTE] 

- ====

- The `dnf config-manager` command is available as part of the dnf-plugins-core package.

- You can also edit the `/etc/yum.repos.d/epel-testing.repo` file manually

- to set `enabled=1` under the `[epel-testing]` section.

- ====

- 

- [[enabling_the_repository_temporarily]]

- === Enabling the repository temporarily

- 

- You can enable the the `epel-testing` repository on a case-by-case basis instead of persistently.

- 

- The following command will enable the `epel-testing` repository for a single upgrade transaction.

- 

- [,console]

- ----

- $ dnf --enablerepo epel-testing upgrade

- ----

- 

- The following command will enable the `epel-testing` repository for a single install transaction.

- 

- [,console]

- ----

- $ dnf --enablerepo epel-testing install <foo>

- ----

- 

- [[what_to_test_testing_and_reporting_results]]

- == What to test, testing, and reporting results

- 

- The link:++https://bodhi.fedoraproject.org++[Bodhi] system is used to track and

- collate feedback on testing updates. All testing updates will be shown

- in the Bodhi system. First of all, if any test update package works

- worse for you in any respect than the pre-update version did, this is a

- problem that should be communicated to the developers. Secondly, when

- you click on a certain update, you will see a screen with more

- information on the update. The `Details` section should give you

- information on what the update is intended to fix. You should, if

- possible, test that the update does indeed fix the issues it claims to

- fix.

- 

- You can give your feedback on a test update by using the

- link:++https://bodhi.fedoraproject.org++[Bodhi web interface]. There is a `Login`

- link in the left-hand sidebar. Log in using your Fedora account. If you

- don't have a Fedora account, you can

- link:++https://admin.fedoraproject.org/accounts/user/new++[create an account

- here]. Once you are logged in, you will be able to leave a comment on

- the update. Underneath the comment box are three options: `Untested`,

- `Works for me`, and `Does not work`. For a guide on when to leave each

- type of feedback, read the 

- link:++https://fedoraproject.org/wiki/QA:Update_feedback_guidelines++[update feedback guidelines].

- 

- Each `Works for me` adds 1 to the test update's karma, while each

- `Does not work` subtracts 1 from it. `Untested` leaves the karma

- unchanged. Usually, test updates with karma of 3 are automatically sent

- out as full official updates, while test updates with karma of -3 are

- automatically withdrawn from the testing repository. As you can see,

- your testing and feedback is vital to make sure that good updates are

- released quickly and bad ones don't get out to the general public.

- 

- [[see_also]]

- == See also

- 

- * link:++https://fedoraproject.org/wiki/Bodhi++[Bodhi Guide]

@@ -1,139 +0,0 @@ 

- include::partial$attributes.adoc[]

- :experimental:

- 

- = Getting started with EPEL

- 

- To enable the EPEL repository on your system,

- install the appropriate release package as described below.

- These packages contain the repository configuration and public package signing key.

- 

- [CAUTION] 

- ====

- Some EPEL packages depend on packages from repositories that are not enabled by default.

- Take note of the additional repositories being enabled in the instructions on this page.

- ====

- 

- [NOTE]

- ====

- For convenience,

- some distributions include copies of EPEL release packages in their default repositories,

- allowing you to install them by name without the full URL.

- The EPEL project recommends using the official permalinks on this page to ensure the best experience.

- ====

- 

- == Release package permalinks

- 

- * link:++https://dl.fedoraproject.org/pub/epel/epel-release-latest-10.noarch.rpm++[epel-release-latest-10]

- * link:++https://dl.fedoraproject.org/pub/epel/epel-next-release-latest-9.noarch.rpm++[epel-next-release-latest-9]

- * link:++https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm++[epel-release-latest-9]

- * link:++https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm++[epel-release-latest-8]

- 

- == EL10

- 

- === CentOS Stream 10

- 

- [,console]

- ----

- $ dnf config-manager --set-enabled crb

- $ dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-10.noarch.rpm

- ----

- 

- === RHEL 10

- 

- [,console]

- ----

- $ subscription-manager repos --enable codeready-builder-for-rhel-10-$(arch)-rpms

- $ dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-10.noarch.rpm

- ----

- 

- == EL9

- 

- [NOTE]

- ====

- EPEL 9 has two different release packages.

- If you are using RHEL 9,

- only install the `epel-release` package.

- If you are using CentOS Stream 9,

- install *both* the `epel-release` and `epel-next-release` packages.

- ====

- 

- === CentOS Stream 9

- 

- [,console]

- ----

- $ dnf config-manager --set-enabled crb

- $ dnf install https://dl.fedoraproject.org/pub/epel/epel{,-next}-release-latest-9.noarch.rpm

- ----

- 

- === RHEL 9

- 

- [,console]

- ----

- $ subscription-manager repos --enable codeready-builder-for-rhel-9-$(arch)-rpms

- $ dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm

- ----

- 

- === Other RHEL 9 compatible distributions

- 

- EPEL 9 officially targets CentOS Stream 9 and RHEL 9.

- EPEL 9 packages will also likely work with other distributions

- that target RHEL 9 compatibility.

- We cannot list specific instructions for all such distributions,

- but in general the steps needed should look similar to the steps for RHEL 9.

- First enable the distribution's equivalent of the CRB repository,

- then install the `epel-release` package.

- 

- [,console]

- ----

- $ dnf config-manager --set-enabled crb

- $ dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm

- ----

- 

- == EL8

- 

- === RHEL 8

- 

- [,console]

- ----

- $ subscription-manager repos --enable codeready-builder-for-rhel-8-$(arch)-rpms

- $ dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm

- ----

- 

- === Other RHEL 8 compatible distributions

- 

- EPEL 8 officially targets RHEL 8.

- EPEL 8 packages will also likely work with other distributions

- that target RHEL 8 compatibility.

- We cannot list specific instructions for all such distributions,

- but in general the steps needed should look similar to the steps for RHEL 8.

- First enable the distribution's equivalent of the PowerTools/CRB repository,

- then install the `epel-release` package.

- 

- [,console]

- ----

- $ dnf config-manager --set-enabled powertools

- $ dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm

- ----

- 

- [[end_of_life_releases]]

- == Previous versions (End-of-life releases)

- 

- [WARNING]

- ====

- *End-of-life releases are no longer supported.*

- ====

- 

- [NOTE]

- ====

- Due to major security changes in SSL in the last 10 years, older

- releases may not be able to directly point to these releases. As of

- 2021-01-22, EPEL-5 and 4 systems do not have the newer TLS 1.2 algorithms

- that Internet servers are required to use for security reasons. The best

- method for working with these is to have a newer system mirror the

- entire archive and then for your systems to point to that mirror.

- ====

- 

- * EPEL 7: link:++https://dl.fedoraproject.org/pub/archive/epel/7/++[]

- * EPEL 6: link:++https://dl.fedoraproject.org/pub/archive/epel/6/++[]

- * EPEL 5: link:++https://dl.fedoraproject.org/pub/archive/epel/5/++[]

- * EPEL 4: link:++https://dl.fedoraproject.org/pub/archive/epel/4/++[]

@@ -1,52 +0,0 @@ 

- include::partial$attributes.adoc[]

- :experimental:

- 

- = Extra Packages for Enterprise Linux (EPEL)

- 

- image::epel-logo.svg[EPEL]

- 

- [[extra_packages_for_enterprise_linux_epel]]

- 

- Welcome to the home of the EPEL Special Interest Group.

- 

- The goal of EPEL is to make high quality Fedora packages available for RHEL and compatible derivatives.

- 

- == Setting up EPEL

- 

- Learn more about getting started using EPEL on the xref:getting-started.adoc[How to use EPEL]

- page. See also xref:available-packages.adoc[Available packages] to see what packages

- are available for each version.

- 

- [[what_is_extra_packages_for_enterprise_linux_or_epel]]

- == What is Extra Packages for Enterprise Linux (or EPEL)?

- 

- Extra Packages for Enterprise Linux (EPEL) is an initiative within the

- link:++https://fedoraproject.org/++[Fedora Project]

- to provide high quality additional packages for

- link:++https://centos.org/++[CentOS Stream] and

- link:++https://redhat.com/rhel++[Red Hat Enterprise Linux] (RHEL).

- 

- EPEL packages are usually based on their Fedora counterparts

- and should not conflict with or replace packages in the base Enterprise Linux distributions.

- EPEL uses much of the same infrastructure as Fedora,

- including buildsystem, Bugzilla instance, updates manager, mirror manager and more.

- 

- Learn more about EPEL in the following pages:

- 

- * link:epel-about[About EPEL]

- 

- * link:epel-policy[EPEL guidelines and policies]

- 

- * link:epel-faq[EPEL FAQ]

- 

- [[history_and_background_of_the_project]]

- == History and background of the project

- 

- The EPEL project was born when Fedora maintainers realized that the same

- infrastructure that builds and maintains packages for Fedora would be

- great to also maintain add on packages for Enterprise Linux. Much of the

- early need was driven by what Fedora infrastructure needed on the RHEL

- machines that built and maintained Fedora. From there things have grown

- to a large collection of varied packages. See

- link:epel-about-history-philosophy[our History and philosophy page] for

- more information.

@@ -1,1 +0,0 @@ 

- :year: 2025

@@ -1,15 +0,0 @@ 

- This is an example of a partial file. Unlike files in `pages/`, files in this directory are not built as standalone pages, but only if they are included in a file within `pages/`. This stops fragments of pages being built and discovered by search engines.

- 

- A file in this directory can be included within any file in the `pages/` directory.

- 

- Most common use cases for partials are:

- 

- . Reusing attributes such as the current year or a release version throughout the entire module while being able to change it easily (such as changing "Fedora 33" to "Fedora 34" when a new release comes out).

- . Reusing content such a banner or an infobox (`[NOTE]`, etc.) that appears on multiple pages and needs to have consistent content everywhere (such as a message on some of the quick-docs that warns the reader about their unreviewed status).

- 

- In these cases, you can use a partial to include the same content in multiple places, and you only need to change it once to get the change to appear in every spot it's included in. You can see the first example used in `pages/index.adoc` in this repository; note the include statement on top.

- 

- If you want to include this particular example somewhere, you can use the following syntax: `include::partial$partial-example.adoc[]`.

- Note the use of `partial$` instead of an actual file location.

- 

- See link:++https://docs.antora.org/antora/3.0/partials-directory/++[Antora docs on partials] for more information about partials.

file removed
-14
@@ -1,14 +0,0 @@ 

- server {

-     listen       80;

-     server_name  localhost;

- 

-     location / {

-         root   /antora/public;

-         index  index.html index.htm;

-     }

- 

-     error_page   500 502 503 504  /50x.html;

-     location = /50x.html {

-         root   /usr/share/nginx/html;

-     }

- }

file removed
-177
@@ -1,177 +0,0 @@ 

- # Makefile for Sphinx documentation

- #

- 

- # You can set these variables from the command line.

- SPHINXOPTS    =

- SPHINXBUILD   = sphinx-build

- PAPER         =

- BUILDDIR      = build

- 

- # User-friendly check for sphinx-build

- ifeq ($(shell which $(SPHINXBUILD) >/dev/null 2>&1; echo $$?), 1)

- $(error The '$(SPHINXBUILD)' command was not found. Make sure you have Sphinx installed, then set the SPHINXBUILD environment variable to point to the full path of the '$(SPHINXBUILD)' executable. Alternatively you can add the directory with the executable to your PATH. If you don't have Sphinx installed, grab it from http://sphinx-doc.org/)

- endif

- 

- # Internal variables.

- PAPEROPT_a4     = -D latex_paper_size=a4

- PAPEROPT_letter = -D latex_paper_size=letter

- ALLSPHINXOPTS   = -d $(BUILDDIR)/doctrees $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) source

- # the i18n builder cannot share the environment and doctrees with the others

- I18NSPHINXOPTS  = $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) source

- 

- .PHONY: help clean html dirhtml singlehtml pickle json htmlhelp qthelp devhelp epub latex latexpdf text man changes linkcheck doctest gettext

- 

- help:

- 	@echo "Please use \`make <target>' where <target> is one of"

- 	@echo "  html       to make standalone HTML files"

- 	@echo "  dirhtml    to make HTML files named index.html in directories"

- 	@echo "  singlehtml to make a single large HTML file"

- 	@echo "  pickle     to make pickle files"

- 	@echo "  json       to make JSON files"

- 	@echo "  htmlhelp   to make HTML files and a HTML help project"

- 	@echo "  qthelp     to make HTML files and a qthelp project"

- 	@echo "  devhelp    to make HTML files and a Devhelp project"

- 	@echo "  epub       to make an epub"

- 	@echo "  latex      to make LaTeX files, you can set PAPER=a4 or PAPER=letter"

- 	@echo "  latexpdf   to make LaTeX files and run them through pdflatex"

- 	@echo "  latexpdfja to make LaTeX files and run them through platex/dvipdfmx"

- 	@echo "  text       to make text files"

- 	@echo "  man        to make manual pages"

- 	@echo "  texinfo    to make Texinfo files"

- 	@echo "  info       to make Texinfo files and run them through makeinfo"

- 	@echo "  gettext    to make PO message catalogs"

- 	@echo "  changes    to make an overview of all changed/added/deprecated items"

- 	@echo "  xml        to make Docutils-native XML files"

- 	@echo "  pseudoxml  to make pseudoxml-XML files for display purposes"

- 	@echo "  linkcheck  to check all external links for integrity"

- 	@echo "  doctest    to run all doctests embedded in the documentation (if enabled)"

- 

- clean:

- 	rm -rf $(BUILDDIR)/*

- 

- html:

- 	$(SPHINXBUILD) -b html $(ALLSPHINXOPTS) $(BUILDDIR)/html

- 	@echo

- 	@echo "Build finished. The HTML pages are in $(BUILDDIR)/html."

- 

- dirhtml:

- 	$(SPHINXBUILD) -b dirhtml $(ALLSPHINXOPTS) $(BUILDDIR)/dirhtml

- 	@echo

- 	@echo "Build finished. The HTML pages are in $(BUILDDIR)/dirhtml."

- 

- singlehtml:

- 	$(SPHINXBUILD) -b singlehtml $(ALLSPHINXOPTS) $(BUILDDIR)/singlehtml

- 	@echo

- 	@echo "Build finished. The HTML page is in $(BUILDDIR)/singlehtml."

- 

- pickle:

- 	$(SPHINXBUILD) -b pickle $(ALLSPHINXOPTS) $(BUILDDIR)/pickle

- 	@echo

- 	@echo "Build finished; now you can process the pickle files."

- 

- json:

- 	$(SPHINXBUILD) -b json $(ALLSPHINXOPTS) $(BUILDDIR)/json

- 	@echo

- 	@echo "Build finished; now you can process the JSON files."

- 

- htmlhelp:

- 	$(SPHINXBUILD) -b htmlhelp $(ALLSPHINXOPTS) $(BUILDDIR)/htmlhelp

- 	@echo

- 	@echo "Build finished; now you can run HTML Help Workshop with the" \

- 	      ".hhp project file in $(BUILDDIR)/htmlhelp."

- 

- qthelp:

- 	$(SPHINXBUILD) -b qthelp $(ALLSPHINXOPTS) $(BUILDDIR)/qthelp

- 	@echo

- 	@echo "Build finished; now you can run "qcollectiongenerator" with the" \

- 	      ".qhcp project file in $(BUILDDIR)/qthelp, like this:"

- 	@echo "# qcollectiongenerator $(BUILDDIR)/qthelp/FedoraReleaseEngineering.qhcp"

- 	@echo "To view the help file:"

- 	@echo "# assistant -collectionFile $(BUILDDIR)/qthelp/FedoraReleaseEngineering.qhc"

- 

- devhelp:

- 	$(SPHINXBUILD) -b devhelp $(ALLSPHINXOPTS) $(BUILDDIR)/devhelp

- 	@echo

- 	@echo "Build finished."

- 	@echo "To view the help file:"

- 	@echo "# mkdir -p $$HOME/.local/share/devhelp/FedoraReleaseEngineering"

- 	@echo "# ln -s $(BUILDDIR)/devhelp $$HOME/.local/share/devhelp/FedoraReleaseEngineering"

- 	@echo "# devhelp"

- 

- epub:

- 	$(SPHINXBUILD) -b epub $(ALLSPHINXOPTS) $(BUILDDIR)/epub

- 	@echo

- 	@echo "Build finished. The epub file is in $(BUILDDIR)/epub."

- 

- latex:

- 	$(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex

- 	@echo

- 	@echo "Build finished; the LaTeX files are in $(BUILDDIR)/latex."

- 	@echo "Run \`make' in that directory to run these through (pdf)latex" \

- 	      "(use \`make latexpdf' here to do that automatically)."

- 

- latexpdf:

- 	$(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex

- 	@echo "Running LaTeX files through pdflatex..."

- 	$(MAKE) -C $(BUILDDIR)/latex all-pdf

- 	@echo "pdflatex finished; the PDF files are in $(BUILDDIR)/latex."

- 

- latexpdfja:

- 	$(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex

- 	@echo "Running LaTeX files through platex and dvipdfmx..."

- 	$(MAKE) -C $(BUILDDIR)/latex all-pdf-ja

- 	@echo "pdflatex finished; the PDF files are in $(BUILDDIR)/latex."

- 

- text:

- 	$(SPHINXBUILD) -b text $(ALLSPHINXOPTS) $(BUILDDIR)/text

- 	@echo

- 	@echo "Build finished. The text files are in $(BUILDDIR)/text."

- 

- man:

- 	$(SPHINXBUILD) -b man $(ALLSPHINXOPTS) $(BUILDDIR)/man

- 	@echo

- 	@echo "Build finished. The manual pages are in $(BUILDDIR)/man."

- 

- texinfo:

- 	$(SPHINXBUILD) -b texinfo $(ALLSPHINXOPTS) $(BUILDDIR)/texinfo

- 	@echo

- 	@echo "Build finished. The Texinfo files are in $(BUILDDIR)/texinfo."

- 	@echo "Run \`make' in that directory to run these through makeinfo" \

- 	      "(use \`make info' here to do that automatically)."

- 

- info:

- 	$(SPHINXBUILD) -b texinfo $(ALLSPHINXOPTS) $(BUILDDIR)/texinfo

- 	@echo "Running Texinfo files through makeinfo..."

- 	make -C $(BUILDDIR)/texinfo info

- 	@echo "makeinfo finished; the Info files are in $(BUILDDIR)/texinfo."

- 

- gettext:

- 	$(SPHINXBUILD) -b gettext $(I18NSPHINXOPTS) $(BUILDDIR)/locale

- 	@echo

- 	@echo "Build finished. The message catalogs are in $(BUILDDIR)/locale."

- 

- changes:

- 	$(SPHINXBUILD) -b changes $(ALLSPHINXOPTS) $(BUILDDIR)/changes

- 	@echo

- 	@echo "The overview file is in $(BUILDDIR)/changes."

- 

- linkcheck:

- 	$(SPHINXBUILD) -b linkcheck $(ALLSPHINXOPTS) $(BUILDDIR)/linkcheck

- 	@echo

- 	@echo "Link check complete; look for any errors in the above output " \

- 	      "or in $(BUILDDIR)/linkcheck/output.txt."

- 

- doctest:

- 	$(SPHINXBUILD) -b doctest $(ALLSPHINXOPTS) $(BUILDDIR)/doctest

- 	@echo "Testing of doctests in the sources finished, look at the " \

- 	      "results in $(BUILDDIR)/doctest/output.txt."

- 

- xml:

- 	$(SPHINXBUILD) -b xml $(ALLSPHINXOPTS) $(BUILDDIR)/xml

- 	@echo

- 	@echo "Build finished. The XML files are in $(BUILDDIR)/xml."

- 

- pseudoxml:

- 	$(SPHINXBUILD) -b pseudoxml $(ALLSPHINXOPTS) $(BUILDDIR)/pseudoxml

- 	@echo

- 	@echo "Build finished. The pseudo-XML files are in $(BUILDDIR)/pseudoxml."

@@ -1,400 +0,0 @@ 

- ========

-  Vision

- ========

- 

- Visions are for people who stand on mountains. System administrators

- and operators are people just trying to get stuff done and have the

- pager not go off one night.

- 

- =========

-  Mission

- =========

- 

- To build a curated set of packages built from Fedora releases that

- help system administrators get their jobs done on Red Hat Enterprise

- Server and related operating systems.

- 

- =========

-  History

- =========

- 

- Red Hat Enterprise Linux (RHEL) is technically a downstream of the Fedora

- Project. Various RHEL releases have been based off either Red Hat

- Linux or Fedora releases.

- 

-   * RHEL 2.1 == Red Hat Linux 7.2

-   * RHEL 3   == Red Hat Linux 9/Fedora Core 1

-   * RHEL 4   == Fedora Core 3

-   * RHEL 5   == Fedora Linux 6

-   * RHEL 6   == Fedora Linux 12/13

-   * RHEL 7   == Fedora Linux 18/19

- 

- RHEL releases are not the entirety of any Fedora release, but a subset

- that Red Hat feels best meets the needs of their customers while being

- long term maintainable by Red Hat. This means that many packages that

- are available in Fedora wouldn't be available in RHEL and would have

- to be found somewhere else.

- 

- Early on, many of these packages were maintained by various Forges and

- developers who would put these packages up on websites for others to

- use as they needed. Sometimes these packages would conflict with

- either RHEL packages or each other. Othertimes the packages would get

- updated rapidly to meet the developers needs but not other

- users. Various people felt that maybe it would be better to build

- packages from Fedora into an Extras repository that could be used by

- people.

- 

- Initially there was some consensus of packagers joining together, but

- eventually disagreements emerged on various packaging philosophies

- which caused EPEL to go one way and others to go another.

- 

- ==================

-  Initial Policies

- ==================

- 

- The initial packaging philosophy has been that EPEL will never replace

- a package that is shipped in Red Hat Enterprise Linux and that maintainers

- would not push any updates that required interactive attention to

- continue working.

- 

- ==================

-  Current Policies

- ==================

- When RHEL was small it was easy to not conflict, but as RHEL split into

- various products (Server, Workstation, etc.) and then further split

- into a great many (sometimes conflicting) channels, this policy became

- untenable.

- 

- Likewise when software was designed for long periods of stablity, it

- was easy to ensure unattented updates worked fine, but many new packages

- have a much faster life cycle than the RHEL they are built on, so this

- policy as well became difficult.

- 

- Currently EPEL will strive to never replace a package in some specific

- set of RHEL channels. See:

- 

- epel7 - https://koji.fedoraproject.org/koji/taginfo?tagID=259

- epel6 - https://koji.fedoraproject.org/koji/taginfo?tagID=140

- epel5 - https://koji.fedoraproject.org/koji/taginfo?tagID=81

- 

- EPEL maintainers will strive to make updates non interactive and working,

- however exceptions will be made from time to time due to upstream

- support life cycles. Interested parties are encouraged to

- subscribe to the epel-announce list.

- 

- ====================

-  Organization Rules

- ====================

- 

- Steering Committee

- ==================

- 

- The EPEL Steering Committee (EPSCO) is made up of interested members

- of the various Red Hat Enterprise Linux rebuild communities.  As of

- 2017-03, the membership consists of 2 members from CentOS, 2 members

- from Fedora and 1 member who sits in both.

- 

- * Stephen Smoogen (smooge)

- * Kevin Fenzi     (nirik)

- * Brian Stinson   (bstinson)

- * Jim Perrin      (Evolution)

- * Anssi Johansson (avij)

- 

- EPEL and the EPEL Steering Committee are chartered by the Fedora

- Council. The Fedora Council can override any decision made by EPSCO.

- The size of the EPSCO committee is set by the committee but can be

- increased or decreased by the Fedora Council.

- 

- Each member of EPSCO will confirm their continued membership on the

- committee once a year.  If a member leaves, then the remaining members

- should canvas for a replacement and at the next general meeting hold a

- general nomination and in meeting "election" of any candidates. If

- there are multiple candidates or other complications, an election

- using the Fedora voting system will be held.

- 

- A committee member can be removed by a super plurality vote of the

- other Steering Committee Members. [For the current committee size that

- would be 4/5ths.]

- 

- Responsibilities

- ================

- EPSCO is charged with meeting regularly to go over current problems

- and concerns of the EPEL community. It will create policies governing

- what releases EPEL will build for, what packages may be in the

- repository, testing and packaging requirements and all other policies

- needed for the well being of the EPEL community.

- 

- 

- Meetings

- ========

- * EPSCO will hold meetings no less than once a month in

-   #fedora-meeting on Wednesdays at 1800 UTC. This time will not change

-   with various country daylight savings.

- * A quorum of members is 4/5ths of the committee members.

- * An agenda for each meeting should be published 12 hours before the

-   meeting.

- * If there is no agenda or not a quorum for meeting, then the meeting

-   will have only one item which is "select items for the next meetings

-   agenda". This will be emailed to the list and requests from there added.

- * If a voting member can not attend, they can ask for a vote to be

-   retaken either by email or the next meeting.

- * After meetings, meeting minutes will be posted to the Fedora meeting

-   list. They should be also posted by the chair to the epel-devel

-   mailing list.

- 

- Making Decisions

- ================

- In general, decisions by EPSCO should be done by consensus. [

- https://en.wikipedia.org/wiki/Consensus_decision-making#Objectives ] In the

- case, where there is a disagreement by members, a simple majority vote

- of the committee will decide the matter.

- 

- 

- ==================

-  General Policies

- ==================

- 1. Package Inclusion

- 2. Package Exclusion

- 3. Package Removal

- 4. Package General Updates

- 5. Package Incompatible Updates

- 6. Packaging Rules

-   a. RHEL6

-   b. RHEL7

- 

- 

- =====================

-  EPEL Updates Policy

- =====================

- 

- This document describes the policy for updates to packages in the EPEL

- package collection. For general EPEL package guidelines, refer to the

- EPEL Guidelines and Policy page.

- 

- Beta Releases

- -------------

- 

- When a new Enterprise Linux major version (example 7, 8, 9) is being

- tested and has been released as a open Beta version, EPEL will create

- a Beta EPEL collection version against that release. This branch will

- follow a process much like Fedora's rawhide repository. Packages built

- in this Beta EPEL will be signed and pushed out each day. There will

- be only one repository (no testing). Packages in this Beta collection

- could be removed, or updated in an incompatible manner if needed

- before the collection is released as stable. At some point after the

- Enterprise Linux version is released, EPEL will leave Beta status and

- move to a stable model for this collection.

- 

- Stable Releases

- ---------------

- 

- Once a Enterprise Linux is released, and EPEL has left Beta and

- entered it's stable phase the follow applies:

- 

- * All updates MUST spend at least 2 weeks in the testing repository,

-   or +3 karma from testers.

- * All updates should strive to avoid situations that require manual

-   intervention to keep the package functioning after update.

- * Major updates with changes to user experience are to be avoided. If

-   they cannot be avoided, the EPEL incompatible upgrades policy MUST

-   be followed. This includes two separate announcements to the

-   epel-announce mailing list.

- * When new packages enter the Enterprise Linux distribution that is

- already available in EPEL, that package will be marked dead.package

- and blocked in pkgdb and koji.

- 

- Exceptions

- ----------

- 

- In some rare cases, exceptions will need to be made. Bring your case

- before the EPEL Steering Committee at one of the weekly meetings

- and/or the epel-devel mailing list. Possibly grounds for exception

- might include:

- 

- * Serious security issue that cannot be backported to the existing

-   version, so a new major version is required.

- * Serious bugs that cannot be fixed in the existing version.

- 

- In cases of major disruption, EPEL updates will looked to be done

- along with Red Hat Enterprise Linux minor releases (6.1, 6.2, 6.3) so

- as to allow for longer testing or differing beta testing.

- 

- ==========================

-  EPEL Package Maintainers

- ==========================

- 

- EPEL packages are maintained by members of the community. These

- maintainers respond to bug reports, update packages and add new

- packages to the collection as needed. EPEL packagers are members of

- the Fedora "packagers" group.

- 

- Joining the EPEL Package Maintainers

- ------------------------------------

- 

- There are several ways you can join the EPEL package maintainer group:

- 

- 1. If you are an existing Fedora package maintainer, you can maintain

-    EPEL packages by becoming a maintainer or co-maintainer of an

-    existing EPEL package, which you can apply for in pkgdb. You can

-    also request EPEL branches for your Fedora package and maintain

-    them for EPEL with a Package SCM request.

- 

- 2. If you are not currently in the Fedora packager group, you could

-    join that group by submitting one or more new packages for

-    Fedora/EPEL, and following the normal Fedora sponsorship

-    process. Then, simply request EPEL branches for your new packages

-    once they are approved.

- 

- 3. If you are not currently in the Fedora packager group and wish to

-    help co-maintain one or more packages in EPEL, you can try and find

-    an existing package and maintainer of that package who wishes to

-    mentor you. You can then follow the "Become a co-maintainer" path

-    to sponsorship.

- 

- 4. If you are an existing EPEL/Fedora maintainer and wish to maintain

-    a package in EPEL that someone else maintains in Fedora, file a bug

-    asking them if they would like to maintain it in EPEL, if no

-    response in a week or if the Fedora maintain has no interested in

-    EPEL, request the branch yourself and maintain it.

- 

- EPEL Policies and Guidelines

- ----------------------------

- 

- Where possible, EPEL tries to use and follow any applicable Fedora

- guidelines. There are of course some exceptions due to older packages

- and EPEL seeking stability over newer packages. You can find a list of

- all such guidelines at the EPEL Packaging Guidelines page.

- 

- EPEL Updates policy

- -------------------

- 

- EPEL strives to provide updates that are compatible and stable to

- compliment the Enterprise Linux packages it's built on. You can find a

- detailed list of updates policies on the EPEL Updates Policy page as

- well as a page on incompatible updates when they absolutely can't be

- avoided

- 

- EPEL Testing Needs

- ------------------

- 

- The easiest method for testing EPEL is to use CentOS or Scientific

- Linux in order to do initial testing of builds. These are 'rebuilds'

- of Red Hat Enterprise Linux and may contain packages which slightly

- differ from the upstream release.

- 

- A developer who wants to build and test against a particular Red Hat

- Enterprise Linux should join the Red Hat developer program at

- https://developers.redhat.com/products/rhel/download/ .

- 

- 

- New Package Wish List

- ---------------------

- 

- The best way to get a new package into EPEL is to first get it added

- to Fedora. You can add such packages to the wish list for Fedora.

- 

- It is possible to have packages only in EPEL, for example if the

- functionality has already been merged in a more recent package in

- Fedora, but it should be exceptional. Such packages can be submitted

- for review as per the regular process. Be ready to discuss why your

- package only applies to EPEL.

- 

- If the package is in Fedora but not in EPEL, see above.

- 

- ==============================

-  Incompatible upgrades policy

- ==============================

- 

- Background

- ----------

- 

- Incompatible version upgrades in EPEL are to be avoided. However, in

- certain situations, they are unavoidable. An example of such a

- situation would be a security update that is difficult/impossible to

- backport. This policy aims to both discourage incompatible upgrades

- for trivial reasons, while allowing them for security updates where

- the version of the software in question is no longer maintained

- upstream and the maintainer is unable to backport just the security

- fix/

- 

- Process for incompatible upgrades

- ---------------------------------

- 

- 1. Send e-mail to epel-devel with details of the proposed

-    upgrade. Include items such as the CVE of the security issue to be

-    fixed, and/or an upstream bug tracker reference (if

-    applicable). Also reference a bug in bugzilla.redhat.com against

-    the package.

- 2. Discussion takes place on epel-devel for a minimum period of 1 week

-    (need some way to short-circuit this for critical security

-    updates - i.e. remote root)

- 3. Item is added to agenda for discussion at weekly EPEL meeting

- 4. If a majority of those present at the EPEL meeting concur, the

-    incompatible upgrade can be built.

- 5. At the same time that the update is submitted to bodhi for testing,

-    the maintainer is responsible for sending e-mail to epel-announce

-    announcing the incompatible upgrade and specific actions that users

-    must take in order to continue using the software.

- 6. Package MUST remain in testing for at least 2 weeks, regardless of

-    received karma. In bodhi, 'Auto-request stable?' MUST NOT be

-    checked.

- 7. When pushing package to stable, the maintainer MUST send another

-    e-mail to epel-announce.

- 

- Procedure for other packages

- ----------------------------

- 

- For other - non-security - updates, the maintainer MUST NOT push those

- types of changes to the stable package. Instead, a new package must be

- made, pass review, and be branched for EPEL only.

- 

- For example, an rdiff-backup upgrade for the reasons of an

- incompatible protocol change would be required to create a new

- package, called rdiff-backup12 and have that package pass review and

- imported into CVS.

- 

- Discussion points

- -----------------

- 

- 1. How to short-circuit process for critical security updates

- 2. Approval process - majority of those present seems to be lax, but

-    being there's no body such as FESCo in "charge" of EPEL (yes, I

-    realize that FESCo has oversight, but oversight != make day-to-day

-    decisions such as these), I'm not sure what else to put there.

- 3. How to enforce the mail to epel-announce? Maybe have the chair of

-    the EPEL meeting send it?

- 

- 

- ========================

-  EPEL Quality Assurance

- ========================

- 

- EPEL strives to produce bug free and stable packages. Testing and

- Quality assurance is vital to this effort.

- 

- Testing packages

- ----------------

- 

- Packages entering the EPEL collection MUST spend 2 weeks or until they

- reach +3 karma in the updates system before being promoted as a stable

- update. During this time they are in the epel-testing

- repository. Everyone is encouraged to install and test packages from

- this repository and provide feedback. The Bodhi web interface is one

- place to provide feedback. You can also use the 'fedora-easy-karma'

- package to quickly provide feedback on all the packages you have

- installed from the epel-testing repository.

- 

- Broken dependency reports

- -------------------------

- 

- Running periodic reports to find and note broken dependencies is

- another great way to ensure quality packages. Broken dependencies

- should never appear in the stable repos.

- 

- Noting packages that appear in both EPEL and RHEL

- -------------------------------------------------

- 

- EPEL strives to never ship packages that are already available in

- RHEL. Noting and removing packages that this is the case for is

- another great way to help out with improving EPEL.

- 

@@ -1,117 +0,0 @@ 

- ======================

-  EPEL meeting process

- ======================

- 

- This guide explains how to manage and run a EPEL IRC meeting. Many of

- the steps here could well apply to other groups that hold regular IRC

- meetings as well.

- 

- Pre-meeting

- ===========

- 

- On Tuesday before the Wednesday meeting, do the following tasks:

- 

- 1. First, check the trac "All Active Tickets" report:

- 

-    https://pagure.io/epel/issues

- 

- 2. For each ticket, make sure to check with and invite stakeholders

-    who may not be CC'd in the ticket. Consider deferring issue if

-    stakeholders have not had adequate notice and are not available for

-    discussion.

- 

- 3. When a ticket is ready for discussion, add the 'meeting' keyword.

- 

- 4. Generate an email to the epel-devel@lists.fedoraproject.org list

-    with the following template:

- 

- ---------------------------------------------------------------

- 

- Schedule for this weeks EPEL Meeting (YYYY-MM-DD)

- 

- Following is the list of topics that will be discussed in the EPEL

- meeting Wednesday at 18:00UTC in #fedora-meeting on irc.freenode.net.

- 

- To convert UTC to your local time, take a look at

-   http://fedoraproject.org/wiki/UTCHowto

- 

- or run:

-   date -d '{{#time:Y-m-d|wednesday}} 18:00 UTC'

- 

- Links to all tickets below can be found at:

-    https://pagure.io/epel/issues

- 

- 

- AGENDA

- ======

- 

-    #startmeeting EPEL (YYYY-MM-DD)

-    #meetingname EPEL

-    #topic aloha

-    #chair avij bstinson Evolution nirik smooge

-    #topic Announcements

-    #info << Fill in announcements from last meeting >>

-    #info << Fill in announcements for upcoming events >>

-    #topic Ticket #NNN Title

-    #topic Next Meeting Business

-    #info << Get items from people. Put enough for ticket >>

-    #topic Open Floor

-    #endmeeting

- 

- 

- If you would like to add something to this agenda, you can reply to

- this e-mail, file a new ticket at https://pagure.io/epel,

- e-mail me directly, or bring it up at the end of the meeting, during

- the open floor topic. Note that added topics may be deferred until

- the following meeting.

- 

- ---------------------------------------------------------------

- 

- Day of meeting

- ==============

- 

- 1. Send out a reminder IRC message a bit before the meeting to the

-    #epel IRC channel.

- 

- 2. Generate a text file from the following template:

- 

-    #startmeeting EPEL (YYYY-MM-DD)

-    #meetingname EPEL

-    #topic aloha

-    #chair avij bstinson Evolution nirik smooge

-    #topic Announcements

-    #info << Fill in announcements from last meeting >>

-    #info << Fill in announcements for upcoming events >>

-    #topic Ticket #NNN Title

-    #topic Next Meeting Business

-    #info << Get items from people. Put enough for ticket >>

-    #topic Open Floor

-    #endmeeting

- 

- 

- You can copy and paste in lines from this file as the meeting progresses.

- 

- 3. Start an email replying to the agenda post. Change the subject to:

-    Summary/Minutes for today's EPEL meeting (YYYY-MM-DD)

- 

- Meeting time

- ============

- 

- 1. Use the lines up to 'init process' to start the meeting.

- 

- 2. Wait a few for people to show up. Confirm there are at least (3)

-    voting members present for Quorum. If not, cancel meeting.

- 

- 3. Go through each topic. Watch time on each and if 15minutes are

-    reached, ask if people want to keep discussing that topic or move

-    on.

- 

- Post meeting

- ============

- 

- 1. When #endmeeting runs it displays links for the logs. Use the .txt

-    and then .log.txt files in your email created above. Send out right

-    after meeting. (If you wait, it's very easy to forget).

- 

- 2. Process through tickets comment/close them as appropriate.

- 

@@ -1,29 +0,0 @@ 

- Simplified BSD License

- ======================

- 

- *Copyright © `<YEAR>`, `<OWNER>*

- *All rights reserved.*

- 

- Redistribution and use in source and binary forms, with or without

- modification, are permitted provided that the following conditions are met: 

- 

- 1. Redistributions of source code must retain the above copyright notice, this

-    list of conditions and the following disclaimer. 

- 2. Redistributions in binary form must reproduce the above copyright notice,

-    this list of conditions and the following disclaimer in the documentation

-    and/or other materials provided with the distribution. 

- 

- THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND

- ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED

- WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE

- DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR

- ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES

- (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;

- LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND

- ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT

- (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS

- SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

- 

- The views and conclusions contained in the software and documentation are those

- of the authors and should not be interpreted as representing official policies, 

- either expressed or implied, of the FreeBSD Project.

@@ -1,340 +0,0 @@ 

- GNU General Public License

- ==========================

- 

- *Version 2, June 1991*

- *Copyright © 1989, 1991 Free Software Foundation, Inc.*

- *51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA*

- 

- Everyone is permitted to copy and distribute verbatim copies

- of this license document, but changing it is not allowed.

- 

- Preamble

- ~~~~~~~~

- 

- The licenses for most software are designed to take away your

- freedom to share and change it.  By contrast, the GNU General Public

- License is intended to guarantee your freedom to share and change free

- software--to make sure the software is free for all its users.  This

- General Public License applies to most of the Free Software

- Foundation's software and to any other program whose authors commit to

- using it.  (Some other Free Software Foundation software is covered by

- the GNU Lesser General Public License instead.)  You can apply it to

- your programs, too.

- 

- When we speak of free software, we are referring to freedom, not

- price.  Our General Public Licenses are designed to make sure that you

- have the freedom to distribute copies of free software (and charge for

- this service if you wish), that you receive source code or can get it

- if you want it, that you can change the software or use pieces of it

- in new free programs; and that you know you can do these things.

- 

- To protect your rights, we need to make restrictions that forbid

- anyone to deny you these rights or to ask you to surrender the rights.

- These restrictions translate to certain responsibilities for you if you

- distribute copies of the software, or if you modify it.

- 

- For example, if you distribute copies of such a program, whether

- gratis or for a fee, you must give the recipients all the rights that

- you have.  You must make sure that they, too, receive or can get the

- source code.  And you must show them these terms so they know their

- rights.

- 

- We protect your rights with two steps: **(1)** copyright the software, and

- **(2)** offer you this license which gives you legal permission to copy,

- distribute and/or modify the software.

- 

- Also, for each author's protection and ours, we want to make certain

- that everyone understands that there is no warranty for this free

- software.  If the software is modified by someone else and passed on, we

- want its recipients to know that what they have is not the original, so

- that any problems introduced by others will not reflect on the original

- authors' reputations.

- 

- Finally, any free program is threatened constantly by software

- patents.  We wish to avoid the danger that redistributors of a free

- program will individually obtain patent licenses, in effect making the

- program proprietary.  To prevent this, we have made it clear that any

- patent must be licensed for everyone's free use or not licensed at all.

- 

- The precise terms and conditions for copying, distribution and

- modification follow.

- 

- TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION

- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

- 

- **0.** This License applies to any program or other work which contains

- a notice placed by the copyright holder saying it may be distributed

- under the terms of this General Public License.  The "Program", below,

- refers to any such program or work, and a "work based on the Program"

- means either the Program or any derivative work under copyright law:

- that is to say, a work containing the Program or a portion of it,

- either verbatim or with modifications and/or translated into another

- language.  (Hereinafter, translation is included without limitation in

- the term "modification".)  Each licensee is addressed as "you".

- 

- Activities other than copying, distribution and modification are not

- covered by this License; they are outside its scope.  The act of

- running the Program is not restricted, and the output from the Program

- is covered only if its contents constitute a work based on the

- Program (independent of having been made by running the Program).

- Whether that is true depends on what the Program does.

- 

- **1.** You may copy and distribute verbatim copies of the Program's

- source code as you receive it, in any medium, provided that you

- conspicuously and appropriately publish on each copy an appropriate

- copyright notice and disclaimer of warranty; keep intact all the

- notices that refer to this License and to the absence of any warranty;

- and give any other recipients of the Program a copy of this License

- along with the Program.

- 

- You may charge a fee for the physical act of transferring a copy, and

- you may at your option offer warranty protection in exchange for a fee.

- 

- **2.** You may modify your copy or copies of the Program or any portion

- of it, thus forming a work based on the Program, and copy and

- distribute such modifications or work under the terms of Section 1

- above, provided that you also meet all of these conditions:

- 

- * **a)** You must cause the modified files to carry prominent notices

-   stating that you changed the files and the date of any change.

- * **b)** You must cause any work that you distribute or publish, that in

-   whole or in part contains or is derived from the Program or any

-   part thereof, to be licensed as a whole at no charge to all third

-   parties under the terms of this License.

- * **c)** If the modified program normally reads commands interactively

-   when run, you must cause it, when started running for such

-   interactive use in the most ordinary way, to print or display an

-   announcement including an appropriate copyright notice and a

-   notice that there is no warranty (or else, saying that you provide

-   a warranty) and that users may redistribute the program under

-   these conditions, and telling the user how to view a copy of this

-   License.  (Exception: if the Program itself is interactive but

-   does not normally print such an announcement, your work based on

-   the Program is not required to print an announcement.)

- 

- These requirements apply to the modified work as a whole.  If

- identifiable sections of that work are not derived from the Program,

- and can be reasonably considered independent and separate works in

- themselves, then this License, and its terms, do not apply to those

- sections when you distribute them as separate works.  But when you

- distribute the same sections as part of a whole which is a work based

- on the Program, the distribution of the whole must be on the terms of

- this License, whose permissions for other licensees extend to the

- entire whole, and thus to each and every part regardless of who wrote it.

- 

- Thus, it is not the intent of this section to claim rights or contest

- your rights to work written entirely by you; rather, the intent is to

- exercise the right to control the distribution of derivative or

- collective works based on the Program.

- 

- In addition, mere aggregation of another work not based on the Program

- with the Program (or with a work based on the Program) on a volume of

- a storage or distribution medium does not bring the other work under

- the scope of this License.

- 

- **3.** You may copy and distribute the Program (or a work based on it,

- under Section 2) in object code or executable form under the terms of

- Sections 1 and 2 above provided that you also do one of the following:

- 

- * **a)** Accompany it with the complete corresponding machine-readable

-   source code, which must be distributed under the terms of Sections

-   1 and 2 above on a medium customarily used for software interchange; or,

- * **b)** Accompany it with a written offer, valid for at least three

-   years, to give any third party, for a charge no more than your

-   cost of physically performing source distribution, a complete

-   machine-readable copy of the corresponding source code, to be

-   distributed under the terms of Sections 1 and 2 above on a medium

-   customarily used for software interchange; or,

- * **c)** Accompany it with the information you received as to the offer

-   to distribute corresponding source code.  (This alternative is

-   allowed only for noncommercial distribution and only if you

-   received the program in object code or executable form with such

-   an offer, in accord with Subsection b above.)

- 

- The source code for a work means the preferred form of the work for

- making modifications to it.  For an executable work, complete source

- code means all the source code for all modules it contains, plus any

- associated interface definition files, plus the scripts used to

- control compilation and installation of the executable.  However, as a

- special exception, the source code distributed need not include

- anything that is normally distributed (in either source or binary

- form) with the major components (compiler, kernel, and so on) of the

- operating system on which the executable runs, unless that component

- itself accompanies the executable.

- 

- If distribution of executable or object code is made by offering

- access to copy from a designated place, then offering equivalent

- access to copy the source code from the same place counts as

- distribution of the source code, even though third parties are not

- compelled to copy the source along with the object code.

- 

- **4.** You may not copy, modify, sublicense, or distribute the Program

- except as expressly provided under this License.  Any attempt

- otherwise to copy, modify, sublicense or distribute the Program is

- void, and will automatically terminate your rights under this License.

- However, parties who have received copies, or rights, from you under

- this License will not have their licenses terminated so long as such

- parties remain in full compliance.

- 

- **5.** You are not required to accept this License, since you have not

- signed it.  However, nothing else grants you permission to modify or

- distribute the Program or its derivative works.  These actions are

- prohibited by law if you do not accept this License.  Therefore, by

- modifying or distributing the Program (or any work based on the

- Program), you indicate your acceptance of this License to do so, and

- all its terms and conditions for copying, distributing or modifying

- the Program or works based on it.

- 

- **6.** Each time you redistribute the Program (or any work based on the

- Program), the recipient automatically receives a license from the

- original licensor to copy, distribute or modify the Program subject to

- these terms and conditions.  You may not impose any further

- restrictions on the recipients' exercise of the rights granted herein.

- You are not responsible for enforcing compliance by third parties to

- this License.

- 

- **7.** If, as a consequence of a court judgment or allegation of patent

- infringement or for any other reason (not limited to patent issues),

- conditions are imposed on you (whether by court order, agreement or

- otherwise) that contradict the conditions of this License, they do not

- excuse you from the conditions of this License.  If you cannot

- distribute so as to satisfy simultaneously your obligations under this

- License and any other pertinent obligations, then as a consequence you

- may not distribute the Program at all.  For example, if a patent

- license would not permit royalty-free redistribution of the Program by

- all those who receive copies directly or indirectly through you, then

- the only way you could satisfy both it and this License would be to

- refrain entirely from distribution of the Program.

- 

- If any portion of this section is held invalid or unenforceable under

- any particular circumstance, the balance of the section is intended to

- apply and the section as a whole is intended to apply in other

- circumstances.

- 

- It is not the purpose of this section to induce you to infringe any

- patents or other property right claims or to contest validity of any

- such claims; this section has the sole purpose of protecting the

- integrity of the free software distribution system, which is

- implemented by public license practices.  Many people have made

- generous contributions to the wide range of software distributed

- through that system in reliance on consistent application of that

- system; it is up to the author/donor to decide if he or she is willing

- to distribute software through any other system and a licensee cannot

- impose that choice.

- 

- This section is intended to make thoroughly clear what is believed to

- be a consequence of the rest of this License.

- 

- **8.** If the distribution and/or use of the Program is restricted in

- certain countries either by patents or by copyrighted interfaces, the

- original copyright holder who places the Program under this License

- may add an explicit geographical distribution limitation excluding

- those countries, so that distribution is permitted only in or among

- countries not thus excluded.  In such case, this License incorporates

- the limitation as if written in the body of this License.

- 

- **9.** The Free Software Foundation may publish revised and/or new versions

- of the General Public License from time to time.  Such new versions will

- be similar in spirit to the present version, but may differ in detail to

- address new problems or concerns.

- 

- Each version is given a distinguishing version number.  If the Program

- specifies a version number of this License which applies to it and "any

- later version", you have the option of following the terms and conditions

- either of that version or of any later version published by the Free

- Software Foundation.  If the Program does not specify a version number of

- this License, you may choose any version ever published by the Free Software

- Foundation.

- 

- **10.** If you wish to incorporate parts of the Program into other free

- programs whose distribution conditions are different, write to the author

- to ask for permission.  For software which is copyrighted by the Free

- Software Foundation, write to the Free Software Foundation; we sometimes

- make exceptions for this.  Our decision will be guided by the two goals

- of preserving the free status of all derivatives of our free software and

- of promoting the sharing and reuse of software generally.

- 

- NO WARRANTY

- ~~~~~~~~~~~

- 

- **11.** BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY

- FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW.  EXCEPT WHEN

- OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES

- PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED

- OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF

- MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.  THE ENTIRE RISK AS

- TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU.  SHOULD THE

- PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,

- REPAIR OR CORRECTION.

- 

- **12.** IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING

- WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR

- REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,

- INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING

- OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED

- TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY

- YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER

- PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE

- POSSIBILITY OF SUCH DAMAGES.

- 

- *END OF TERMS AND CONDITIONS*

- 

- How to Apply These Terms to Your New Programs

- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

- 

- If you develop a new program, and you want it to be of the greatest

- possible use to the public, the best way to achieve this is to make it

- free software which everyone can redistribute and change under these terms.

- 

- To do so, attach the following notices to the program.  It is safest

- to attach them to the start of each source file to most effectively

- convey the exclusion of warranty; and each file should have at least

- the "copyright" line and a pointer to where the full notice is found.

- 

-     <one line to give the program's name and a brief idea of what it does.>

-     Copyright (C) <year>  <name of author>

-     

-     This program is free software; you can redistribute it and/or modify

-     it under the terms of the GNU General Public License as published by

-     the Free Software Foundation; either version 2 of the License, or

-     (at your option) any later version.

-     

-     This program is distributed in the hope that it will be useful,

-     but WITHOUT ANY WARRANTY; without even the implied warranty of

-     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the

-     GNU General Public License for more details.

-     

-     You should have received a copy of the GNU General Public License along

-     with this program; if not, write to the Free Software Foundation, Inc.,

-     51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.

- 

- Also add information on how to contact you by electronic and paper mail.

- 

- If the program is interactive, make it output a short notice like this

- when it starts in an interactive mode:

- 

-     Gnomovision version 69, Copyright (C) year name of author

-     Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'.

-     This is free software, and you are welcome to redistribute it

-     under certain conditions; type `show c' for details.

- 

- The hypothetical commands `show w` and `show c` should show the appropriate

- parts of the General Public License.  Of course, the commands you use may

- be called something other than `show w' and `show c`; they could even be

- mouse-clicks or menu items--whatever suits your program.

- 

- You should also get your employer (if you work as a programmer) or your

- school, if any, to sign a "copyright disclaimer" for the program, if

- necessary.  Here is a sample; alter the names:

- 

-     Yoyodyne, Inc., hereby disclaims all copyright interest in the program

-     `Gnomovision' (which makes passes at compilers) written by James Hacker.

-     

-     <signature of Ty Coon>, 1 April 1989

-     Ty Coon, President of Vice

- 

- This General Public License does not permit incorporating your program into

- proprietary programs.  If your program is a subroutine library, you may

- consider it more useful to permit linking proprietary applications with the

- library.  If this is what you want to do, use the GNU Lesser General

- Public License instead of this License.

@@ -1,616 +0,0 @@ 

- GNU General Public License

- ==========================

- 

- *Version 3, 29 June 2007*

- *Copyright © 2007 Free Software Foundation, Inc* <http://fsf.org>

- 

- Everyone is permitted to copy and distribute verbatim copies of this license

- document, but changing it is not allowed.

- 

- Preamble

- --------

- 

- The GNU General Public License is a free, copyleft license for software and other

- kinds of works.

- 

- The licenses for most software and other practical works are designed to take away

- your freedom to share and change the works. By contrast, the GNU General Public

- License is intended to guarantee your freedom to share and change all versions of a

- program--to make sure it remains free software for all its users. We, the Free

- Software Foundation, use the GNU General Public License for most of our software; it

- applies also to any other work released this way by its authors. You can apply it to

- your programs, too.

- 

- When we speak of free software, we are referring to freedom, not price. Our General

- Public Licenses are designed to make sure that you have the freedom to distribute

- copies of free software (and charge for them if you wish), that you receive source

- code or can get it if you want it, that you can change the software or use pieces of

- it in new free programs, and that you know you can do these things.

- 

- To protect your rights, we need to prevent others from denying you these rights or

- asking you to surrender the rights. Therefore, you have certain responsibilities if

- you distribute copies of the software, or if you modify it: responsibilities to

- respect the freedom of others.

- 

- For example, if you distribute copies of such a program, whether gratis or for a fee,

- you must pass on to the recipients the same freedoms that you received. You must make

- sure that they, too, receive or can get the source code. And you must show them these

- terms so they know their rights.

- 

- Developers that use the GNU GPL protect your rights with two steps: **(1)** assert

- copyright on the software, and **(2)** offer you this License giving you legal permission

- to copy, distribute and/or modify it.

- 

- For the developers' and authors' protection, the GPL clearly explains that there is

- no warranty for this free software. For both users' and authors' sake, the GPL

- requires that modified versions be marked as changed, so that their problems will not

- be attributed erroneously to authors of previous versions.

- 

- Some devices are designed to deny users access to install or run modified versions of

- the software inside them, although the manufacturer can do so. This is fundamentally

- incompatible with the aim of protecting users' freedom to change the software. The

- systematic pattern of such abuse occurs in the area of products for individuals to

- use, which is precisely where it is most unacceptable. Therefore, we have designed

- this version of the GPL to prohibit the practice for those products. If such problems

- arise substantially in other domains, we stand ready to extend this provision to

- those domains in future versions of the GPL, as needed to protect the freedom of

- users.

- 

- Finally, every program is threatened constantly by software patents. States should

- not allow patents to restrict development and use of software on general-purpose

- computers, but in those that do, we wish to avoid the special danger that patents

- applied to a free program could make it effectively proprietary. To prevent this, the

- GPL assures that patents cannot be used to render the program non-free.

- 

- The precise terms and conditions for copying, distribution and modification follow.

- 

- TERMS AND CONDITIONS

- --------------------

- 

- 0. Definitions

- ~~~~~~~~~~~~~~

- 

- "This License" refers to version 3 of the GNU General Public License.

- 

- "Copyright" also means copyright-like laws that apply to other kinds of

- works, such as semiconductor masks.

- 

- "The Program" refers to any copyrightable work licensed under this

- License. Each licensee is addressed as "you". "Licensees" and

- "recipients" may be individuals or organizations.

- 

- To "modify" a work means to copy from or adapt all or part of the work in

- a fashion requiring copyright permission, other than the making of an exact copy. The

- resulting work is called a "modified version" of the earlier work or a

- work "based on" the earlier work.

- 

- A "covered work" means either the unmodified Program or a work based on

- the Program.

- 

- To "propagate" a work means to do anything with it that, without

- permission, would make you directly or secondarily liable for infringement under

- applicable copyright law, except executing it on a computer or modifying a private

- copy. Propagation includes copying, distribution (with or without modification),

- making available to the public, and in some countries other activities as well.

- 

- To "convey" a work means any kind of propagation that enables other

- parties to make or receive copies. Mere interaction with a user through a computer

- network, with no transfer of a copy, is not conveying.

- 

- An interactive user interface displays "Appropriate Legal Notices" to the

- extent that it includes a convenient and prominently visible feature that **(1)**

- displays an appropriate copyright notice, and **(2)** tells the user that there is no

- warranty for the work (except to the extent that warranties are provided), that

- licensees may convey the work under this License, and how to view a copy of this

- License. If the interface presents a list of user commands or options, such as a

- menu, a prominent item in the list meets this criterion.

- 

- 1. Source Code

- ~~~~~~~~~~~~~~

- 

- The "source code" for a work means the preferred form of the work for

- making modifications to it. "Object code" means any non-source form of a

- work.

- 

- A "Standard Interface" means an interface that either is an official

- standard defined by a recognized standards body, or, in the case of interfaces

- specified for a particular programming language, one that is widely used among

- developers working in that language.

- 

- The "System Libraries" of an executable work include anything, other than

- the work as a whole, that **(a)** is included in the normal form of packaging a Major

- Component, but which is not part of that Major Component, and **(b)** serves only to

- enable use of the work with that Major Component, or to implement a Standard

- Interface for which an implementation is available to the public in source code form.

- A "Major Component", in this context, means a major essential component

- (kernel, window system, and so on) of the specific operating system (if any) on which

- the executable work runs, or a compiler used to produce the work, or an object code

- interpreter used to run it.

- 

- The "Corresponding Source" for a work in object code form means all the

- source code needed to generate, install, and (for an executable work) run the object

- code and to modify the work, including scripts to control those activities. However,

- it does not include the work's System Libraries, or general-purpose tools or

- generally available free programs which are used unmodified in performing those

- activities but which are not part of the work. For example, Corresponding Source

- includes interface definition files associated with source files for the work, and

- the source code for shared libraries and dynamically linked subprograms that the work

- is specifically designed to require, such as by intimate data communication or

- control flow between those subprograms and other parts of the work.

- 

- The Corresponding Source need not include anything that users can regenerate

- automatically from other parts of the Corresponding Source.

- 

- The Corresponding Source for a work in source code form is that same work.

- 

- 2. Basic Permissions

- ~~~~~~~~~~~~~~~~~~~~

- 

- All rights granted under this License are granted for the term of copyright on the

- Program, and are irrevocable provided the stated conditions are met. This License

- explicitly affirms your unlimited permission to run the unmodified Program. The

- output from running a covered work is covered by this License only if the output,

- given its content, constitutes a covered work. This License acknowledges your rights

- of fair use or other equivalent, as provided by copyright law.

- 

- You may make, run and propagate covered works that you do not convey, without

- conditions so long as your license otherwise remains in force. You may convey covered

- works to others for the sole purpose of having them make modifications exclusively

- for you, or provide you with facilities for running those works, provided that you

- comply with the terms of this License in conveying all material for which you do not

- control copyright. Those thus making or running the covered works for you must do so

- exclusively on your behalf, under your direction and control, on terms that prohibit

- them from making any copies of your copyrighted material outside their relationship

- with you.

- 

- Conveying under any other circumstances is permitted solely under the conditions

- stated below. Sublicensing is not allowed; section 10 makes it unnecessary.

- 

- 3. Protecting Users' Legal Rights From Anti-Circumvention Law

- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

- 

- No covered work shall be deemed part of an effective technological measure under any

- applicable law fulfilling obligations under article 11 of the WIPO copyright treaty

- adopted on 20 December 1996, or similar laws prohibiting or restricting circumvention

- of such measures.

- 

- When you convey a covered work, you waive any legal power to forbid circumvention of

- technological measures to the extent such circumvention is effected by exercising

- rights under this License with respect to the covered work, and you disclaim any

- intention to limit operation or modification of the work as a means of enforcing,

- against the work's users, your or third parties' legal rights to forbid circumvention

- of technological measures.

- 

- 4. Conveying Verbatim Copies

- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~

- 

- You may convey verbatim copies of the Program's source code as you receive it, in any

- medium, provided that you conspicuously and appropriately publish on each copy an

- appropriate copyright notice; keep intact all notices stating that this License and

- any non-permissive terms added in accord with section 7 apply to the code; keep

- intact all notices of the absence of any warranty; and give all recipients a copy of

- this License along with the Program.

- 

- You may charge any price or no price for each copy that you convey, and you may offer

- support or warranty protection for a fee.

- 

- 5. Conveying Modified Source Versions

- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

- 

- You may convey a work based on the Program, or the modifications to produce it from

- the Program, in the form of source code under the terms of section 4, provided that

- you also meet all of these conditions:

- 

- * **a)** The work must carry prominent notices stating that you modified it, and giving a

-   relevant date.

- * **b)** The work must carry prominent notices stating that it is released under this

-   License and any conditions added under section 7. This requirement modifies the

-   requirement in section 4 to "keep intact all notices".

- * **c)** You must license the entire work, as a whole, under this License to anyone who

-   comes into possession of a copy. This License will therefore apply, along with any

-   applicable section 7 additional terms, to the whole of the work, and all its parts,

-   regardless of how they are packaged. This License gives no permission to license the

-   work in any other way, but it does not invalidate such permission if you have

-   separately received it.

- * **d)** If the work has interactive user interfaces, each must display Appropriate Legal

-   Notices; however, if the Program has interactive interfaces that do not display

-   Appropriate Legal Notices, your work need not make them do so.

- 

- A compilation of a covered work with other separate and independent works, which are

- not by their nature extensions of the covered work, and which are not combined with

- it such as to form a larger program, in or on a volume of a storage or distribution

- medium, is called an "aggregate" if the compilation and its resulting

- copyright are not used to limit the access or legal rights of the compilation's users

- beyond what the individual works permit. Inclusion of a covered work in an aggregate

- does not cause this License to apply to the other parts of the aggregate.

- 

- 6. Conveying Non-Source Forms

- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

- 

- You may convey a covered work in object code form under the terms of sections 4 and

- 5, provided that you also convey the machine-readable Corresponding Source under the

- terms of this License, in one of these ways:

- 

- * **a)** Convey the object code in, or embodied in, a physical product (including a

-   physical distribution medium), accompanied by the Corresponding Source fixed on a

-   durable physical medium customarily used for software interchange.

- * **b)** Convey the object code in, or embodied in, a physical product (including a

-   physical distribution medium), accompanied by a written offer, valid for at least

-   three years and valid for as long as you offer spare parts or customer support for

-   that product model, to give anyone who possesses the object code either **(1)** a copy of

-   the Corresponding Source for all the software in the product that is covered by this

-   License, on a durable physical medium customarily used for software interchange, for

-   a price no more than your reasonable cost of physically performing this conveying of

-   source, or **(2)** access to copy the Corresponding Source from a network server at no

-   charge.

- * **c)** Convey individual copies of the object code with a copy of the written offer to

-   provide the Corresponding Source. This alternative is allowed only occasionally and

-   noncommercially, and only if you received the object code with such an offer, in

-   accord with subsection 6b.

- * **d)** Convey the object code by offering access from a designated place (gratis or for

-   a charge), and offer equivalent access to the Corresponding Source in the same way

-   through the same place at no further charge. You need not require recipients to copy

-   the Corresponding Source along with the object code. If the place to copy the object

-   code is a network server, the Corresponding Source may be on a different server

-   (operated by you or a third party) that supports equivalent copying facilities,

-   provided you maintain clear directions next to the object code saying where to find

-   the Corresponding Source. Regardless of what server hosts the Corresponding Source,

-   you remain obligated to ensure that it is available for as long as needed to satisfy

-   these requirements.

- * **e)** Convey the object code using peer-to-peer transmission, provided you inform

-   other peers where the object code and Corresponding Source of the work are being

-   offered to the general public at no charge under subsection 6d.

- 

- A separable portion of the object code, whose source code is excluded from the

- Corresponding Source as a System Library, need not be included in conveying the

- object code work.

- 

- A "User Product" is either **(1)** a "consumer product", which

- means any tangible personal property which is normally used for personal, family, or

- household purposes, or **(2)** anything designed or sold for incorporation into a

- dwelling. In determining whether a product is a consumer product, doubtful cases

- shall be resolved in favor of coverage. For a particular product received by a

- particular user, "normally used" refers to a typical or common use of

- that class of product, regardless of the status of the particular user or of the way

- in which the particular user actually uses, or expects or is expected to use, the

- product. A product is a consumer product regardless of whether the product has

- substantial commercial, industrial or non-consumer uses, unless such uses represent

- the only significant mode of use of the product.

- 

- "Installation Information" for a User Product means any methods,

- procedures, authorization keys, or other information required to install and execute

- modified versions of a covered work in that User Product from a modified version of

- its Corresponding Source. The information must suffice to ensure that the continued

- functioning of the modified object code is in no case prevented or interfered with

- solely because modification has been made.

- 

- If you convey an object code work under this section in, or with, or specifically for

- use in, a User Product, and the conveying occurs as part of a transaction in which

- the right of possession and use of the User Product is transferred to the recipient

- in perpetuity or for a fixed term (regardless of how the transaction is

- characterized), the Corresponding Source conveyed under this section must be

- accompanied by the Installation Information. But this requirement does not apply if

- neither you nor any third party retains the ability to install modified object code

- on the User Product (for example, the work has been installed in ROM).

- 

- The requirement to provide Installation Information does not include a requirement to

- continue to provide support service, warranty, or updates for a work that has been

- modified or installed by the recipient, or for the User Product in which it has been

- modified or installed. Access to a network may be denied when the modification itself

- materially and adversely affects the operation of the network or violates the rules

- and protocols for communication across the network.

- 

- Corresponding Source conveyed, and Installation Information provided, in accord with

- this section must be in a format that is publicly documented (and with an

- implementation available to the public in source code form), and must require no

- special password or key for unpacking, reading or copying.

- 

- 7. Additional Terms

- ~~~~~~~~~~~~~~~~~~~

- 

- "Additional permissions" are terms that supplement the terms of this

- License by making exceptions from one or more of its conditions. Additional

- permissions that are applicable to the entire Program shall be treated as though they

- were included in this License, to the extent that they are valid under applicable

- law. If additional permissions apply only to part of the Program, that part may be

- used separately under those permissions, but the entire Program remains governed by

- this License without regard to the additional permissions.

- 

- When you convey a copy of a covered work, you may at your option remove any

- additional permissions from that copy, or from any part of it. (Additional

- permissions may be written to require their own removal in certain cases when you

- modify the work.) You may place additional permissions on material, added by you to a

- covered work, for which you have or can give appropriate copyright permission.

- 

- Notwithstanding any other provision of this License, for material you add to a

- covered work, you may (if authorized by the copyright holders of that material)

- supplement the terms of this License with terms:

- 

- * **a)** Disclaiming warranty or limiting liability differently from the terms of

-   sections 15 and 16 of this License; or

- * **b)** Requiring preservation of specified reasonable legal notices or author

-   attributions in that material or in the Appropriate Legal Notices displayed by works

-   containing it; or

- * **c)** Prohibiting misrepresentation of the origin of that material, or requiring that

-   modified versions of such material be marked in reasonable ways as different from the

-   original version; or

- * **d)** Limiting the use for publicity purposes of names of licensors or authors of the

-   material; or

- * **e)** Declining to grant rights under trademark law for use of some trade names,

-   trademarks, or service marks; or

- * **f)** Requiring indemnification of licensors and authors of that material by anyone

-   who conveys the material (or modified versions of it) with contractual assumptions of

-   liability to the recipient, for any liability that these contractual assumptions

-   directly impose on those licensors and authors.

- 

- All other non-permissive additional terms are considered "further

- restrictions" within the meaning of section 10. If the Program as you received

- it, or any part of it, contains a notice stating that it is governed by this License

- along with a term that is a further restriction, you may remove that term. If a

- license document contains a further restriction but permits relicensing or conveying

- under this License, you may add to a covered work material governed by the terms of

- that license document, provided that the further restriction does not survive such

- relicensing or conveying.

- 

- If you add terms to a covered work in accord with this section, you must place, in

- the relevant source files, a statement of the additional terms that apply to those

- files, or a notice indicating where to find the applicable terms.

- 

- Additional terms, permissive or non-permissive, may be stated in the form of a

- separately written license, or stated as exceptions; the above requirements apply

- either way.

- 

- 8. Termination

- ~~~~~~~~~~~~~~

- 

- You may not propagate or modify a covered work except as expressly provided under

- this License. Any attempt otherwise to propagate or modify it is void, and will

- automatically terminate your rights under this License (including any patent licenses

- granted under the third paragraph of section 11).

- 

- However, if you cease all violation of this License, then your license from a

- particular copyright holder is reinstated **(a)** provisionally, unless and until the

- copyright holder explicitly and finally terminates your license, and **(b)** permanently,

- if the copyright holder fails to notify you of the violation by some reasonable means

- prior to 60 days after the cessation.

- 

- Moreover, your license from a particular copyright holder is reinstated permanently

- if the copyright holder notifies you of the violation by some reasonable means, this

- is the first time you have received notice of violation of this License (for any

- work) from that copyright holder, and you cure the violation prior to 30 days after

- your receipt of the notice.

- 

- Termination of your rights under this section does not terminate the licenses of

- parties who have received copies or rights from you under this License. If your

- rights have been terminated and not permanently reinstated, you do not qualify to

- receive new licenses for the same material under section 10.

- 

- 9. Acceptance Not Required for Having Copies

- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

- 

- You are not required to accept this License in order to receive or run a copy of the

- Program. Ancillary propagation of a covered work occurring solely as a consequence of

- using peer-to-peer transmission to receive a copy likewise does not require

- acceptance. However, nothing other than this License grants you permission to

- propagate or modify any covered work. These actions infringe copyright if you do not

- accept this License. Therefore, by modifying or propagating a covered work, you

- indicate your acceptance of this License to do so.

- 

- 10. Automatic Licensing of Downstream Recipients

- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

- 

- Each time you convey a covered work, the recipient automatically receives a license

- from the original licensors, to run, modify and propagate that work, subject to this

- License. You are not responsible for enforcing compliance by third parties with this

- License.

- 

- An "entity transaction" is a transaction transferring control of an

- organization, or substantially all assets of one, or subdividing an organization, or

- merging organizations. If propagation of a covered work results from an entity

- transaction, each party to that transaction who receives a copy of the work also

- receives whatever licenses to the work the party's predecessor in interest had or

- could give under the previous paragraph, plus a right to possession of the

- Corresponding Source of the work from the predecessor in interest, if the predecessor

- has it or can get it with reasonable efforts.

- 

- You may not impose any further restrictions on the exercise of the rights granted or

- affirmed under this License. For example, you may not impose a license fee, royalty,

- or other charge for exercise of rights granted under this License, and you may not

- initiate litigation (including a cross-claim or counterclaim in a lawsuit) alleging

- that any patent claim is infringed by making, using, selling, offering for sale, or

- importing the Program or any portion of it.

- 

- 11. Patents

- ~~~~~~~~~~~

- 

- A "contributor" is a copyright holder who authorizes use under this

- License of the Program or a work on which the Program is based. The work thus

- licensed is called the contributor's "contributor version".

- 

- A contributor's "essential patent claims" are all patent claims owned or

- controlled by the contributor, whether already acquired or hereafter acquired, that

- would be infringed by some manner, permitted by this License, of making, using, or

- selling its contributor version, but do not include claims that would be infringed

- only as a consequence of further modification of the contributor version. For

- purposes of this definition, "control" includes the right to grant patent

- sublicenses in a manner consistent with the requirements of this License.

- 

- Each contributor grants you a non-exclusive, worldwide, royalty-free patent license

- under the contributor's essential patent claims, to make, use, sell, offer for sale,

- import and otherwise run, modify and propagate the contents of its contributor

- version.

- 

- In the following three paragraphs, a "patent license" is any express

- agreement or commitment, however denominated, not to enforce a patent (such as an

- express permission to practice a patent or covenant not to sue for patent

- infringement). To "grant" such a patent license to a party means to make

- such an agreement or commitment not to enforce a patent against the party.

- 

- If you convey a covered work, knowingly relying on a patent license, and the

- Corresponding Source of the work is not available for anyone to copy, free of charge

- and under the terms of this License, through a publicly available network server or

- other readily accessible means, then you must either **(1)** cause the Corresponding

- Source to be so available, or **(2)** arrange to deprive yourself of the benefit of the

- patent license for this particular work, or **(3)** arrange, in a manner consistent with

- the requirements of this License, to extend the patent license to downstream

- recipients. "Knowingly relying" means you have actual knowledge that, but

- for the patent license, your conveying the covered work in a country, or your

- recipient's use of the covered work in a country, would infringe one or more

- identifiable patents in that country that you have reason to believe are valid.

- 

- If, pursuant to or in connection with a single transaction or arrangement, you

- convey, or propagate by procuring conveyance of, a covered work, and grant a patent

- license to some of the parties receiving the covered work authorizing them to use,

- propagate, modify or convey a specific copy of the covered work, then the patent

- license you grant is automatically extended to all recipients of the covered work and

- works based on it.

- 

- A patent license is "discriminatory" if it does not include within the

- scope of its coverage, prohibits the exercise of, or is conditioned on the

- non-exercise of one or more of the rights that are specifically granted under this

- License. You may not convey a covered work if you are a party to an arrangement with

- a third party that is in the business of distributing software, under which you make

- payment to the third party based on the extent of your activity of conveying the

- work, and under which the third party grants, to any of the parties who would receive

- the covered work from you, a discriminatory patent license **(a)** in connection with

- copies of the covered work conveyed by you (or copies made from those copies), or **(b)**

- primarily for and in connection with specific products or compilations that contain

- the covered work, unless you entered into that arrangement, or that patent license

- was granted, prior to 28 March 2007.

- 

- Nothing in this License shall be construed as excluding or limiting any implied

- license or other defenses to infringement that may otherwise be available to you

- under applicable patent law.

- 

- 12. No Surrender of Others' Freedom

- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

- 

- If conditions are imposed on you (whether by court order, agreement or otherwise)

- that contradict the conditions of this License, they do not excuse you from the

- conditions of this License. If you cannot convey a covered work so as to satisfy

- simultaneously your obligations under this License and any other pertinent

- obligations, then as a consequence you may not convey it at all. For example, if you

- agree to terms that obligate you to collect a royalty for further conveying from

- those to whom you convey the Program, the only way you could satisfy both those terms

- and this License would be to refrain entirely from conveying the Program.

- 

- 13. Use with the GNU Affero General Public License

- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

- 

- Notwithstanding any other provision of this License, you have permission to link or

- combine any covered work with a work licensed under version 3 of the GNU Affero

- General Public License into a single combined work, and to convey the resulting work.

- The terms of this License will continue to apply to the part which is the covered

- work, but the special requirements of the GNU Affero General Public License, section

- 13, concerning interaction through a network will apply to the combination as such.

- 

- 14. Revised Versions of this License

- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

- 

- The Free Software Foundation may publish revised and/or new versions of the GNU

- General Public License from time to time. Such new versions will be similar in spirit

- to the present version, but may differ in detail to address new problems or concerns.

- 

- Each version is given a distinguishing version number. If the Program specifies that

- a certain numbered version of the GNU General Public License "or any later

- version" applies to it, you have the option of following the terms and

- conditions either of that numbered version or of any later version published by the

- Free Software Foundation. If the Program does not specify a version number of the GNU

- General Public License, you may choose any version ever published by the Free

- Software Foundation.

- 

- If the Program specifies that a proxy can decide which future versions of the GNU

- General Public License can be used, that proxy's public statement of acceptance of a

- version permanently authorizes you to choose that version for the Program.

- 

- Later license versions may give you additional or different permissions. However, no

- additional obligations are imposed on any author or copyright holder as a result of

- your choosing to follow a later version.

- 

- 15. Disclaimer of Warranty

- ~~~~~~~~~~~~~~~~~~~~~~~~~~

- 

- THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW.

- EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES

- PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER

- EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF

- MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE

- QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE

- DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.

- 

- 16. Limitation of Liability

- ~~~~~~~~~~~~~~~~~~~~~~~~~~~

- 

- IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY

- COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS THE PROGRAM AS

- PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL,

- INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE

- PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE

- OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE

- WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE

- POSSIBILITY OF SUCH DAMAGES.

- 

- 17. Interpretation of Sections 15 and 16

- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

- 

- If the disclaimer of warranty and limitation of liability provided above cannot be

- given local legal effect according to their terms, reviewing courts shall apply local

- law that most closely approximates an absolute waiver of all civil liability in

- connection with the Program, unless a warranty or assumption of liability accompanies

- a copy of the Program in return for a fee.

- 

- *END OF TERMS AND CONDITIONS*

- 

- How to Apply These Terms to Your New Programs

- ---------------------------------------------

- 

- If you develop a new program, and you want it to be of the greatest possible use to

- the public, the best way to achieve this is to make it free software which everyone

- can redistribute and change under these terms.

- 

- To do so, attach the following notices to the program. It is safest to attach them

- to the start of each source file to most effectively state the exclusion of warranty;

- and each file should have at least the "copyright" line and a pointer to

- where the full notice is found.

- 

-     <one line to give the program's name and a brief idea of what it does.>

-     Copyright (C) <year>  <name of author>

- 

-     This program is free software: you can redistribute it and/or modify

-     it under the terms of the GNU General Public License as published by

-     the Free Software Foundation, either version 3 of the License, or

-     (at your option) any later version.

- 

-     This program is distributed in the hope that it will be useful,

-     but WITHOUT ANY WARRANTY; without even the implied warranty of

-     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the

-     GNU General Public License for more details.

- 

-     You should have received a copy of the GNU General Public License

-     along with this program.  If not, see <http://www.gnu.org/licenses/>.

- 

- Also add information on how to contact you by electronic and paper mail.

- 

- If the program does terminal interaction, make it output a short notice like this

- when it starts in an interactive mode:

- 

-     <program>  Copyright (C) <year>  <name of author>

-     This program comes with ABSOLUTELY NO WARRANTY; for details type 'show w'.

-     This is free software, and you are welcome to redistribute it

-     under certain conditions; type 'show c' for details.

- 

- The hypothetical commands `show w` and `show c` should show the appropriate parts of

- the General Public License. Of course, your program's commands might be different;

- for a GUI interface, you would use an "about box".

- 

- You should also get your employer (if you work as a programmer) or school, if any, to

- sign a "copyright disclaimer" for the program, if necessary. For more

- information on this, and how to apply and follow the GNU GPL, see

- <http://www.gnu.org/licenses/>.

- 

- The GNU General Public License does not permit incorporating your program into

- proprietary programs. If your program is a subroutine library, you may consider it

- more useful to permit linking proprietary applications with the library. If this is

- what you want to do, use the GNU Lesser General Public License instead of this

- License. But first, please read

- <http://www.gnu.org/philosophy/why-not-lgpl.html>.

@@ -1,500 +0,0 @@ 

- GNU Lesser General Public License

- =================================

- 

- *Version 2.1, February 1999*

- *Copyright © 1991, 1999 Free Software Foundation, Inc*

- *51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA*

- 

- Everyone is permitted to copy and distribute verbatim copies

- of this license document, but changing it is not allowed.

- 

- *This is the first released version of the Lesser GPL.  It also counts

- as the successor of the GNU Library Public License, version 2, hence

- the version number 2.1.*

- 

- Preamble

- ~~~~~~~~

- 

- The licenses for most software are designed to take away your

- freedom to share and change it.  By contrast, the GNU General Public

- Licenses are intended to guarantee your freedom to share and change

- free software--to make sure the software is free for all its users.

- 

- This license, the Lesser General Public License, applies to some

- specially designated software packages--typically libraries--of the

- Free Software Foundation and other authors who decide to use it.  You

- can use it too, but we suggest you first think carefully about whether

- this license or the ordinary General Public License is the better

- strategy to use in any particular case, based on the explanations below.

- 

- When we speak of free software, we are referring to freedom of use,

- not price.  Our General Public Licenses are designed to make sure that

- you have the freedom to distribute copies of free software (and charge

- for this service if you wish); that you receive source code or can get

- it if you want it; that you can change the software and use pieces of

- it in new free programs; and that you are informed that you can do

- these things.

- 

- To protect your rights, we need to make restrictions that forbid

- distributors to deny you these rights or to ask you to surrender these

- rights.  These restrictions translate to certain responsibilities for

- you if you distribute copies of the library or if you modify it.

- 

- For example, if you distribute copies of the library, whether gratis

- or for a fee, you must give the recipients all the rights that we gave

- you.  You must make sure that they, too, receive or can get the source

- code.  If you link other code with the library, you must provide

- complete object files to the recipients, so that they can relink them

- with the library after making changes to the library and recompiling

- it.  And you must show them these terms so they know their rights.

- 

- We protect your rights with a two-step method: **(1)** we copyright the

- library, and **(2)** we offer you this license, which gives you legal

- permission to copy, distribute and/or modify the library.

- 

- To protect each distributor, we want to make it very clear that

- there is no warranty for the free library.  Also, if the library is

- modified by someone else and passed on, the recipients should know

- that what they have is not the original version, so that the original

- author's reputation will not be affected by problems that might be

- introduced by others.

- 

- Finally, software patents pose a constant threat to the existence of

- any free program.  We wish to make sure that a company cannot

- effectively restrict the users of a free program by obtaining a

- restrictive license from a patent holder.  Therefore, we insist that

- any patent license obtained for a version of the library must be

- consistent with the full freedom of use specified in this license.

- 

- Most GNU software, including some libraries, is covered by the

- ordinary GNU General Public License.  This license, the GNU Lesser

- General Public License, applies to certain designated libraries, and

- is quite different from the ordinary General Public License.  We use

- this license for certain libraries in order to permit linking those

- libraries into non-free programs.

- 

- When a program is linked with a library, whether statically or using

- a shared library, the combination of the two is legally speaking a

- combined work, a derivative of the original library.  The ordinary

- General Public License therefore permits such linking only if the

- entire combination fits its criteria of freedom.  The Lesser General

- Public License permits more lax criteria for linking other code with

- the library.

- 

- We call this license the "Lesser" General Public License because it

- does Less to protect the user's freedom than the ordinary General

- Public License.  It also provides other free software developers Less

- of an advantage over competing non-free programs.  These disadvantages

- are the reason we use the ordinary General Public License for many

- libraries.  However, the Lesser license provides advantages in certain

- special circumstances.

- 

- For example, on rare occasions, there may be a special need to

- encourage the widest possible use of a certain library, so that it becomes

- a de-facto standard.  To achieve this, non-free programs must be

- allowed to use the library.  A more frequent case is that a free

- library does the same job as widely used non-free libraries.  In this

- case, there is little to gain by limiting the free library to free

- software only, so we use the Lesser General Public License.

- 

- In other cases, permission to use a particular library in non-free

- programs enables a greater number of people to use a large body of

- free software.  For example, permission to use the GNU C Library in

- non-free programs enables many more people to use the whole GNU

- operating system, as well as its variant, the GNU/Linux operating

- system.

- 

- Although the Lesser General Public License is Less protective of the

- users' freedom, it does ensure that the user of a program that is

- linked with the Library has the freedom and the wherewithal to run

- that program using a modified version of the Library.

- 

- The precise terms and conditions for copying, distribution and

- modification follow.  Pay close attention to the difference between a

- "work based on the library" and a "work that uses the library".  The

- former contains code derived from the library, whereas the latter must

- be combined with the library in order to run.

- 

- TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION

- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

- 

- **0.** This License Agreement applies to any software library or other

- program which contains a notice placed by the copyright holder or

- other authorized party saying it may be distributed under the terms of

- this Lesser General Public License (also called "this License").

- Each licensee is addressed as "you"�

- 

- A "library" means a collection of software functions and/or data

- prepared so as to be conveniently linked with application programs

- (which use some of those functions and data) to form executables.

- 

- The "Library", below, refers to any such software library or work

- which has been distributed under these terms.  A "work based on the

- Library" means either the Library or any derivative work under

- copyright law: that is to say, a work containing the Library or a

- portion of it, either verbatim or with modifications and/or translated

- straightforwardly into another language.  (Hereinafter, translation is

- included without limitation in the term "modification".)

- 

- "Source code" for a work means the preferred form of the work for

- making modifications to it.  For a library, complete source code means

- all the source code for all modules it contains, plus any associated

- interface definition files, plus the scripts used to control compilation

- and installation of the library.

- 

- Activities other than copying, distribution and modification are not

- covered by this License; they are outside its scope.  The act of

- running a program using the Library is not restricted, and output from

- such a program is covered only if its contents constitute a work based

- on the Library (independent of the use of the Library in a tool for

- writing it).  Whether that is true depends on what the Library does

- and what the program that uses the Library does.

- 

- **1.** You may copy and distribute verbatim copies of the Library's

- complete source code as you receive it, in any medium, provided that

- you conspicuously and appropriately publish on each copy an

- appropriate copyright notice and disclaimer of warranty; keep intact

- all the notices that refer to this License and to the absence of any

- warranty; and distribute a copy of this License along with the

- Library.

- 

- You may charge a fee for the physical act of transferring a copy,

- and you may at your option offer warranty protection in exchange for a

- fee.

- 

- **2.** You may modify your copy or copies of the Library or any portion

- of it, thus forming a work based on the Library, and copy and

- distribute such modifications or work under the terms of Section 1

- above, provided that you also meet all of these conditions:

- 

- * **a)** The modified work must itself be a software library.

- * **b)** You must cause the files modified to carry prominent notices

-   stating that you changed the files and the date of any change.

- * **c)** You must cause the whole of the work to be licensed at no

-   charge to all third parties under the terms of this License.

- * **d)** If a facility in the modified Library refers to a function or a

-   table of data to be supplied by an application program that uses

-   the facility, other than as an argument passed when the facility

-   is invoked, then you must make a good faith effort to ensure that,

-   in the event an application does not supply such function or

-   table, the facility still operates, and performs whatever part of

-   its purpose remains meaningful.  

- 

- (For example, a function in a library to compute square roots has

- a purpose that is entirely well-defined independent of the

- application.  Therefore, Subsection 2d requires that any

- application-supplied function or table used by this function must

- be optional: if the application does not supply it, the square

- root function must still compute square roots.)

- 

- These requirements apply to the modified work as a whole.  If

- identifiable sections of that work are not derived from the Library,

- and can be reasonably considered independent and separate works in

- themselves, then this License, and its terms, do not apply to those

- sections when you distribute them as separate works.  But when you

- distribute the same sections as part of a whole which is a work based

- on the Library, the distribution of the whole must be on the terms of

- this License, whose permissions for other licensees extend to the

- entire whole, and thus to each and every part regardless of who wrote

- it.

- 

- Thus, it is not the intent of this section to claim rights or contest

- your rights to work written entirely by you; rather, the intent is to

- exercise the right to control the distribution of derivative or

- collective works based on the Library.

- 

- In addition, mere aggregation of another work not based on the Library

- with the Library (or with a work based on the Library) on a volume of

- a storage or distribution medium does not bring the other work under

- the scope of this License.

- 

- **3.** You may opt to apply the terms of the ordinary GNU General Public

- License instead of this License to a given copy of the Library.  To do

- this, you must alter all the notices that refer to this License, so

- that they refer to the ordinary GNU General Public License, version 2,

- instead of to this License.  (If a newer version than version 2 of the

- ordinary GNU General Public License has appeared, then you can specify

- that version instead if you wish.)  Do not make any other change in

- these notices.

- 

- Once this change is made in a given copy, it is irreversible for

- that copy, so the ordinary GNU General Public License applies to all

- subsequent copies and derivative works made from that copy.

- 

- This option is useful when you wish to copy part of the code of

- the Library into a program that is not a library.

- 

- **4.** You may copy and distribute the Library (or a portion or

- derivative of it, under Section 2) in object code or executable form

- under the terms of Sections 1 and 2 above provided that you accompany

- it with the complete corresponding machine-readable source code, which

- must be distributed under the terms of Sections 1 and 2 above on a

- medium customarily used for software interchange.

- 

- If distribution of object code is made by offering access to copy

- from a designated place, then offering equivalent access to copy the

- source code from the same place satisfies the requirement to

- distribute the source code, even though third parties are not

- compelled to copy the source along with the object code.

- 

- **5.** A program that contains no derivative of any portion of the

- Library, but is designed to work with the Library by being compiled or

- linked with it, is called a "work that uses the Library".  Such a

- work, in isolation, is not a derivative work of the Library, and

- therefore falls outside the scope of this License.

- 

- However, linking a "work that uses the Library" with the Library

- creates an executable that is a derivative of the Library (because it

- contains portions of the Library), rather than a "work that uses the

- library".  The executable is therefore covered by this License.

- Section 6 states terms for distribution of such executables.

- 

- When a "work that uses the Library" uses material from a header file

- that is part of the Library, the object code for the work may be a

- derivative work of the Library even though the source code is not.

- Whether this is true is especially significant if the work can be

- linked without the Library, or if the work is itself a library.  The

- threshold for this to be true is not precisely defined by law.

- 

- If such an object file uses only numerical parameters, data

- structure layouts and accessors, and small macros and small inline

- functions (ten lines or less in length), then the use of the object

- file is unrestricted, regardless of whether it is legally a derivative

- work.  (Executables containing this object code plus portions of the

- Library will still fall under Section 6.)

- 

- Otherwise, if the work is a derivative of the Library, you may

- distribute the object code for the work under the terms of Section 6.

- Any executables containing that work also fall under Section 6,

- whether or not they are linked directly with the Library itself.

- 

- **6.** As an exception to the Sections above, you may also combine or

- link a "work that uses the Library" with the Library to produce a

- work containing portions of the Library, and distribute that work

- under terms of your choice, provided that the terms permit

- modification of the work for the customer's own use and reverse

- engineering for debugging such modifications.

- 

- You must give prominent notice with each copy of the work that the

- Library is used in it and that the Library and its use are covered by

- this License.  You must supply a copy of this License.  If the work

- during execution displays copyright notices, you must include the

- copyright notice for the Library among them, as well as a reference

- directing the user to the copy of this License.  Also, you must do one

- of these things:

- 

- * **a)** Accompany the work with the complete corresponding

- machine-readable source code for the Library including whatever

- changes were used in the work (which must be distributed under

- Sections 1 and 2 above); and, if the work is an executable linked

- with the Library, with the complete machine-readable "work that

- uses the Library", as object code and/or source code, so that the

- user can modify the Library and then relink to produce a modified

- executable containing the modified Library.  (It is understood

- that the user who changes the contents of definitions files in the

- Library will not necessarily be able to recompile the application

- to use the modified definitions.)

- * **b)** Use a suitable shared library mechanism for linking with the

- Library.  A suitable mechanism is one that (1) uses at run time a

- copy of the library already present on the user's computer system,

- rather than copying library functions into the executable, and (2)

- will operate properly with a modified version of the library, if

- the user installs one, as long as the modified version is

- interface-compatible with the version that the work was made with.

- 

- * **c)** Accompany the work with a written offer, valid for at

-   least three years, to give the same user the materials

-   specified in Subsection 6a, above, for a charge no more

-   than the cost of performing this distribution.

- * **d)** If distribution of the work is made by offering access to copy

-   from a designated place, offer equivalent access to copy the above

-   specified materials from the same place.

- * **e)** Verify that the user has already received a copy of these

-   materials or that you have already sent this user a copy.

- 

- For an executable, the required form of the "work that uses the

- Library" must include any data and utility programs needed for

- reproducing the executable from it.  However, as a special exception,

- the materials to be distributed need not include anything that is

- normally distributed (in either source or binary form) with the major

- components (compiler, kernel, and so on) of the operating system on

- which the executable runs, unless that component itself accompanies

- the executable.

- 

- It may happen that this requirement contradicts the license

- restrictions of other proprietary libraries that do not normally

- accompany the operating system.  Such a contradiction means you cannot

- use both them and the Library together in an executable that you

- distribute.

- 

- **7.** You may place library facilities that are a work based on the

- Library side-by-side in a single library together with other library

- facilities not covered by this License, and distribute such a combined

- library, provided that the separate distribution of the work based on

- the Library and of the other library facilities is otherwise

- permitted, and provided that you do these two things:

- 

- * **a)** Accompany the combined library with a copy of the same work

- based on the Library, uncombined with any other library

- facilities.  This must be distributed under the terms of the

- Sections above.

- * **b)** Give prominent notice with the combined library of the fact

- that part of it is a work based on the Library, and explaining

- where to find the accompanying uncombined form of the same work.

- 

- **8.** You may not copy, modify, sublicense, link with, or distribute

- the Library except as expressly provided under this License.  Any

- attempt otherwise to copy, modify, sublicense, link with, or

- distribute the Library is void, and will automatically terminate your

- rights under this License.  However, parties who have received copies,

- or rights, from you under this License will not have their licenses

- terminated so long as such parties remain in full compliance.

- 

- **9.** You are not required to accept this License, since you have not

- signed it.  However, nothing else grants you permission to modify or

- distribute the Library or its derivative works.  These actions are

- prohibited by law if you do not accept this License.  Therefore, by

- modifying or distributing the Library (or any work based on the

- Library), you indicate your acceptance of this License to do so, and

- all its terms and conditions for copying, distributing or modifying

- the Library or works based on it.

- 

- **10.** Each time you redistribute the Library (or any work based on the

- Library), the recipient automatically receives a license from the

- original licensor to copy, distribute, link with or modify the Library

- subject to these terms and conditions.  You may not impose any further

- restrictions on the recipients' exercise of the rights granted herein.

- You are not responsible for enforcing compliance by third parties with

- this License.

- 

- **11.** If, as a consequence of a court judgment or allegation of patent

- infringement or for any other reason (not limited to patent issues),

- conditions are imposed on you (whether by court order, agreement or

- otherwise) that contradict the conditions of this License, they do not

- excuse you from the conditions of this License.  If you cannot

- distribute so as to satisfy simultaneously your obligations under this

- License and any other pertinent obligations, then as a consequence you

- may not distribute the Library at all.  For example, if a patent

- license would not permit royalty-free redistribution of the Library by

- all those who receive copies directly or indirectly through you, then

- the only way you could satisfy both it and this License would be to

- refrain entirely from distribution of the Library.

- 

- If any portion of this section is held invalid or unenforceable under any

- particular circumstance, the balance of the section is intended to apply,

- and the section as a whole is intended to apply in other circumstances.

- 

- It is not the purpose of this section to induce you to infringe any

- patents or other property right claims or to contest validity of any

- such claims; this section has the sole purpose of protecting the

- integrity of the free software distribution system which is

- implemented by public license practices.  Many people have made

- generous contributions to the wide range of software distributed

- through that system in reliance on consistent application of that

- system; it is up to the author/donor to decide if he or she is willing

- to distribute software through any other system and a licensee cannot

- impose that choice.

- 

- This section is intended to make thoroughly clear what is believed to

- be a consequence of the rest of this License.

- 

- **12.** If the distribution and/or use of the Library is restricted in

- certain countries either by patents or by copyrighted interfaces, the

- original copyright holder who places the Library under this License may add

- an explicit geographical distribution limitation excluding those countries,

- so that distribution is permitted only in or among countries not thus

- excluded.  In such case, this License incorporates the limitation as if

- written in the body of this License.

- 

- **13.** The Free Software Foundation may publish revised and/or new

- versions of the Lesser General Public License from time to time.

- Such new versions will be similar in spirit to the present version,

- but may differ in detail to address new problems or concerns.

- 

- Each version is given a distinguishing version number.  If the Library

- specifies a version number of this License which applies to it and

- "any later version", you have the option of following the terms and

- conditions either of that version or of any later version published by

- the Free Software Foundation.  If the Library does not specify a

- license version number, you may choose any version ever published by

- the Free Software Foundation.

- 

- **14.** If you wish to incorporate parts of the Library into other free

- programs whose distribution conditions are incompatible with these,

- write to the author to ask for permission.  For software which is

- copyrighted by the Free Software Foundation, write to the Free

- Software Foundation; we sometimes make exceptions for this.  Our

- decision will be guided by the two goals of preserving the free status

- of all derivatives of our free software and of promoting the sharing

- and reuse of software generally.

- 

- NO WARRANTY

- ~~~~~~~~~~~

- 

- **15.** BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO

- WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW.

- EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR

- OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY

- KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE

- IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR

- PURPOSE.  THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE

- LIBRARY IS WITH YOU.  SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME

- THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.

- 

- **16.** IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN

- WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY

- AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU

- FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR

- CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE

- LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING

- RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A

- FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF

- SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH

- DAMAGES.

- 

- *END OF TERMS AND CONDITIONS*

- 

- How to Apply These Terms to Your New Libraries

- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

- 

- If you develop a new library, and you want it to be of the greatest

- possible use to the public, we recommend making it free software that

- everyone can redistribute and change.  You can do so by permitting

- redistribution under these terms (or, alternatively, under the terms of the

- ordinary General Public License).

- 

- To apply these terms, attach the following notices to the library.  It is

- safest to attach them to the start of each source file to most effectively

- convey the exclusion of warranty; and each file should have at least the

- "copyright" line and a pointer to where the full notice is found.

- 

-     <one line to give the library's name and a brief idea of what it does.>

-     Copyright (C) <year>  <name of author>

- 

-     This library is free software; you can redistribute it and/or

-     modify it under the terms of the GNU Lesser General Public

-     License as published by the Free Software Foundation; either

-     version 2.1 of the License, or (at your option) any later version.

- 

-     This library is distributed in the hope that it will be useful,

-     but WITHOUT ANY WARRANTY; without even the implied warranty of

-     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU

-     Lesser General Public License for more details.

- 

-     You should have received a copy of the GNU Lesser General Public

-     License along with this library; if not, write to the Free Software

-     Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA

- 

- Also add information on how to contact you by electronic and paper mail.

- 

- You should also get your employer (if you work as a programmer) or your

- school, if any, to sign a "copyright disclaimer" for the library, if

- necessary.  Here is a sample; alter the names:

- 

-     Yoyodyne, Inc., hereby disclaims all copyright interest in the

-     library `Frob' (a library for tweaking knobs) written by James Random Hacker.

- 

-     <signature of Ty Coon>, 1 April 1990

-     Ty Coon, President of Vice

- 

- That's all there is to it!

@@ -1,170 +0,0 @@ 

- GNU Lesser General Public License

- =================================

- 

- *Version 3, 29 June 2007*

- *Copyright © 2007 Free Software Foundation, Inc* <http://fsf.org/>

- 

- Everyone is permitted to copy and distribute verbatim copies

- of this license document, but changing it is not allowed.

- 

- 

- This version of the GNU Lesser General Public License incorporates

- the terms and conditions of version 3 of the GNU General Public

- License, supplemented by the additional permissions listed below.

- 

- 0. Additional Definitions

- ~~~~~~~~~~~~~~~~~~~~~~~~~

- 

- As used herein, "this License" refers to version 3 of the GNU Lesser

- General Public License, and the "GNU GPL" refers to version 3 of the GNU

- General Public License.

- 

- "The Library" refers to a covered work governed by this License,

- other than an Application or a Combined Work as defined below.

- 

- An "Application" is any work that makes use of an interface provided

- by the Library, but which is not otherwise based on the Library.

- Defining a subclass of a class defined by the Library is deemed a mode

- of using an interface provided by the Library.

- 

- A "Combined Work" is a work produced by combining or linking an

- Application with the Library.  The particular version of the Library

- with which the Combined Work was made is also called the "Linked

- Version".

- 

- The "Minimal Corresponding Source" for a Combined Work means the

- Corresponding Source for the Combined Work, excluding any source code

- for portions of the Combined Work that, considered in isolation, are

- based on the Application, and not on the Linked Version.

- 

- The "Corresponding Application Code" for a Combined Work means the

- object code and/or source code for the Application, including any data

- and utility programs needed for reproducing the Combined Work from the

- Application, but excluding the System Libraries of the Combined Work.

- 

- 1. Exception to Section 3 of the GNU GPL

- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

- 

- You may convey a covered work under sections 3 and 4 of this License

- without being bound by section 3 of the GNU GPL.

- 

- 2. Conveying Modified Versions

- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

- 

- If you modify a copy of the Library, and, in your modifications, a

- facility refers to a function or data to be supplied by an Application

- that uses the facility (other than as an argument passed when the

- facility is invoked), then you may convey a copy of the modified

- version:

- 

- * **a)** under this License, provided that you make a good faith effort to

- ensure that, in the event an Application does not supply the

- function or data, the facility still operates, and performs

- whatever part of its purpose remains meaningful, or

- 

- * **b)** under the GNU GPL, with none of the additional permissions of

- this License applicable to that copy.

- 

- ### 3. Object Code Incorporating Material from Library Header Files

- 

- The object code form of an Application may incorporate material from

- a header file that is part of the Library.  You may convey such object

- code under terms of your choice, provided that, if the incorporated

- material is not limited to numerical parameters, data structure

- layouts and accessors, or small macros, inline functions and templates

- (ten or fewer lines in length), you do both of the following:

- 

- * **a)** Give prominent notice with each copy of the object code that the

- Library is used in it and that the Library and its use are

- covered by this License.

- * **b)** Accompany the object code with a copy of the GNU GPL and this license

- document.

- 

- 4. Combined Works

- ~~~~~~~~~~~~~~~~~

- 

- You may convey a Combined Work under terms of your choice that,

- taken together, effectively do not restrict modification of the

- portions of the Library contained in the Combined Work and reverse

- engineering for debugging such modifications, if you also do each of

- the following:

- 

- * **a)** Give prominent notice with each copy of the Combined Work that

-   the Library is used in it and that the Library and its use are

-   covered by this License.

- 

- * **b)** Accompany the Combined Work with a copy of the GNU GPL and this license

-   document.

- 

- * **c)** For a Combined Work that displays copyright notices during

-   execution, include the copyright notice for the Library among

-   these notices, as well as a reference directing the user to the

-   copies of the GNU GPL and this license document.

- 

- * **d)** Do one of the following:

- 

-   - **0)** Convey the Minimal Corresponding Source under the terms of this

-     License, and the Corresponding Application Code in a form

-     suitable for, and under terms that permit, the user to

-     recombine or relink the Application with a modified version of

-     the Linked Version to produce a modified Combined Work, in the

-     manner specified by section 6 of the GNU GPL for conveying

-     Corresponding Source.

-   - **1)** Use a suitable shared library mechanism for linking with the

-     Library.  A suitable mechanism is one that **(a)** uses at run time

-     a copy of the Library already present on the user's computer

-     system, and **(b)** will operate properly with a modified version

-     of the Library that is interface-compatible with the Linked

-     Version.

- 

- * **e)** Provide Installation Information, but only if you would otherwise

-   be required to provide such information under section 6 of the

-   GNU GPL, and only to the extent that such information is

-   necessary to install and execute a modified version of the

-   Combined Work produced by recombining or relinking the

-   Application with a modified version of the Linked Version. (If

-   you use option **4d0**, the Installation Information must accompany

-   the Minimal Corresponding Source and Corresponding Application

-   Code. If you use option **4d1**, you must provide the Installation

-   Information in the manner specified by section 6 of the GNU GPL

-   for conveying Corresponding Source.)

- 

- 5. Combined Libraries

- ~~~~~~~~~~~~~~~~~~~~~

- 

- You may place library facilities that are a work based on the

- Library side by side in a single library together with other library

- facilities that are not Applications and are not covered by this

- License, and convey such a combined library under terms of your

- choice, if you do both of the following:

- 

- * **a)** Accompany the combined library with a copy of the same work based

-   on the Library, uncombined with any other library facilities,

-   conveyed under the terms of this License.

- * **b)** Give prominent notice with the combined library that part of it

-   is a work based on the Library, and explaining where to find the

-   accompanying uncombined form of the same work.

- 

- 6. Revised Versions of the GNU Lesser General Public License

- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

- 

- The Free Software Foundation may publish revised and/or new versions

- of the GNU Lesser General Public License from time to time. Such new

- versions will be similar in spirit to the present version, but may

- differ in detail to address new problems or concerns.

- 

- Each version is given a distinguishing version number. If the

- Library as you received it specifies that a certain numbered version

- of the GNU Lesser General Public License "or any later version"

- applies to it, you have the option of following the terms and

- conditions either of that published version or of any later version

- published by the Free Software Foundation. If the Library as you

- received it does not specify a version number of the GNU Lesser

- General Public License, you may choose any version of the GNU Lesser

- General Public License ever published by the Free Software Foundation.

- 

- If the Library as you received it specifies that a proxy can decide

- whether future versions of the GNU Lesser General Public License shall

- apply, that proxy's public statement of acceptance of any version is

- permanent authorization for you to choose that version for the

- Library.

@@ -1,359 +0,0 @@ 

- Creative Commons Legal Code

- 

- Attribution-ShareAlike 3.0 Unported

- 

-     CREATIVE COMMONS CORPORATION IS NOT A LAW FIRM AND DOES NOT PROVIDE

-     LEGAL SERVICES. DISTRIBUTION OF THIS LICENSE DOES NOT CREATE AN

-     ATTORNEY-CLIENT RELATIONSHIP. CREATIVE COMMONS PROVIDES THIS

-     INFORMATION ON AN "AS-IS" BASIS. CREATIVE COMMONS MAKES NO WARRANTIES

-     REGARDING THE INFORMATION PROVIDED, AND DISCLAIMS LIABILITY FOR

-     DAMAGES RESULTING FROM ITS USE.

- 

- License

- 

- THE WORK (AS DEFINED BELOW) IS PROVIDED UNDER THE TERMS OF THIS CREATIVE

- COMMONS PUBLIC LICENSE ("CCPL" OR "LICENSE"). THE WORK IS PROTECTED BY

- COPYRIGHT AND/OR OTHER APPLICABLE LAW. ANY USE OF THE WORK OTHER THAN AS

- AUTHORIZED UNDER THIS LICENSE OR COPYRIGHT LAW IS PROHIBITED.

- 

- BY EXERCISING ANY RIGHTS TO THE WORK PROVIDED HERE, YOU ACCEPT AND AGREE

- TO BE BOUND BY THE TERMS OF THIS LICENSE. TO THE EXTENT THIS LICENSE MAY

- BE CONSIDERED TO BE A CONTRACT, THE LICENSOR GRANTS YOU THE RIGHTS

- CONTAINED HERE IN CONSIDERATION OF YOUR ACCEPTANCE OF SUCH TERMS AND

- CONDITIONS.

- 

- 1. Definitions

- 

-  a. "Adaptation" means a work based upon the Work, or upon the Work and

-     other pre-existing works, such as a translation, adaptation,

-     derivative work, arrangement of music or other alterations of a

-     literary or artistic work, or phonogram or performance and includes

-     cinematographic adaptations or any other form in which the Work may be

-     recast, transformed, or adapted including in any form recognizably

-     derived from the original, except that a work that constitutes a

-     Collection will not be considered an Adaptation for the purpose of

-     this License. For the avoidance of doubt, where the Work is a musical

-     work, performance or phonogram, the synchronization of the Work in

-     timed-relation with a moving image ("synching") will be considered an

-     Adaptation for the purpose of this License.

-  b. "Collection" means a collection of literary or artistic works, such as

-     encyclopedias and anthologies, or performances, phonograms or

-     broadcasts, or other works or subject matter other than works listed

-     in Section 1(f) below, which, by reason of the selection and

-     arrangement of their contents, constitute intellectual creations, in

-     which the Work is included in its entirety in unmodified form along

-     with one or more other contributions, each constituting separate and

-     independent works in themselves, which together are assembled into a

-     collective whole. A work that constitutes a Collection will not be

-     considered an Adaptation (as defined below) for the purposes of this

-     License.

-  c. "Creative Commons Compatible License" means a license that is listed

-     at https://creativecommons.org/compatiblelicenses that has been

-     approved by Creative Commons as being essentially equivalent to this

-     License, including, at a minimum, because that license: (i) contains

-     terms that have the same purpose, meaning and effect as the License

-     Elements of this License; and, (ii) explicitly permits the relicensing

-     of adaptations of works made available under that license under this

-     License or a Creative Commons jurisdiction license with the same

-     License Elements as this License.

-  d. "Distribute" means to make available to the public the original and

-     copies of the Work or Adaptation, as appropriate, through sale or

-     other transfer of ownership.

-  e. "License Elements" means the following high-level license attributes

-     as selected by Licensor and indicated in the title of this License:

-     Attribution, ShareAlike.

-  f. "Licensor" means the individual, individuals, entity or entities that

-     offer(s) the Work under the terms of this License.

-  g. "Original Author" means, in the case of a literary or artistic work,

-     the individual, individuals, entity or entities who created the Work

-     or if no individual or entity can be identified, the publisher; and in

-     addition (i) in the case of a performance the actors, singers,

-     musicians, dancers, and other persons who act, sing, deliver, declaim,

-     play in, interpret or otherwise perform literary or artistic works or

-     expressions of folklore; (ii) in the case of a phonogram the producer

-     being the person or legal entity who first fixes the sounds of a

-     performance or other sounds; and, (iii) in the case of broadcasts, the

-     organization that transmits the broadcast.

-  h. "Work" means the literary and/or artistic work offered under the terms

-     of this License including without limitation any production in the

-     literary, scientific and artistic domain, whatever may be the mode or

-     form of its expression including digital form, such as a book,

-     pamphlet and other writing; a lecture, address, sermon or other work

-     of the same nature; a dramatic or dramatico-musical work; a

-     choreographic work or entertainment in dumb show; a musical

-     composition with or without words; a cinematographic work to which are

-     assimilated works expressed by a process analogous to cinematography;

-     a work of drawing, painting, architecture, sculpture, engraving or

-     lithography; a photographic work to which are assimilated works

-     expressed by a process analogous to photography; a work of applied

-     art; an illustration, map, plan, sketch or three-dimensional work

-     relative to geography, topography, architecture or science; a

-     performance; a broadcast; a phonogram; a compilation of data to the

-     extent it is protected as a copyrightable work; or a work performed by

-     a variety or circus performer to the extent it is not otherwise

-     considered a literary or artistic work.

-  i. "You" means an individual or entity exercising rights under this

-     License who has not previously violated the terms of this License with

-     respect to the Work, or who has received express permission from the

-     Licensor to exercise rights under this License despite a previous

-     violation.

-  j. "Publicly Perform" means to perform public recitations of the Work and

-     to communicate to the public those public recitations, by any means or

-     process, including by wire or wireless means or public digital

-     performances; to make available to the public Works in such a way that

-     members of the public may access these Works from a place and at a

-     place individually chosen by them; to perform the Work to the public

-     by any means or process and the communication to the public of the

-     performances of the Work, including by public digital performance; to

-     broadcast and rebroadcast the Work by any means including signs,

-     sounds or images.

-  k. "Reproduce" means to make copies of the Work by any means including

-     without limitation by sound or visual recordings and the right of

-     fixation and reproducing fixations of the Work, including storage of a

-     protected performance or phonogram in digital form or other electronic

-     medium.

- 

- 2. Fair Dealing Rights. Nothing in this License is intended to reduce,

- limit, or restrict any uses free from copyright or rights arising from

- limitations or exceptions that are provided for in connection with the

- copyright protection under copyright law or other applicable laws.

- 

- 3. License Grant. Subject to the terms and conditions of this License,

- Licensor hereby grants You a worldwide, royalty-free, non-exclusive,

- perpetual (for the duration of the applicable copyright) license to

- exercise the rights in the Work as stated below:

- 

-  a. to Reproduce the Work, to incorporate the Work into one or more

-     Collections, and to Reproduce the Work as incorporated in the

-     Collections;

-  b. to create and Reproduce Adaptations provided that any such Adaptation,

-     including any translation in any medium, takes reasonable steps to

-     clearly label, demarcate or otherwise identify that changes were made

-     to the original Work. For example, a translation could be marked "The

-     original work was translated from English to Spanish," or a

-     modification could indicate "The original work has been modified.";

-  c. to Distribute and Publicly Perform the Work including as incorporated

-     in Collections; and,

-  d. to Distribute and Publicly Perform Adaptations.

-  e. For the avoidance of doubt:

- 

-      i. Non-waivable Compulsory License Schemes. In those jurisdictions in

-         which the right to collect royalties through any statutory or

-         compulsory licensing scheme cannot be waived, the Licensor

-         reserves the exclusive right to collect such royalties for any

-         exercise by You of the rights granted under this License;

-     ii. Waivable Compulsory License Schemes. In those jurisdictions in

-         which the right to collect royalties through any statutory or

-         compulsory licensing scheme can be waived, the Licensor waives the

-         exclusive right to collect such royalties for any exercise by You

-         of the rights granted under this License; and,

-    iii. Voluntary License Schemes. The Licensor waives the right to

-         collect royalties, whether individually or, in the event that the

-         Licensor is a member of a collecting society that administers

-         voluntary licensing schemes, via that society, from any exercise

-         by You of the rights granted under this License.

- 

- The above rights may be exercised in all media and formats whether now

- known or hereafter devised. The above rights include the right to make

- such modifications as are technically necessary to exercise the rights in

- other media and formats. Subject to Section 8(f), all rights not expressly

- granted by Licensor are hereby reserved.

- 

- 4. Restrictions. The license granted in Section 3 above is expressly made

- subject to and limited by the following restrictions:

- 

-  a. You may Distribute or Publicly Perform the Work only under the terms

-     of this License. You must include a copy of, or the Uniform Resource

-     Identifier (URI) for, this License with every copy of the Work You

-     Distribute or Publicly Perform. You may not offer or impose any terms

-     on the Work that restrict the terms of this License or the ability of

-     the recipient of the Work to exercise the rights granted to that

-     recipient under the terms of the License. You may not sublicense the

-     Work. You must keep intact all notices that refer to this License and

-     to the disclaimer of warranties with every copy of the Work You

-     Distribute or Publicly Perform. When You Distribute or Publicly

-     Perform the Work, You may not impose any effective technological

-     measures on the Work that restrict the ability of a recipient of the

-     Work from You to exercise the rights granted to that recipient under

-     the terms of the License. This Section 4(a) applies to the Work as

-     incorporated in a Collection, but this does not require the Collection

-     apart from the Work itself to be made subject to the terms of this

-     License. If You create a Collection, upon notice from any Licensor You

-     must, to the extent practicable, remove from the Collection any credit

-     as required by Section 4(c), as requested. If You create an

-     Adaptation, upon notice from any Licensor You must, to the extent

-     practicable, remove from the Adaptation any credit as required by

-     Section 4(c), as requested.

-  b. You may Distribute or Publicly Perform an Adaptation only under the

-     terms of: (i) this License; (ii) a later version of this License with

-     the same License Elements as this License; (iii) a Creative Commons

-     jurisdiction license (either this or a later license version) that

-     contains the same License Elements as this License (e.g.,

-     Attribution-ShareAlike 3.0 US)); (iv) a Creative Commons Compatible

-     License. If you license the Adaptation under one of the licenses

-     mentioned in (iv), you must comply with the terms of that license. If

-     you license the Adaptation under the terms of any of the licenses

-     mentioned in (i), (ii) or (iii) (the "Applicable License"), you must

-     comply with the terms of the Applicable License generally and the

-     following provisions: (I) You must include a copy of, or the URI for,

-     the Applicable License with every copy of each Adaptation You

-     Distribute or Publicly Perform; (II) You may not offer or impose any

-     terms on the Adaptation that restrict the terms of the Applicable

-     License or the ability of the recipient of the Adaptation to exercise

-     the rights granted to that recipient under the terms of the Applicable

-     License; (III) You must keep intact all notices that refer to the

-     Applicable License and to the disclaimer of warranties with every copy

-     of the Work as included in the Adaptation You Distribute or Publicly

-     Perform; (IV) when You Distribute or Publicly Perform the Adaptation,

-     You may not impose any effective technological measures on the

-     Adaptation that restrict the ability of a recipient of the Adaptation

-     from You to exercise the rights granted to that recipient under the

-     terms of the Applicable License. This Section 4(b) applies to the

-     Adaptation as incorporated in a Collection, but this does not require

-     the Collection apart from the Adaptation itself to be made subject to

-     the terms of the Applicable License.

-  c. If You Distribute, or Publicly Perform the Work or any Adaptations or

-     Collections, You must, unless a request has been made pursuant to

-     Section 4(a), keep intact all copyright notices for the Work and

-     provide, reasonable to the medium or means You are utilizing: (i) the

-     name of the Original Author (or pseudonym, if applicable) if supplied,

-     and/or if the Original Author and/or Licensor designate another party

-     or parties (e.g., a sponsor institute, publishing entity, journal) for

-     attribution ("Attribution Parties") in Licensor's copyright notice,

-     terms of service or by other reasonable means, the name of such party

-     or parties; (ii) the title of the Work if supplied; (iii) to the

-     extent reasonably practicable, the URI, if any, that Licensor

-     specifies to be associated with the Work, unless such URI does not

-     refer to the copyright notice or licensing information for the Work;

-     and (iv) , consistent with Ssection 3(b), in the case of an

-     Adaptation, a credit identifying the use of the Work in the Adaptation

-     (e.g., "French translation of the Work by Original Author," or

-     "Screenplay based on original Work by Original Author"). The credit

-     required by this Section 4(c) may be implemented in any reasonable

-     manner; provided, however, that in the case of a Adaptation or

-     Collection, at a minimum such credit will appear, if a credit for all

-     contributing authors of the Adaptation or Collection appears, then as

-     part of these credits and in a manner at least as prominent as the

-     credits for the other contributing authors. For the avoidance of

-     doubt, You may only use the credit required by this Section for the

-     purpose of attribution in the manner set out above and, by exercising

-     Your rights under this License, You may not implicitly or explicitly

-     assert or imply any connection with, sponsorship or endorsement by the

-     Original Author, Licensor and/or Attribution Parties, as appropriate,

-     of You or Your use of the Work, without the separate, express prior

-     written permission of the Original Author, Licensor and/or Attribution

-     Parties.

-  d. Except as otherwise agreed in writing by the Licensor or as may be

-     otherwise permitted by applicable law, if You Reproduce, Distribute or

-     Publicly Perform the Work either by itself or as part of any

-     Adaptations or Collections, You must not distort, mutilate, modify or

-     take other derogatory action in relation to the Work which would be

-     prejudicial to the Original Author's honor or reputation. Licensor

-     agrees that in those jurisdictions (e.g. Japan), in which any exercise

-     of the right granted in Section 3(b) of this License (the right to

-     make Adaptations) would be deemed to be a distortion, mutilation,

-     modification or other derogatory action prejudicial to the Original

-     Author's honor and reputation, the Licensor will waive or not assert,

-     as appropriate, this Section, to the fullest extent permitted by the

-     applicable national law, to enable You to reasonably exercise Your

-     right under Section 3(b) of this License (right to make Adaptations)

-     but not otherwise.

- 

- 5. Representations, Warranties and Disclaimer

- 

- UNLESS OTHERWISE MUTUALLY AGREED TO BY THE PARTIES IN WRITING, LICENSOR

- OFFERS THE WORK AS-IS AND MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY

- KIND CONCERNING THE WORK, EXPRESS, IMPLIED, STATUTORY OR OTHERWISE,

- INCLUDING, WITHOUT LIMITATION, WARRANTIES OF TITLE, MERCHANTIBILITY,

- FITNESS FOR A PARTICULAR PURPOSE, NONINFRINGEMENT, OR THE ABSENCE OF

- LATENT OR OTHER DEFECTS, ACCURACY, OR THE PRESENCE OF ABSENCE OF ERRORS,

- WHETHER OR NOT DISCOVERABLE. SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION

- OF IMPLIED WARRANTIES, SO SUCH EXCLUSION MAY NOT APPLY TO YOU.

- 

- 6. Limitation on Liability. EXCEPT TO THE EXTENT REQUIRED BY APPLICABLE

- LAW, IN NO EVENT WILL LICENSOR BE LIABLE TO YOU ON ANY LEGAL THEORY FOR

- ANY SPECIAL, INCIDENTAL, CONSEQUENTIAL, PUNITIVE OR EXEMPLARY DAMAGES

- ARISING OUT OF THIS LICENSE OR THE USE OF THE WORK, EVEN IF LICENSOR HAS

- BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

- 

- 7. Termination

- 

-  a. This License and the rights granted hereunder will terminate

-     automatically upon any breach by You of the terms of this License.

-     Individuals or entities who have received Adaptations or Collections

-     from You under this License, however, will not have their licenses

-     terminated provided such individuals or entities remain in full

-     compliance with those licenses. Sections 1, 2, 5, 6, 7, and 8 will

-     survive any termination of this License.

-  b. Subject to the above terms and conditions, the license granted here is

-     perpetual (for the duration of the applicable copyright in the Work).

-     Notwithstanding the above, Licensor reserves the right to release the

-     Work under different license terms or to stop distributing the Work at

-     any time; provided, however that any such election will not serve to

-     withdraw this License (or any other license that has been, or is

-     required to be, granted under the terms of this License), and this

-     License will continue in full force and effect unless terminated as

-     stated above.

- 

- 8. Miscellaneous

- 

-  a. Each time You Distribute or Publicly Perform the Work or a Collection,

-     the Licensor offers to the recipient a license to the Work on the same

-     terms and conditions as the license granted to You under this License.

-  b. Each time You Distribute or Publicly Perform an Adaptation, Licensor

-     offers to the recipient a license to the original Work on the same

-     terms and conditions as the license granted to You under this License.

-  c. If any provision of this License is invalid or unenforceable under

-     applicable law, it shall not affect the validity or enforceability of

-     the remainder of the terms of this License, and without further action

-     by the parties to this agreement, such provision shall be reformed to

-     the minimum extent necessary to make such provision valid and

-     enforceable.

-  d. No term or provision of this License shall be deemed waived and no

-     breach consented to unless such waiver or consent shall be in writing

-     and signed by the party to be charged with such waiver or consent.

-  e. This License constitutes the entire agreement between the parties with

-     respect to the Work licensed here. There are no understandings,

-     agreements or representations with respect to the Work not specified

-     here. Licensor shall not be bound by any additional provisions that

-     may appear in any communication from You. This License may not be

-     modified without the mutual written agreement of the Licensor and You.

-  f. The rights granted under, and the subject matter referenced, in this

-     License were drafted utilizing the terminology of the Berne Convention

-     for the Protection of Literary and Artistic Works (as amended on

-     September 28, 1979), the Rome Convention of 1961, the WIPO Copyright

-     Treaty of 1996, the WIPO Performances and Phonograms Treaty of 1996

-     and the Universal Copyright Convention (as revised on July 24, 1971).

-     These rights and subject matter take effect in the relevant

-     jurisdiction in which the License terms are sought to be enforced

-     according to the corresponding provisions of the implementation of

-     those treaty provisions in the applicable national law. If the

-     standard suite of rights granted under applicable copyright law

-     includes additional rights not granted under this License, such

-     additional rights are deemed to be included in the License; this

-     License is not intended to restrict the license of any rights under

-     applicable law.

- 

- 

- Creative Commons Notice

- 

-     Creative Commons is not a party to this License, and makes no warranty

-     whatsoever in connection with the Work. Creative Commons will not be

-     liable to You or any party on any legal theory for any damages

-     whatsoever, including without limitation any general, special,

-     incidental or consequential damages arising in connection to this

-     license. Notwithstanding the foregoing two (2) sentences, if Creative

-     Commons has expressly identified itself as the Licensor hereunder, it

-     shall have all rights and obligations of Licensor.

- 

-     Except for the limited purpose of indicating to the public that the

-     Work is licensed under the CCPL, Creative Commons does not authorize

-     the use by either party of the trademark "Creative Commons" or any

-     related trademark or logo of Creative Commons without the prior

-     written consent of Creative Commons. Any permitted use will be in

-     compliance with Creative Commons' then-current trademark usage

-     guidelines, as may be published on its website or otherwise made

-     available upon request from time to time. For the avoidance of doubt,

-     this trademark restriction does not form part of the License.

- 

-     Creative Commons may be contacted at https://creativecommons.org/.

@@ -1,26 +0,0 @@ 

- The MIT License (MIT)

- =====================

- 

- Copyright © `<year>` `<copyright holders>`

- 

- Permission is hereby granted, free of charge, to any person

- obtaining a copy of this software and associated documentation

- files (the "Software"), to deal in the Software without

- restriction, including without limitation the rights to use,

- copy, modify, merge, publish, distribute, sublicense, and/or sell

- copies of the Software, and to permit persons to whom the

- Software is furnished to do so, subject to the following

- conditions:

- 

- The above copyright notice and this permission notice shall be

- included in all copies or substantial portions of the Software.

- 

- THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,

- EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES

- OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND

- NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT

- HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,

- WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING

- FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR

- OTHER DEALINGS IN THE SOFTWARE.

- 

file removed
-20
@@ -1,20 +0,0 @@ 

- site:

-   title: Local Preview

-   start_page: epel::index.adoc

- content:

-   sources:

-    - url: .

-      branches: HEAD

- ui:

-   bundle:

-     url: https://gitlab.com/fedora/docs/docs-website/ui-bundle/-/jobs/artifacts/HEAD/raw/build/ui-bundle.zip?job=bundle-stable

-     snapshot: true

-   default_layout: with_menu

- output:

-   clean: true

-   dir: ./public

- runtime:

-   fetch: true

-   cache_dir: ./cache

- urls:

-   html_extension_style: indexify

As part of the docs repo migration process [0], this change removes the docs from this repository. I also modified the README to guide people to the other repo for docs related changes.

Btw, the new docs are already hosted at:

[0] https://pagure.io/epel/issue/355

Very exciting.
Just to double check. Has the thing that builds the pages already been changed to point to the new repo?

I see that you already announced that everything is in place. So ... +1 from me.

Pull-Request has been merged by dherrera

a month ago
Metadata
Changes Summary 48
-4
file removed
.gitignore
+11 -15
file changed
README.md
-22
file removed
antora.yml
-292
file removed
docsbuilder.sh
-150
file removed
modules/ROOT/assets/images/epel-logo.svg
-9
file removed
modules/ROOT/examples/exampe-example.adoc
-26
file removed
modules/ROOT/nav.adoc
-35
file removed
modules/ROOT/pages/available-packages.adoc
-132
file removed
modules/ROOT/pages/branches.adoc
-32
file removed
modules/ROOT/pages/epel-about-history-philosophy.adoc
-148
file removed
modules/ROOT/pages/epel-about-next.adoc
-16
file removed
modules/ROOT/pages/epel-about-playground.adoc
-131
file removed
modules/ROOT/pages/epel-about.adoc
-46
file removed
modules/ROOT/pages/epel-communication.adoc
-557
file removed
modules/ROOT/pages/epel-faq.adoc
-19
file removed
modules/ROOT/pages/epel-help.adoc
-60
file removed
modules/ROOT/pages/epel-package-maintainer-generic-description.adoc
-85
file removed
modules/ROOT/pages/epel-package-maintainers.adoc
-202
file removed
modules/ROOT/pages/epel-package-request.adoc
-122
file removed
modules/ROOT/pages/epel-packagers-sig.adoc
-174
file removed
modules/ROOT/pages/epel-packaging-examples.adoc
-127
file removed
modules/ROOT/pages/epel-packaging.adoc
-61
file removed
modules/ROOT/pages/epel-policy-incompatible-upgrades.adoc
-89
file removed
modules/ROOT/pages/epel-policy-missing-sub-packages.adoc
-93
file removed
modules/ROOT/pages/epel-policy-retirement.adoc
-21
file removed
modules/ROOT/pages/epel-policy-scl.adoc
-125
file removed
modules/ROOT/pages/epel-policy-steering-committee.adoc
-43
file removed
modules/ROOT/pages/epel-policy-updates.adoc
-342
file removed
modules/ROOT/pages/epel-policy.adoc
-42
file removed
modules/ROOT/pages/epel-qa.adoc
-18
file removed
modules/ROOT/pages/epel-rhel-entitlements.adoc
-102
file removed
modules/ROOT/pages/epel-testing.adoc
-139
file removed
modules/ROOT/pages/getting-started.adoc
-52
file removed
modules/ROOT/pages/index.adoc
-1
file removed
modules/ROOT/partials/attributes.adoc
-15
file removed
modules/ROOT/partials/partial-example.adoc
-14
file removed
nginx.conf
-177
file removed
old.docs/Makefile
-400
file removed
old.docs/source/EPEL-charter.rst
-117
file removed
old.docs/source/EPEL-meeting-process.rst
-29
file removed
old.docs/source/licenses/bsd-2.rst
-340
file removed
old.docs/source/licenses/gnu-gpl-v2.0.rst
-616
file removed
old.docs/source/licenses/gnu-gpl-v3.0.rst
-500
file removed
old.docs/source/licenses/gnu-lgpl-v2.1.rst
-170
file removed
old.docs/source/licenses/gnu-lgpl-v3.0.rst
-359
file removed
old.docs/source/licenses/legalcode.txt
-26
file removed
old.docs/source/licenses/mit.rst
-20
file removed
site.yml