From bd40aeedab93105028340991ffa85d1921bc6aee Mon Sep 17 00:00:00 2001 From: Otto Urpelainen Date: Jul 07 2021 18:55:43 +0000 Subject: Wiki import Restart the repository by 1. Starting to use Antora 2. Moving over some packaging related pages over from the wiki 3. Updating the pages where there are obvious problems --- diff --git a/.gitignore b/.gitignore index 1897e6f..9f3ebf5 100644 --- a/.gitignore +++ b/.gitignore @@ -1,4 +1,3 @@ -*.pyc -pelican.pid -srv.pid -output/ +build +cache +public diff --git a/LICENSE b/LICENSE new file mode 100644 index 0000000..ba8d521 --- /dev/null +++ b/LICENSE @@ -0,0 +1,10 @@ +The text of and illustrations in this document are licensed by Red Hat +under a Creative Commons Attribution–Share Alike 3.0 Unported license +("CC-BY-SA"). An explanation of CC-BY-SA is available at +http://creativecommons.org/licenses/by-sa/3.0/. In accordance with +CC-BY-SA, if you distribute this document or an adaptation of it, you +must provide the URL for the original version. + +Red Hat, as the licensor of this document, waives the right to +enforce, and agrees not to assert, Section 4d of CC-BY-SA to the +fullest extent permitted by applicable law. diff --git a/README.md b/README.md index 15794be..ec22d92 100644 --- a/README.md +++ b/README.md @@ -1,17 +1,131 @@ -# packaging docs +# Fedora Packaging Committee -## Running the server for writing new articles +Welcome! This is the Pagure instance for the Fedora Package Maintainer Docs. -Running the pelican development server is useful when writing new articles. The steps to -get it running are: +The Pagure repository is used to store the source of Package Maintainer Docs, +track related issues +and accept changes via pull requests. -1. Install pelican: - ```` - sudo dnf install python2-pelican python2-GitPython - python-beautifulsoup4 rubygem-asciidoctor - ```` +You can view the actual packaging guidelines +[here](https://docs.fedoraproject.org/en-US/package-maintainers/). -2. Check out the packagin docs source (from your fork or the main repo) -3. In the main folder of the checked out repo, run `./develop_server.sh start` -and your local copy of the Docs Fedora will be at http://localhost:8000/ -4. To stop the development server, run `./develop_server.sh stop` +## Documentation Development + +### Writing + +[Antora](https://antora.org/) is used for +managing the various documents which comprise the guidelines +and integrating them into the rest of Fedora Documentation. + +The guidelines themselves are written in +[AsciiDoc](https://asciidoc.org). +Some useful information about AsciiDoc can be found below: + +* [AsciiDoc Syntax Quick Reference](https://asciidoctor.org/docs/asciidoc-syntax-quick-reference/) +* [AsciiDoc Writer's Guide](https://asciidoctor.org/docs/asciidoc-writers-guide/) + +### Conventions and Preferences + +This repository attempts to follow the following: + +* Use [Semantic Line Breaks](http://sembr.org/) to make diffing simpler. +* Prefer `https://example.com[here]` over `link:https://example.com[here]` +* Prefer `[#some-ref]` over `[[some-ref]]` + +### Local preview + +This repo includes scripts to +build and preview the contents of this repository. + +**NOTE**: Please note that +if you reference pages from other repositories, +such links will be broken in this local preview +as it only builds this repository. +If you want to rebuild the whole Fedora Docs site, +please see [the Fedora Docs build repository](https://pagure.io/fedora-docs/docs-fp-o/) for instructions. + +Both scripts work on Fedora (using Podman) and macOS (using Docker). + +To build and preview the site, run: + +``` +$ ./build.sh && ./preview.sh +``` + +The result will be available at http://localhost:8080 + +#### Installing Podman on Fedora + +Fedora Workstation doesn't come with Podman preinstalled by default +— so you might need to install it using the following command: + +``` +$ sudo dnf install podman +``` + +#### Preview as a part of the whole Fedora Docs site + +You can also build the whole Fedora Docs site locally +to see your changes in the whole context. +This is especially useful for checking if your `xref` links work properly. + +To do this, +you need to clone the main [Fedora Docs build repository](https://pagure.io/fedora-docs/docs-fp-o), +modify the `site.yml` file to reference a repo with your changes, +and build it. +Steps: + +Clone the main repository and cd into it: + +``` +$ git clone https://pagure.io/fedora-docs/docs-fp-o.git +$ cd docs-fp-o +``` + +Find a reference to the repository you're changing in the `site.yml` file, +and change it so it points to your change. +So for example, if I made a modification to the Modularity docs, +I would find: + +``` +... + - url: https://pagure.io/fedora-docs/modularity.git + branches: + - master +... +``` + +And replaced it with a pointer to my fork: +``` +... + - url: https://pagure.io/forks/asamalik/fedora-docs/modularity.git + branches: + - master +... +``` + +I could also point to a local repository, +using `HEAD` as a branch +to preview the what's changed +without the need of making a commit. + +**Note:** I would need to move the repository under the `docs-fp-o` directory, +because the builder won't see anything above. +So I would need to create a `repositories` directory in `docs-fp-o` +and copy my repository into it. + +``` +... + - url: ./repositories/modularity + branches: + - HEAD +... +``` + +To build the whole site, +I would run the following +in the `docs-fp-o` directory. + +``` +$ ./build.sh && ./preview.sh +``` diff --git a/antora.yml b/antora.yml new file mode 100644 index 0000000..7779b80 --- /dev/null +++ b/antora.yml @@ -0,0 +1,16 @@ +# 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: package-maintainers + +# Title will be visible on the page. +title: Package Maintainers + +# 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 "master" to a specific version. +version: master + +# 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 + +# This lists all the menu definitions of your component. +nav: +- modules/ROOT/nav.adoc diff --git a/build.sh b/build.sh new file mode 100755 index 0000000..f4ecfe4 --- /dev/null +++ b/build.sh @@ -0,0 +1,46 @@ +#!/bin/sh + +image="docker.io/antora/antora" +cmd="--html-url-extension-style=indexify site.yml" + +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 fall back to docker + # which requires root. + + if [ -f /usr/bin/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 + + elif [ -f /usr/bin/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 diff --git a/content/en-US/add_a_package.adoc b/content/en-US/add_a_package.adoc deleted file mode 100644 index be5b874..0000000 --- a/content/en-US/add_a_package.adoc +++ /dev/null @@ -1,13 +0,0 @@ -:Tags: COPR, new package, rpms -:Slug: adding-a-package -= How to get a package added to Fedora? - -This document explains how to get a software packaged for Fedora and added into -the distribution - -Questions to answers (unordered): -- How do I COPR? -- How can I get my project in Fedora? -- How to package this project I used? -- How to get this project I used added? -- What about EPEL? diff --git a/content/en-US/becoming_packager.adoc b/content/en-US/becoming_packager.adoc deleted file mode 100644 index 0cb19fa..0000000 --- a/content/en-US/becoming_packager.adoc +++ /dev/null @@ -1,48 +0,0 @@ -:Tags: joining, fedpkg, rpms -:Slug: becoming-a-package-maintainer -= Becoming a package maintainer - -Fedora Packages are maintained collectively by a community of both Red Hat members and volunteers. -Software components included in Fedora need to be maintained actively, and bugs - especially security issues - need to be fixed in a timely manner. -As a Fedora package maintainer, it is your primary https://fedoraproject.org/wiki/Package_maintainer_responsibilities[ responsibility] to ensure this. - -This guide will lead you through the initial steps for joining the packaging team. - -[[create-a-fedora-account]] -== Create a Fedora Account - -Create an account in the https://admin.fedoraproject.org/accounts/[Fedora Account System], and https://fedoraproject.org/wiki/Account_System/CompleteFPCA[complete the Fedora Project Contributor Agreement (FPCA)] - -Additionally, you require a RSA SSH key to work on Fedora packages. Add your public RSA SSH key to the Fedora Account System. -More information on creating an SSH key is available in the https://fedoraproject.org/wiki/Cryptography[Cryptography article]. - -[[join-the-important-mailing-lists]] -== Join the important Mailing Lists -There are several mailing lists that are useful to Fedora Package Maintainers. -devel-announce is the only mailing list that is required for Fedora Package Maintainers to belong to. - -=== devel-announce mailing list -Fedora Package Maintainers are expected to join the https://lists.fedoraproject.org/admin/lists/devel-announce.lists.fedoraproject.org/[devel-announce mailing list.] -devel-announce is a low traffic announcements only list, where important development information is posted. - -=== devel mailing list -Joining the https://lists.fedoraproject.org/admin/lists/devel.lists.fedoraproject.org/[devel mailing list] is recommended for Fedora Package Maintainers. -devel is a high-traffic mailing list where discussions about the development of Fedora are held. - -=== packaging mailing list -Another mailing list you might consider (at least to view the archives) -is the https://lists.fedoraproject.org/admin/lists/packaging@lists.fedoraproject.org/[packaging mailing list]. This is the mailing list of the link:Packaging/Committee[ Fedora -Packaging Committee], who determine the official packaging guidelines -for Fedora projects. - -[[read-the-guidelines]] -== Read the Guidelines - -The https://fedoraproject.org/wiki/Packaging:Guidelines[Fedora Packaging Guidelines] specify a list of recommendations for Fedora packages. -The http://fedoraproject.org/wiki/Packaging:Naming[Package Naming Guidelines] specify recommendations for how Fedora packages are named. - -For detailed information on creating an RPM package, refer to the guide to https://docs.fedoraproject.org/quick-docs/en-US/creating-rpm-packages.html[creating an RPM package.] - -== Next steps -* #[setting up your system for packaging] -* #[creating a new package in Fedora] \ No newline at end of file diff --git a/content/en-US/introduction.adoc b/content/en-US/introduction.adoc deleted file mode 100644 index de1ef79..0000000 --- a/content/en-US/introduction.adoc +++ /dev/null @@ -1,62 +0,0 @@ -:Tags: joining -:Slug: introduction-to-packaging -= Introduction to Packaging - -== What is packaging? - -There are myriad software projects being developed on a daily basis. -Each of these comes with instructions on how to install. - -These instructions can be simple or complex, depending on the nature of the software and its dependencies. -Packaging is the process of standardizing these different installation methods into a common format. - -In Fedora, the default packaging format is RPM, but other formats are supported, such as containers and modules. - -Regardless of the format, packaging also provides metadata about the application to a build system, such as: - -* name -* version -* license -* build and installation instructions - -== Why is packaging useful? - -Standard packaging allows users to discover, install, and audit the software on their system in a consistent way. -There are many ways to build software, and the method often depends on the tools used by the developers. -Similarly, there are many ways to install that software, often depending on the programming language used to write the source code. -For instance, Python has `easy_install` and `pip_install`, Perl has `cpan install`, Java has `maven`, and so on. -The multiplicity of these tools can also easily break systems or other applications if, for example, installing a library overwrites a file used by another application. - -Packaging has numerous advantages over disparate build and language-specific management tools: - -* Packaging tracks system state and makes it easy for an administrator to audit the system to see if files are legitimate and authentic. -* Unlike language-specific tools, packaging tools can resolve dependencies across languages, such as a PHP library that depends on non-PHP content. -* The system owner only has to learn to use one set of tools to install applications, libraries, and other content, regardless of language or build tooling. -* The system does not need a functioning compiler, much less multiple compilers across different languages. - -Packages provided by Fedora are built on secure builders and cryptographically signed. -Therefore they provide users a certain amount of security, reproducibility, and authenticity. - -== How is packaging done? - -Fedora supports several different packaging formats. -This document provides an overview of each and references to more documentation about each. - -=== RPMs - -RPM is a pre-built, binary package format. -The RPM package is built from source using a `spec` file that contains metadata about the application and build instructions. -The spec file is a simple text file documented in this https://rpm-packaging-guide.github.io/[RPM Packaging Guide]. -Often the spec file, the source code of the application, any patches, and additional files are combined in a single archive called the source rpm or SRPM. - -The RPM package can be built from the SRPM. -The resulting RPM package file is a single archive that contains the resulting binary files in the same structure as they should appear on the file system. -The archive may also contain scripts executed before or after the installation, update, or removal of the application. - -=== Containers - -Documentation on package and build containers is coming soon. - -=== Modules - -Documentation on how to package and build modules is coming soon. diff --git a/content/en-US/old/join-the-package-collection-maintainers.adoc b/content/en-US/old/join-the-package-collection-maintainers.adoc deleted file mode 100644 index 7964f27..0000000 --- a/content/en-US/old/join-the-package-collection-maintainers.adoc +++ /dev/null @@ -1,480 +0,0 @@ -[[contributing-roles]] -= Contributing roles - -[cols="",] -|======================================================================= -|image:Join_OSDeveloper.png[Join_OSDeveloper.png,title="fig:Join_OSDeveloper.png"] + -link:Join#OS_Developer[OS Developer] -|======================================================================= - -[[how-to-join-the-fedora-package-collection-maintainers]] -= How to join the Fedora Package Collection Maintainers? - -So, you have decided to become a package maintainer in the Fedora -Project? This guide will lead you through your first package submission. - -file:fedora-submit-package.png[750x214px] - -[[becoming-a-fedora-package-collection-maintainer]] -== Becoming a Fedora Package Collection Maintainer - -[[read-the-guidelines]] -=== Read the Guidelines - -If you don't know how to create an RPM package, refer to the tutorial at -How_to_create_a_GNU_Hello_RPM_package or the more advanced and much more -detailed link:how to create an RPM package[how to create an RPM -package]. - -Read the Packaging:Guidelines[ Packaging Guidelines] and -Packaging:NamingGuidelines[ Package Naming Guidelines] . - -You need to be thoroughly familiar with these. They govern all package -submissions. If you have questions, ask on the Fedora List. - -[[create-a-bugzilla-account]] -=== Create a Bugzilla Account - -Make sure you have an account in https://bugzilla.redhat.com/[Red Hat -Bugzilla] . - -The email address that you use for your Bugzilla account should be the -same email address as you use in the link:#Get_a_Fedora_Account[ Fedora -Account System] for all things related to Fedora Packaging. - -[[create-a-fedora-account]] -=== Create a Fedora Account - -Create an account in the link:Infrastructure/AccountSystem[Fedora -Account System] (this is _not_ the same as the Bugzilla account) - -1. Visit the account system home: -https://admin.fedoraproject.org/accounts/ -2. Click on 'New account' and fill in the blanks. Note that the email -you give should be the same as the one you gave Bugzilla. This allows -the system to link privileges between the two accounts. -3. After you create your account, please be sure to sign the CLA (if -you click on the "My Account" link in the top right, you should see CLA: -CLA Done). -4. You will also need to upload a public RSA SSH key. You need to use -the matching private key to access Fedora machines via SSH. You can read -more about this link:Cryptography[ here]. - -[[join-the-important-mailing-lists]] -=== Join the important Mailing Lists - -You must join the fedora mailing list. It is a low traffic announcements -only list, where important development information is posted. - -You can join the fedora mailing list, where discussions about the -development of Fedora are held. This is a high traffic mailing list. - -You can also consider joining the mailing list -- The commits mailing -list gets notifications on all commits in any package in the Fedora -repository. This is a very high traffic mailing list. The Fedora package -database sends commit mails for packages you (co-)maintain. - -Another mailing list you might consider (at least to view the archives) -is . This is the mailing list of the link:Packaging/Committee[ Fedora -Packaging Committee], who determine the official packaging guidelines -for Fedora projects. - -[[ensure-the-software-you-wish-to-package-is-suitable]] -=== Ensure the software you wish to package is suitable - -The package you are submitting can be of any free and open source -project that is not already packaged in Fedora. Before creating your -package, make sure that the software is not already in the Fedora -repository, or waiting for review. - -* Search the https://apps.fedoraproject.org/packages/[Fedora packages] -for packages already in the repository. -* Search in the http://fedoraproject.org/PackageReviewStatus/[Review -Tracker] for packages under review. -* Also check the link:Deprecated_packages[ deprecated packages] list. -* Be aware of link:forbidden items[forbidden items]. - -[[understand-your-responsibilities]] -=== Understand your responsibilities - -Software components included in Fedora need to be maintained actively, -and bugs - especially security issues - need to be fixed in a timely -manner. As a Fedora package maintainer, it is your primary -link:Package_maintainer_responsibilities[ responsibility] to ensure -this. We encourage you to get -link:Policy_for_encouraging_comaintainers_of_packages[ co-maintainers] -and seek the help of the Fedora community via the development mailing -list whenever needed. - -[[read-other-submissions]] -=== Read Other Submissions - -Read some other package submissions to learn about packaging and gain -familiarity with the process and requirements. - -One way of doing this is to join the mailing list;All comments on Fedora -package reviews are sent to this (read-only from your point of view) -list. - -[[configure-your-git]] -=== Configure Your Git - -First thing to do when you set up Fedora packaging is to configure your -user name and email address for Git. These are linked in each commit you -do to Fedora packages. - --------------------------------------------------- -git config --global user.name "John Doe" -git config --global user.email johndoe@example.com --------------------------------------------------- - -[[install-the-developer-client-tools]] -=== Install the developer client tools - -To build Packages for the Fedora Collection or EPEL in the Fedora build -system you need link:Using_the_Koji_build_system[Koji]. - -The package provides tools to help you setup and work with fedora; it -will bring in everything necessary for general packaging work. Run the -following as root: - -`dnf install fedora-packager` - -After installation run the following as your user (not root) to -link:Using_the_Koji_build_system#Fedora_Account_System_.28FAS2.29_Setup[setup -your koji client configuration]: - -`fedora-packager-setup` - -You can now use "koji" to try to build your RPM packages in the Fedora -build system, even on platforms or Fedora versions you don't have. Note -that you can (and definitely should) test out builds ("scratch" builds) -even before your package has been approved and you have been sponsored. -A simple way to do a scratch build using koji is to do this at the -command line: - -`koji build --scratch TARGET path_to_source_RPM` - -Where: - -* TARGET is a distribution keyword such as f25 (for Fedora 25). You can -run "koji list-targets" to see all targets. To build for the next -release (rawhide), _don't_ use "dist-rawhide" - use "fX" where X is one -more than the latest stable or branched release. -* Note that you need to supply the _path_ to the source RPM (which ends -in .src.rpm), and *not* a URL. (If you only have the spec file, use -`rpmbuild --nodeps -bs SPECFILE` to create the new source RPM). - -Your koji builds can only depend on packages that are actually in the -TARGET distribution repository. Thus, you can't use koji to build for -released distributions if your package depends on other new packages -that link:Bodhi[ Bodhi] hasn't released yet. You _can_ use koji to build -for rawhide (the next unreleased version), even if it depends on other -new packages, as long as the other packages were built for the "rawhide" -as described below. If you need to build against a package that is not -yet a stable released update, you can file a ticket with rel-eng at: -https://fedorahosted.org/rel-eng/newticket and request that that package -be added as a buildroot override. For packages in EPEL, you have to use -the component _epel_ to get the request to the right persons. - -You can learn more about koji via: - -`koji --help            # General help` + -`koji --help-commands   # list of koji commands` + -`koji COMMAND --help    # help on command COMMAND` - -link:Using the Koji build system[Using the Koji build system] has more -information about using Koji. - -[[make-a-package]] -=== Make a Package - -* If you don't know how to create an RPM package, see the -link:How to create an RPM package[How to create an RPM package]. -* Make sure that your package meets the Packaging:Guidelines[ Packaging -Guidelines] and Packaging:NamingGuidelines[ PackageNamingGuidelines] . -* Be aware of the Packaging:ReviewGuidelines[ Package Review Guidelines] -(they will be used during the package review). -* Make sure your package builds. This is surprisingly important, because -a significant number of submissions don't. - -[[upload-your-package]] -=== Upload Your Package - -Upload your SRPM and SPEC files onto the Internet somewhere so that -others can retrieve them. This can be anywhere accessible by a URL, but -it is important that the files be directly accessible, not hidden behind -some service that makes people wait to download things or redirects -through advertising pages. - -If you want to make ad-hoc builds available for users while you are -getting the package into the official repositories, consider using -https://copr.fedorainfracloud.org[Copr]. It is a light weight automated -build system that can create repositories using the SRPM you upload. You -can use this Copr space to point reviewers to your src.rpm and spec. - -[[create-your-review-request]] -=== Create Your Review Request - -Fill out this form: -https://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Fedora&format=fedora-review. - -* Before submitting your request, be sure there’s not a previous request -for the same package. There is a convenient search box on the -http://fedoraproject.org/PackageReviewStatus/[package review status -page]. -* Make sure that you put the *name of the package* (excluding version -and release numbers) in the '`Review Summary`' field, along with a very -*brief summary* of what the package is. -* Put a *description* of your package (usually, this can be the same -thing as what you put in the spec %description) in the -'`Review Description`' field. Include the *URLs* to your *SRPM* and -*SPEC* files. -* Explain in the ticket that this is your first package and you need a -sponsor. Also include any information that may help prospective -sponsors. If you've been active in other review work, include links. If -you're the upstream maintainer, be sure to say so. -* For bonus points, include a link to a successful koji build so that -everyone knows you did all of your homework. - -The review process is described in detail on the -link:Package Review Process[ Package Review Process] page. - -[[inform-upstream]] -=== Inform Upstream - -Fedora as a project prefers to link:Staying_close_to_upstream_projects[ -stay close to upstream]. Inform the developers that you are packaging -the software. You can do that by sending them an email introducing -yourself and pointing out the review request. This sets up the stage for -future conversations. They will usually advertise the fact that their -software is now part of Fedora or might want to inform you of important -bugs in the existing release, future roadmaps etc. - -[[introduce-yourself]] -=== Introduce yourself - -When a new package maintainer joins the Fedora Project, we request that -he/she introduces themselves on the Fedora mailing list. To sign up for -the list, visit the list's signup page. The primary purpose of this is -to begin the process of building trust by allowing the Fedora community -members to get to know you a bit more and increase the chances of your -review request being processed sooner. - -We want to break anonymity and foster real-world community within the -project. You are under no obligation to reveal personal secrets. The -objective is to establish a level of trust with yourself and the other -members of the project. But you should at least use your real name when -communicating with us. Also a brief description of who you are, your -motivations and perhaps a description of the software you have submitted -for review is advisable. - ------------------------------------------------------------- - -Subject: Self Introduction: - -Body: Add any information you believe is applicable -including past experience in free and open source projects, -a link to the review request you have filed and -a brief description of yourself. You can also post -your GPG key information if you want to. ------------------------------------------------------------- - -[[watch-for-feedback]] -=== Watch for Feedback - -Watch the Bugzilla report for your first package. You should get -notifications of changes by email. Fix any blockers that the reviewer(s) -point out. - -[[get-sponsored]] -=== Get Sponsored - -When the package is APPROVED by the reviewer, you must separately obtain -member sponsorship in order to check in and build your package. -Sponsorship is not automatic and may require that you further -participate in other ways in order to demonstrate your understanding of -the packaging guidelines. Key to becoming sponsored is to convince an -existing sponsor-level member that you understand and follow the -project's guidelines and processes. - -See link:how to get sponsored into the packager group[how to get -sponsored into the packager group] for more information on the process -of becoming sponsored. - -Your sponsor can add you to the packager group. You should receive email -confirmation of your sponsorship. - -[[add-package-to-source-code-management-scm-system-and-set-owner]] -=== Add Package to Source Code Management (SCM) system and Set Owner - -Before proceeding, please sync your account by login on -https://src.fedoraproject.org/ using your FAS credentials. - -If you are becoming a maintainer for a new package, instead of being a -co-maintainer, use the https://pagure.io/fedrepo_req[fedrepo-req] tool -to request a new git repository for your package. The README file for -fedrepo-req has instructions for configuring and using the tool. - -The request will be reviewed and processed by an admin, usually within -24 hours. Once the ticket is processed, you will have access to commit -and build the package. - -[[check-out-the-module]] -=== Check out the module - -You _could_ check out your module now, but before doing that, consider -doing `mkdir ~/fedora-scm ; cd ~/fedora-scm` - that way, all your files -are inside a single directory. Also, run `ssh-add`, so that you won't -have to keep typing in your key password. - -Now you are ready to checkout your module from the SCM: - ---------------------------- - fedpkg clone ---------------------------- - -Where `` should be replaced with the name of your package. - -[[test-your-package]] -=== Test Your Package - -Refer to Using_Mock_to_test_package_builds and -Using_the_Koji_build_system#Scratch_Builds for more information on -testing your package. Mock uses your local system while Koji command -line tool uses the Fedora build system server. - -[[import-commit-and-build-your-package]] -=== Import, commit, and build your package - -Now that you've checked out your (empty) package module with fedpkg, cd -into the module's master branch: - -`cd ` - -Run fedpkg to import the contents of the SRPM into the SCM: - -`fedpkg import PATH_TO_SRPM` - -`# Review Changes, press 'q' to stop; Revert with: git reset --hard HEAD` + -`git commit -m "Initial import (#XXXXXX)."` + -`git push` + -`fedpkg build` - -Obviously, replace `PATH_TO_SRPM` with the full path (not URL) to your -approved SRPM, and `XXXXXX` with the package review bug number. - -This imports into, commits, and builds only the *master* -(link:Releases/Rawhide[Rawhide]) branch. - -If the push fails with this kind of message: - -`W access for why DENIED to YOUR_ACCOUNT` + -`fatal: The remote end hung up unexpectedly` + -`Could not push: Command '['git', 'push']' returned non-zero exit status 128` - -Then you don't have the necessary rights to modify that package branch; -view https://src.fedoraproject.org/rpms/PACKAGE_NAME to request those -rights. - -For more information on using the Fedora package maintenance system, see -the link:Package maintenance guide[Package maintenance guide]. - -[[update-your-branches-if-desired]] -=== Update Your Branches (if desired) - -Branches are `f`# (formerly `F-`# and before that `FC-`#), `master`, -etc. So _f_ is the branch for Fedora . - -To switch to a branch first: - -`fedpkg switch-branch BRANCH (e.g. f``)` - -Merge the initial commit from master, creating an identical commit in -the branch: - -`git merge master` - -Push the changes to the server: - -`git push` - -Build the package: - -`fedpkg build` - -If there is another branch to work with repeat "To switch to a branch" -and import and commit to each branch. - -If everything goes well, it should queue up your branch for building, -the package will cleanly build, and you're done! - -If it fails to build, the build system will send you an email to report -the failure and show you to the logs. Commit any needed changes to git, -bump the SPEC release number, and request a new build. - -[[submit-package-as-update-in-bodhi]] -=== Submit Package as Update in Bodhi - -The Fedora update system called Bodhi is used for pushing updates, -classifying packages etc. Do not submit Rawhide (master branch) builds -via Bodhi. - -You can push an update using Bodhi via the command line using this in -each branch: - -`fedpkg update` - -See the link:Package_update_HOWTO[update submission guide] for more -details. - -[[make-the-package-available-in-comps-files]] -=== Make the package available in "comps" files - -If appropriate for the package, make it available in "comps" files so -that it can be selected during installation and included in dnf's|yum's -package group operations. See link:PackageMaintainers/CompsXml[How to -use and edit comps.xml for package groups] for more info. - -[[watch-for-updates]] -=== Watch for updates - -Fedora has infrastructure available for monitoring new upstream releases -of the software you are packaging. Refer to -link:Upstream Release Monitoring[Upstream Release Monitoring] for more -details. - -[[getting-help]] -== Getting Help - -We know that this process can be as clear as mud sometimes, and we're -always trying to make it better. If you run into any problems, or have -any questions, please ask on the mailing list or in on freenode.net. - -[[getting-a-new-package-into-fedora-package-collection-for-existing-maintainers]] -== Getting a new package into Fedora Package Collection for existing -maintainers - -If you already maintain a package in Fedora and want to maintain -another, follow the -link:new package process for existing contributors[new package process -for existing contributors] . - -[[one-off-contributions]] -= One-off contributions - -Changes to https://src.fedoraproject.org/browse/projects/[existing -packages] can be suggested by submitting -https://docs.pagure.org/pagure/usage/pull_requests.html[pull requests]. -You must have a -link:Join_the_package_collection_maintainers#Create_a_Fedora_Account[Fedora -account] to create a pull request. - -If https://pagure.io/fedora-infrastructure/issue/6361[your account is -not in the 'packager' group, you cannot push changes to forks on -src.fedoraproject.org] so you must use an external Git hosting platform -(e.g. https://pagure.io/new) and use -https://docs.pagure.org/pagure/usage/pull_requests.html#remote-git-to-pagure-pull-request[remote -pull-requests]. - -Category:Package Maintainers[Category:Package Maintainers] Category:Join diff --git a/content/en-US/old/new-package-process-for-existing-contributors.adoc b/content/en-US/old/new-package-process-for-existing-contributors.adoc deleted file mode 100644 index d2a4a72..0000000 --- a/content/en-US/old/new-package-process-for-existing-contributors.adoc +++ /dev/null @@ -1,113 +0,0 @@ -= new package process for existing contributors -This is a short version of the PackageMaintainers/Join document, -streamlined to show how existing contributors can make new packages. - -*Step 1:* Read the Packaging:Guidelines[ Packaging Guidelines] and -Packaging:NamingGuidelines[ Package Naming Guidelines] . Really. Be -comfortable with them. + -*Step 2:* Make a package. - -* You should make sure that it is a new package. A list of existing -packages in Fedora Packages is here: -https://src.fedoraproject.org/projects/rpms/* -* Some information on how to create an RPM package is in the -link:PackageMaintainers/CreatingPackageHowTo[ Creating Package HOWTO] -* Make sure that your package meets the Packaging:Guidelines[ Packaging -Guidelines] and Packaging:NamingGuidelines[ Package Naming Guidelines] -* Be aware of Forbidden_items and Packaging:ReviewGuidelines[ Package -Review Guidelines] (they will be used during the package review) - -*Step 3:* Upload your SRPM and SPEC files onto the internet somewhere. + -* If you have already got a Fedora Account then you can use your storage -at http://fedorapeople.org for this. *Step 4:* Make sure you have a -bugzilla account at bugzilla.redhat.com + -*Step 5:* Fill out this form: -https://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Fedora&format=fedora-review - -* Make sure you put the name of the package in the Review Summary field, -along with a very brief summary of what it is -* Make sure that you put the URL paths for the SPEC file and the SRPM -file in the Review Description -* Put a description of your package (usually, this can be the same thing -as what you put in the spec %description) in Review Description -* The review process is described in detail here: -Packaging:ReviewGuidelines[ Package Review Guidelines] - -*Step 6:* Watch the bugzilla report for your first package (you created -this in step 5). Fix any blockers that the reviewer(s) point out. + -*Step 7:* When the package is approved by the reviewer, request a git -module and branches using -`fedpkg --module-name PACKAGE request-repo TICKET` and -`fedpkg --module-name PACKAGE request-branch BRANCH` (see -https://fedoraproject.org/wiki/Changes/fedrepo-req-to-fedpkg[1]) + -* Please wait until the request is approved. *Step 8:* Once the request -is approved, checkout the git module (details -link:Join_the_package_collection_maintainers#Check_out_the_module[here]) - -* Once you have the git module, checkout your module from git. Refer to -the link:Package maintenance guide[Package maintenance guide] -* It is probably a good idea to make a "git" toplevel directory, then -check-out your files inside of that. -* If your package is named foobar, this is done with: fedpkg clone -foobar - -*Step 9:* Import your srpm - -* First kinit username@FEDORAPROJECT.ORG -* Then you can import the approved SRPM into master branch by running -` fedpkg import libfoo-x.x.x.src.rpm; git commit -m "Initial import (#nnnnnn)."` -(where nnnnnn is your Bugzilla package review bug number). -* Obviously, replace libfoo-x.x.x.src.rpm with the full path to your -approved SRPM. -* You should see it upload the sources, and finish successfully. If you -didn't set up ssh-agent it will ask often for your ssh-key passphrase. -This is normal. -* Now run git push to get the final versions in your master branch. - -*Step 10:* You can now import the package to your branches (which you -has requested in Step 7) too - -* The quickest way to do this is to use `fedpkg switch-branch BRANCH` to -switch the branch (where BRANCH can be "f13" and so on). -* Now you can `git merge master`. This will get .spec file, .gitignore -and source file together with any patches and other files from master -branch and create identical commit. -* Previous step already created commit for you, now you can push the -results using `fedpkg push` or `git push`. - -*Step 11:* Request builds - -* For each branch that you'd like to request a build for, switch using -fedpkg switch-branch and run: `fedpkg build` -* If everything goes well, it should queue up your branch for building, -the package will cleanly build, and you're done! -* If it fails to build, the buildsystem will send you an email to report -the failure and link you to the logs. Commit any needed changes to git, -bump the spec release number and request a new build. - -*Step 12:* Close the bugzilla ticket (assuming that the package built -successfully) - -* You should close it with resolution NEXTRELEASE or RAWHIDE, depending -on where you built the package. The resolution field will appear after -you set the status field to CLOSED. - -*Step 13:* If this package will be built for any version of Fedora that -is already released please submit it for inclusion in the -'fedora-updates' repository for those versions of Fedora. See -link:Package_update_HOWTO#Later_Branched_and_stable_releases[the update -submission guide] for more details. + -*Step 14:* Add the package to the link:PackageMaintainers/CompsXml[comps -file(s)] if appropriate. + -*Step 15:* Consider enabling link:Upstream Release Monitoring[Upstream -Release Monitoring] for the package. - -We know that this process can be as clear as mud sometimes, we're always -trying to make it better. If you run into any problems, or have any -questions, please ask on fedora development list. + - http://lists.fedoraproject.org/pipermail/devel/ - -There is a helpful link:Package maintenance guide[Package maintenance -guide] which may also be of use. - -Category:Package Maintainers[Category:Package Maintainers] diff --git a/content/en-US/old/package-maintenance-guide.adoc b/content/en-US/old/package-maintenance-guide.adoc deleted file mode 100644 index a2f49bd..0000000 --- a/content/en-US/old/package-maintenance-guide.adoc +++ /dev/null @@ -1,369 +0,0 @@ -= package maintainence guide -This page provides some basic instructions for day-to-day usage of the -http://git-scm.com/[git]-based package maintenance system for Fedora. It -is intended primarily for new and current Fedora package maintainers, -but does briefly link:#anon[cover anonymous read-only use of the -system]. It is not a guide to RPM packaging per se. Some pre-existing -knowledge of git may be useful, but is not a pre-requisite (in fact, -Fedora packaging can be a relatively painless introduction to it). - -You may have been looking for, or also be interested in: - -* link:How_to_create_an_RPM_package[Learning to create packages] -* link:Join_the_package_collection_maintainers[Becoming a package -maintainer] -* link:Package_update_HOWTO[Submitting package updates] -* link:New_package_process_for_existing_contributors[Adding a new -package to the repository] as an existing maintainer -* -link:PackageDB_admin_requests#Additional_branches_for_existing_packages[adding -a new release branch] to an existing package -* Packaging:Guidelines[The Packaging Guidelines] - -[[installing-fedpkg-and-doing-initial-setup]] -== Installing _fedpkg_ and doing initial setup - -Start by installing with . This will also install the tool, which will -be your primary interface to the packaging system. Run to configure your -machine for package maintenance. If you have run before, but wish to set -up a new machine, copy the files to the new system. - -You also must have an ssh key configured in the -https://admin.fedoraproject.org/accounts/[Fedora Accounts System] to be -able to make changes to any package (including your own). fedpkg will -expect the correct ssh key to be available in your keyring. - -Before uploading sources with `new-sources` and `upload` and building -packages in Koji, with `build` for example, you have to get your -Kerberos credential first with `kinit`, e.g. - -` kinit [FAS name]@FEDORAPROJECT.ORG` - -(Keep FEDORAPROJECT.ORG in capital case) - -[[common-fedpkg-commands]] -== Common fedpkg commands - -This section lists typical fedpkg commands in a normal workflow, with -short descriptions. Longer explanations for each can be seen by clicking -the 'Show' links. In this workflow, we will be operating on the -link:Releases/Rawhide[Rawhide] branch of the package. - -* Check out a package: - -`fedpkg co ` + -`cd ` - -* Update your checked-out copy from the Fedora server: - -`fedpkg pull` - -* Retrieve the package sources: - -`fedpkg sources` - -* Make your changes to the package - -* Run the 'prep' stage (extract source, apply patches etc) within the -checkout directory: - -`fedpkg prep` - -* Do a local build of the current state: - -`fedpkg local` - -* Do a mock build of the current state: - -`fedpkg mockbuild` - -* Generate a .src.rpm from the current state: - -`fedpkg srpm` - -* Do a scratch build using koji: see -https://fedoraproject.org/wiki/Using_the_Koji_build_system#Scratch_Builds[Koji -scratch builds] -* Check changes you have made: - -`fedpkg diff` - -* Run some checks (rpmlint) on your package: - -`fedpkg lint` - -* Stage any small patches or new source files for commit: - -`git add (somefile)` - -* Upload new source files to the lookaside cache: - -`fedpkg new-sources` - -`fedpkg upload` - -* Switch to a different release branch: - -`fedpkg switch-branch ` - -* Generate git changelog from package changelog: - -`fedpkg clog` - -* Commit changes: - -`fedpkg commit (-F clog) (-p) (-c)` - -* Push changes: - -`fedpkg push` - -* Do an 'official' build of the latest pushed changes: - -`fedpkg build` - -* In the event you are working with a Docker -link:Changes/Layered_Docker_Image_Build_Service[Container Layered Image -Build] - -`fedpkg container-build` - -* Submit a package update for the latest build: - -`fedpkg update` - -[[typical-fedpkg-session]] -== Typical _fedpkg_ session - -A typical session may look like this: - ---------------------------------------------------------------------------- -fedpkg clone foo -cd foo -fedpkg sources -fedpkg new-sources foo-0.0.2.tar.bz2 -gedit foo.spec # change the required things in the specfile. - # rpmdev-bumpspec is useful for simple version updates -fedpkg mockbuild # check that the changes you made are correct -fedpkg diff -fedpkg lint -fedpkg commit -p -c # commit and push in one go ---------------------------------------------------------------------------- - -[[working-with-branches]] -== Working with branches - -Each Fedora release is represented by a branch in the git repository. -You can switch between them like this: - -`fedpkg switch-branch f` + -`fedpkg switch-branch f` + -`fedpkg switch-branch master` - -The _master_ branch is for link:Releases/Rawhide[Rawhide]. You can -maintain each branch entirely separately, if you like, laboriously -copying changes between them (so long as you always stay within the -link:Updates Policy[Updates Policy] requirements). However, git provides -us with several handy tools for working with branches. Here's an -example: This will 'merge' the changes from the _master_ (Rawhide) -branch to the f branch. git aficionados may note this is a somewhat -unusual workflow, but it is appropriate to the context of package -management. Remember, after pushing to and building for a stable release -or a link:Releases/Branched[Branched] release after -link:Updates Policy#Bodhi_enabling[Bodhi has been enabled], you will -have to link:Package_update_HOWTO[submit an update] before any other -Fedora users will see your build. - -Note that merges will only be sure to work cleanly so long as the -branches have not previously diverged. That is, if you do this: you may -encounter a _merge conflict_. - -Remember that git is a _collaborative_ system, and used as such in -Fedora package management. It is often the case that you must consider -changes made by others in working on a package, and consider how your -changes will affect others. - -[[resolving-merge-conflicts]] -=== Resolving merge conflicts - -This is a large topic and somewhat beyond the scope of this guide, but -we can give basic pointers. There are other good references in the -http://git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging[git -book] and at -https://help.github.com/articles/resolving-a-merge-conflict-from-the-command-line[github]. - -When you git merge and a conflict occurs you can edit the files that -have conflicts. Remove the conflict markers in the files and merge the -changes manually. Use or to inspect the changes against the pre-conflict -state and verify you are happy with the resolution. Then you can commit -the files with or . git will know if you have resolved the conflict by -checking that all the conflict markers have been removed. - -[[using-git-mergetool-to-resolve-conflicts]] -=== Using `git mergetool` to resolve conflicts - -Git provides a graphical diff program to help resolve conflicts. This -can be handy for visualizing what changes have occurred and dealing with -them as a set. - -[[requesting-special-dist-tags]] -== Requesting special dist tags - -When a change to a package affects a large number of dependencies (e.g. -all perl, python, ruby or ghc packages), requiring them to be rebuilt, -it may be better to initially do the builds in a special repository, so -that there is less disruption in Rawhide. - -If you think you have an update that falls under this case you can -request a special dist tag by filing a -https://fedorahosted.org/rel-eng/newticket[release engineering ticket]. -Someone from link:ReleaseEngineering[release engineering] will likely -want to discuss your needs to make sure this is really an appropriate -case (it's OK ask if you aren't sure) and that you get what you need. - -[[tips-and-tricks]] -== Tips and tricks - -[[using-fedpkg-anonymously]] -=== Using fedpkg anonymously - -You can use fedpkg like this: - -`fedpkg clone --anonymous ` - -to check out a package without requiring identification. Obviously, you -will not be able to push any changes to this repository, but it is -useful for non-packagers who simply want to examine a package, make -changes for their own use, and perhaps submit changes to a Fedora -developer. - -[[local-branch-names]] -=== Local branch names - -If you use git commands to branch and checkout directly, you can define -whatever local branch names you want. If you use , it will default to -creating the names used in the examples above. - -[[current-branch-and-state-in-shell-prompt]] -=== Current branch and state in shell prompt - -It is often helpful to know what branch you are working on at a glance. -You can add this information to your bash prompt with the information -link:Git_Quickref#Display_current_branch_in_bash[here]. - -[[importing-a-.src.rpm-to-update]] -=== Importing a .src.rpm to update - -The command usually used to initially populate a git package repository -from a .src.rpm that has been through the -link:Package Review Process[Package Review Process] can also be used to -update a normal working copy, if you have an old-school packaging -process to which you are particularly attached. Just run and it will -upload new tarballs into lookaside cache, update a working copy of the -last version found in git, and commit all changes. documents some other -parameters it can accept. - -[[making-changes-on-an-older-branch-without-breaking-the-upgrade-path]] -=== Making changes on an older branch without breaking the upgrade path - -Here is the scenario: you've built your package successfully on the __ -branch, but there is a problem keeping your package from building on __. - -Solution: make your changes in the branch and then add a digit to the -very right of the release tag. There is no need to change the release in -the other branches. This allows upgrades to work smoothly if the user -upgrades to a newer release of Fedora. - --------------------- -Name: foo -Version: 1.0 -Release: 1%{?dist} - -Name: foo -Version: 1.0 -Release: 1%{?dist}.1 --------------------- - -Then tag and build as usual. This approach was initially discussed -https://www.redhat.com/archives/fedora-extras-list/2006-May/msg00083.html[in -this mailing list thread]. - -[[removing-a-package-build-pending-for-rawhide-or-branched]] -=== Removing a package build pending for link:Releases/Rawhide[Rawhide] -or link:Releases/Branched[Branched] - -From time to time you may want to remove a package build you submitted -to Rawhide or to Branched prior to the Alpha freeze (both cases where -the build would usually go out to the main link:Repositories[repository] -without further gating). This could happen in a situation where a bug or -issue is found in your package that will be resolved upstream in the -next release, or you realize you made a significant mistake in the build -that cannot easily be corrected. - -You can remove the package by using Koji: - -where is replaced with the name of your package build. See or -link:Using_the_Koji_build_system[using Koji] for more information. - -[[ssh-fingerprint]] -=== ssh fingerprint - -The recommended option is to include "`VerifyHostKeyDNS yes`" in your -~/.ssh/config file. This will result in using DNS to check that the key -is correct. - -But you can also manually check against the list of keys at -https://admin.fedoraproject.org . The strings there are what ends up in -your ~/.ssh/known_hosts file. So you can accept the fingerprint when -prompted and then check that the correct string for -pkgs.fedoraproject.org ended up in your ~/.ssh/known_hosts file. - -[[problems-connecting-to-the-repository]] -=== Problems connecting to the repository - -The _fedpkg_ tool clones repositories using the ssh:// protocol, so this -should not be a problem normally (as long as you have your ssh key). If -you cloned using the _git_ utility itself, check the file to ensure the -remote repository is being accessed via an ssh:// protocol, and not -git://. - -[[expired-certificates-error-255-or-openssl.ssl.error]] -=== Expired certificates (Error 255 or OpenSSL.SSL.Error) - -This error usually means that your client certificate (~/.fedora.cert) -has expired, so you need to run fedora-cert to get a new one. If you -have trouble with this, you may try removing and re-running . - -[[it-builds-here-why-doesnt-it-build-there]] -=== It builds here, why doesn't it build there? - -Is your package building locally - even with Mock, even as a scratch -build! - but not when you run ? Before you get too frustrated, remember -runs on the package as it exists in the upstream repository, not your -local working copy. Make sure you have committed and pushed all changes -and source files, and handled the lookaside cache correctly. Other -issues that have been reported, are issues because of -https://bugzilla.redhat.com/show_bug.cgi?id=1179139[build/make check -parallelization] and failures because of test suites that depend on -operations finish on precise timing (and a busy build system may not be -able to perform operations on time). - -[[references]] -== References - -* http://pkgs.fedoraproject.org/cgit/ -* Infrastructure/Kerberos -* link:Package SCM admin requests[Package SCM admin requests] -* Package_Renaming_Process -* PackageMaintainers/PackagingTricks -* Package_update_HOWTO -* -PackageMaintainers/BuildSystemClientSetup#Install_the_Client_Tools_.28Koji.29 -* PackageMaintainers/MockTricks#How_do_I_use_Mock.3F -* Using_the_Koji_build_system -* Package_Review_Process -* Fedora_Release_Life_Cycle -* PackageMaintainers/Join -* Infrastructure/VersionControl/dist-git - -Category:Package Maintainers[Category:Package Maintainers] diff --git a/content/en-US/old/package-review-process.adoc b/content/en-US/old/package-review-process.adoc deleted file mode 100644 index 1bdd212..0000000 --- a/content/en-US/old/package-review-process.adoc +++ /dev/null @@ -1,265 +0,0 @@ -[[review-purpose]] -= Review Purpose - -In order for a new package to be added to Fedora, the package must first -undertake a formal review. The purpose of this formal review is to try -to ensure that the package meets the quality control requirements for -Fedora. This does not mean that the package (or the software being -packaged) is perfect, but it should meet baseline minimum requirements -for quality. - -Reviews are currently done for totally new packages, -link:Package_Renaming_Process#Re-review_required[package renames], old -packages that were once deprecated returning to the collection, and -packages merged from the old Fedora Core repository. - -Note that some new packages may be exempt from the review process. -Please see Packaging:ReviewGuidelines#Package_Review_Process for a list -of criteria. If an exemption is warranted, the contributor can skip -directly to step 8 of the process: filing a -link:PackageDB_admin_requests[request] in the package database. But note -that a bugzilla ticket will still be required in order to complete that -process; please use rhbug:1376885[this bug] for this purpose and follow -the instructions there. - -[[review-process]] -== Review Process - -There are two roles in the review process, that of the contributor and -that of the reviewer. In this document, we'll present both perspectives. - -[[contributor]] -=== Contributor - -A Contributor is defined as someone who wants to submit (and maintain) a -new package in Fedora. To become a contributor, you must follow the -detailed instructions to -link:Join the package collection maintainers[Join the package collection -maintainers]. - -As a Contributor, you should have already made a package which adheres -to the Packaging:NamingGuidelines[ Package Naming Guidelines] and -Packaging:Guidelines[ Packaging Guidelines]. There are also some -packages that cannot be included in Fedora, to check if your package -applies, check if it contains any link:Forbidden items[Forbidden items]. - -When you're happy with your spec file, you should then submit that SRPM -to a package review. Currently, this is done by following these steps: - -* Put your spec file and SRPM somewhere on the Internet where it can be -directly downloaded (just HTTP(s), no registration pages or special -download methods, please). If you have no place to put your spec and -SRPM, use copr: https://copr.fedorainfracloud.org/[1]. -* Fill out a -https://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Fedora&format=fedora-review[request -for review in bugzilla]. For guidance, a -:Image:PackageReviewProcess_review.png[screenshot of a sample bugzilla -request is available for review]. - -image:PackageReviewProcess_review.png[PackageReviewProcess_review.png,title="PackageReviewProcess_review.png"] - -* If you do not have any package already in Fedora, this means you need -a sponsor and to add FE-NEEDSPONSOR (Bugzilla id:177841) to the bugs -being blocked by your review request. For more information read the -link:How to get sponsored into the packager group[How to get sponsored -into the packager group] wiki page. -* Wait for someone to review your package! At this point in the process, -the *fedora-review* flag is blank, meaning that no reviewer is assigned. - -* There may be comments from people that are not formally reviewing the -package, they may add NotReady to the Whiteboard field, indication that -the review request is not yet ready, because of some issues they report. -After you have addressed them, please post the URLs to the updated SPEC -and SRPM file and remove it from the Whiteboard. It is expected that you -will respond to commentary, including updating your submission to -address it; if you do not, your ticket will be closed. -* A reviewer takes on the task of reviewing your package. They will set -the *fedora-review* flag to *?* -* The reviewer will review your package. You should fix any blockers -that the reviewer identifies. Once the reviewer is happy with the -package, the *fedora-review* flag will be set to *+*, indicating that -the package has passed review. -* If you have not yet been sponsored, you will not be able to progress -past this point. -* When your package pass the review, you should use the fedpkg tool to -request a git repository for it. Before doing that you will need your -https://pagure.io/fedrepo_req[pagure_api_token] configured and added -into `~/.config/rpkg/fedpkg.conf` - -`[fedpkg.pagure]` + -`token = whatever` - -For example, if your bugzilla review ticket is 12345 and you want your -package in Fedora 27, use: -`fedpkg --module-name request-repo 12345` - -* As following, if you want to add your package into more Fedora -releases, you can use the following command to request additional -branches: `fedpkg --module-name request-branch f27` -* When this is complete (tickets in Paquire for requests above are -closed as processed), you can -link:Join_the_package_collection_maintainers#Import.2C_commit.2C_and_build_your_package[import -your SRPM package] into the SCM. -* Checkout the package using `fedpkg clone ` do a final -check of spec file tags, etc. -* Request a Koji build by running `fedpkg build`. (You will need to set -up link:Infrastructure/Kerberos[Kerberos for Fedora project]) -* Repeat the process for other branches you may have requested above: -** Checkout given branch: `fedpkg switch-branch f26` -** Lets Koji build the package for this branch: `fedpkg build` -* Request updates for Fedora release branches, if necessary, using -`fedpkg update` or another Bodhi interface as detailed in Bodhi. -* If possible, add your package to -link:Upstream_release_monitoring[Upstream Release Monitoring]. -* You should make sure the review ticket is closed. You are welcome to -close it once the package has been built on the requested branches, or -if you built for one of the Fedora release branches you can ask Bodhi to -close the ticket for you when it completes the process. If you close the -ticket yourself, use *NEXTRELEASE* as the resolution. - -You do not need to go through the review process again for subsequent -package changes, and should not reference the review ticket in -subsequent updates you create in Bodhi. - -[[reviewer]] -=== Reviewer - -The Reviewer is the person who chooses to review a package. - -The Reviewer can be any Fedora account holder who is a member of the -[https://admin.fedoraproject.org/accounts/group/members/packager/* -packager group]. (If the Contributor is not yet sponsored, the review -can still proceed to completion but they will need to find a sponsor at -some point.) - -* Search for a review request that needs a reviewer: -http://fedoraproject.org/PackageReviewStatus/ (*fedora-review* flag is -blank or the bug is assigned to nobody@fedoraproject.org) -* If you notice some issues that need to be solved before you want to -start a formal review, add these issues in a comment and set the -Whiteboard of the bug to contain NotReady. This helps other possible -reviewers to notice that the review request is not yet ready for further -review action. -* if you want to formally review the package, set the *fedora-review* -flag to *?* and assign the bug to yourself. - -* Review the package ... -** Go through the MUST items listed in Packaging:ReviewGuidelines[ -Review Guidelines] . -** Go through the SHOULD items in Packaging:ReviewGuidelines[ Review -Guidelines] . -** The https://fedorahosted.org/FedoraReview/[FedoraReview] tool -(packaged as fedora-review) can help to automate this process. -* Include the text of your review in a comment in the ticket. For easy -readability, simply use a regular comment instead of an attachment. -* Take one of the following actions: -** *ACCEPT* - If the package is good, set the *fedora-review* flag to -*+* - -* ** *FAIL, LEGAL* - If the package is legally risky for whatever reason -(known patent or copyright infringement, trademark concerns) close the -bug WONTFIX and leave an appropriate comment (i.e. we don't ship mp3, so -stop submitting it). Set the *fedora-review* flag to *-*, and have the -review ticket block FE-Legal. -** *FAIL, OTHER* - If the package is just way off or unsuitable for some -other reason, and there is no simple fix, then close the bug WONTFIX and -leave an appropriate comment (i.e. we don't package pornography for -redistribution, sorry. Or, this isn't a specfile, it's a McDonald's -menu, sorry.) Set the *fedora-review* flag to *-*. -** *NEEDSWORK* - Anything that isn't explicitly failed should be left -open while the submitter and reviewer work together to fix any potential -issues. Mark the bug as NEEDINFO while waiting for the reviewer to -respond to improvement requests; this makes it easier for reviewers to -find open reviews which require their input. - -[[definitions-for-fedora-review-flag-settings]] -== Definitions for fedora-review Flag Settings - -[cols=",,",] -|======================================================================= -|fedora-review |(BLANK) |Package Needs Review - -|fedora-review |? |Package Under Review - -|fedora-review |- |Package Failed Review, dropped for legal or other -issues. - -|fedora-review |+ |Package Approved -|======================================================================= - -[[special-blocker-tickets]] -== Special blocker tickets - -There are a few tickets which can be placed in the "Blocks" field to -indicate specific ticket statuses: - -[cols=",",] -|======================================================================= -|FE-NEEDSPONSOR |The submitter requires a sponsor; the review can be -done by anyone, but a sponsor will need to come and sponsor the -submittor. - -|FE-DEADREVIEW |The review has been closed out because the submitter has -left; users looking for packages to submit may find some possibilities -in these dead tickets. - -|FE-Legal |The package is currently awaiting review by the legal team. -|======================================================================= - -[[the-whiteboard]] -== The Whiteboard - -To save time for reviewers, the page at -http://fedoraproject.org/PackageReviewStatus/NEW.html will hide certain -tickets which are not reviewable. The Whiteboard field can be used to -mark a ticket with various additional bits of status which will cause it -to be hidden or displayed differently. - -[cols=",",] -|======================================================================= -|NotReady |The package is not yet ready for review. It is possible to -open a review ticket, mark it as NotReady, and continue to work on it -until it's ready to be seen by a reviewer. - -|BuildFails |The package fails to build. - -|AwaitingSubmitter |The package review is stalled and cannot proceed -without input from the submitter. - -|Trivial |The package is trivial to review. See below. -|======================================================================= - -The "Trivial" status is intended to indicate packages which, as an aid -to new reviewers, are especially uncomplicated and easy to review. A -ticket should not be marked as being trivial unless: - -* The package is known to build and a link to a scratch build is -included. -* The ticket explains any rpmlint output which is present. -* The spec contains nothing which is unnecessary in modern Fedora (such -as BuildRoot:, a %clean section or %defattr). -* The spec is free from excessive or complicated macro usage. -* The spec uses only the least complicated scriptlets which are taken -directly from the Packaging:Scriptlets page. -* The package contains no daemons. -* The package is not especially security sensitive. -* The code has undergone a thorough inspection for licensing issues. -Anomalies which would be found by licensecheck should be explained. - -In short, this should be reserved only for those tickets which should be -easily approachable by someone doing their first package review. - -[[tracking-of-package-requests]] -== Tracking of Package Requests - -The http://fedoraproject.org/PackageReviewStatus[cached Package Review -Tracker] provides various review-related reports and a simple way to -search for reviews by package name or reporter name or others. - -[[authorship]] -== Authorship - -This document was originally authored by link:TomCallaway[Tom 'spot' -Callaway] in 2007 and has since been modified by many others. - -Category:Package Maintainers[Category:Package Maintainers] diff --git a/content/en-US/old/package-update-howto.adoc b/content/en-US/old/package-update-howto.adoc deleted file mode 100644 index 9493b6d..0000000 --- a/content/en-US/old/package-update-howto.adoc +++ /dev/null @@ -1,344 +0,0 @@ -= package update howto -This document shows how to submit an update for a package you maintain -in Fedora. It assumes you already have a package in the Fedora -repositories. It is not a guide to using the Fedora package source -control system: see the link:Package maintenance guide[Package -maintenance guide] for that. - -* For details of the policy on requirements for updates at various -stages of the link:Fedora Release Life Cycle[Fedora Release Life Cycle], -refer to link:Updates Policy[Updates Policy]. - -[[overview]] -== Overview - -This page is intended for new and existing package maintainers. Testers -and regular users may be interested in the -QA:Updates_Testing[updates-testing] repository and the -QA:Update_feedback_guidelines[update feedback guidelines]. This page -specifically covers the update submission process. - -There are two significantly different package update submission -workflows in Fedora: - -* link:Releases/Rawhide[Rawhide], and link:Releases/Branched[Branched] -up to the link:Updates Policy#Bodhi_enabling[Bodhi enabling point] -* link:Releases/Branched[Branched] releases after the Alpha change -deadline, and stable releases - -The repository layouts differ somewhat for Rawhide, Branched and stable -releases, but the update workflows split up as described above. - -[[rawhide-and-early-branched]] -== Rawhide and early Branched - -The package update workflow for Rawhide and Branched before the _Bodhi -enabling point_ is simple: - -1. Build the package with (see the -link:Package maintenance guide[Package maintenance guide] for more -details) - -This is all you need to do. Your package will appear in the next daily -compose of Rawhide or Branched and will be used in any image composes -built from that tree. - -[[later-branched-and-stable-releases]] -== Later Branched and stable releases - -At the link:Updates Policy#Bodhi_enabling[Bodhi enabling point], the -Bodhi update feedback system is enabled by -link:ReleaseEngineering[Release Engineering] and builds submitted with -are no longer automatically sent to any official -link:Repositories[repository]. The update workflow for releases of this -type is: - -1. Build the package with -2. Submit an update for the package with , the -https://admin.fedoraproject.org/updates/[Bodhi web interface], or the -https://fedorahosted.org/bodhi/wiki/CLI[Bodhi CLI tool]. This causes the -package to be sent to the -link:Repositories#updates-testing[_updates-testing_] repository -3. Monitor the update's status and the feedback you receive via the web -interface or the emails that are sent to you, and modify it with updated -or additional builds if necessary -4. After the update meets the criteria in the -link:Updates Policy[Updates Policy] and you are satisfied it should be -released as a stable update, submit the update to -_link:Repositories#stable[stable]_ with or the web interface - -[[update-attributes]] -=== Update attributes - -At the time you submit the update, you will be asked for several -attributes. The type of the update should be fairly self-explanatory: -either it fixes bugs, adds new features, or is a new package. - -If you are asked whether you want to send the update to -_updates-testing_ or _stable_, this is a no-op: all updates now go -through _updates-testing_. It does not matter what you choose. - -There are several schools of thought on filling out the update -description. Some would suggest you consider the target audience: for a -stable release, in particular, many Fedora users will see this text, and -many of them may not be particularly familiar with your package. -Consider not simply describing literally the changes in the update, but -explaining as if to an outsider why your are updating the package, what -benefits it will bring to them (if any), and anything they may want to -note in order to have a smooth update experience. - -If you associate one or more bug reports with your update, Bodhi will -post comments into Bugzilla to alert those following the bug reports -that an update is available. If you mark your update as fixing the -bug(s), Bodhi will move the report(s) through the *MODIFIED*, *ON_QA* -and *CLOSED ERRATA* states of the link:BugZappers/BugStatusWorkFlow[bug -workflow] as your update reaches various points in the process. Using -this mechanism can be very useful both for you and for users of your -package. - -You may set a _karma_ (feedback) level at which the update will -automatically be submitted to _stable_. This is optional. If you choose -to use it, please carefully consider an appropriate feedback level. For -a relatively obscure package which is quite stable, 1 or 2 may be an -appropriate value. For a popular, sensitive and complex package such as -or the , the default of 3 may be insufficient and a choice of 5 or even -10 may be appropriate. - -[[who-will-receive-your-update-when]] -=== Who will receive your update, when? - -When a release is in Branched state, the _updates-testing_ repository is -enabled by default so most users will see the package, but only packages -from the stable _fedora_ repository are used in building milestone -releases (Alpha, Beta and Final) and nightly images. - -Where a package goes when it is marked as _stable_ differs between -Branched and stable releases. In Branched releases, _stable_ packages -are pushed to the base _fedora_ repository. In stable releases, _stable_ -packages are pushed to the _updates_ repository. However, from the point -of view of the packager, this is an insignificant implementation detail. -For more details, see Repositories. - -When a release is in stable state, the _updates-testing_ repository is -disabled by default, but QA team members and others run with it enabled -in order to provide testing and Bodhi feedback. The main user population -will see your update only when it passes Bodhi, is marked as _stable_ -and reaches the _updates_ repository. - -[[updating-inter-dependent-packages]] -=== Updating inter-dependent packages - -If an update you wish to submit would cause a dependency issue of any -kind (a strict package dependency error, or simply another package -failing to operate correctly) if updated alone, you must not submit the -package as a single-package update. You must always collect all -inter-dependent or related packages together into a single multi-package -update, such that no user will face problems if they install all the -packages in the update together. - -For example: if you maintain a package _libfoo_ which the package _bar_ -depends on, and you need to update _libfoo_, you should check that _bar_ -continues to function correctly with the updated version of _libfoo_. If -it does not, you must ensure the appropriate changes are made to _bar_, -and include the updated _bar_ in your update along with the updated -_libfoo_. - -The _fedpkg_ tool does not handle multi-package updates. You can add -multiple packages to an update using the -https://admin.fedoraproject.org/updates/[Bodhi web application], or the -command line tool. You can pass as many package names as you like to the -to create a new multi-package update, or use to edit an existing update. - -It is possible you will run into problems with permissions when trying -to add builds of packages you do not have commit privileges for to an -update, or trying to add a build for a package you do have privileges -for to someone else's update. If you encounter a situation like this, -you should contact the link:ReleaseEngineering[release engineering] team -or a proven packager for help. - -You may need a _buildroot override_ to complete a multi-package update -successfully. For instance in the case described above, you may need to -rebuild _bar_ against the new _libfoo_ package and submit both packages -together as a multi-package update. However, in the normal course of -events, you would not be able to build another package against your new -_libfoo_ build until it reached the link:Repositories#stable[_stable_] -state. To resolve this dilemma, you can request a buildroot override, -which causes the _libfoo_ build to be included in the buildroot for a -short time in order to get the _bar_ package build done. - -You can request a buildroot override with bodhi: This would submit a -buildroot override with a duration of two days. Buildroot overrides are -usually granted within 15-30 minutes of submission. If you submit an -override request with the bodhi tool, it will suggest a command that -will let you monitor when the package appears in the buildroot, so you -can fire your dependent build at the appropriate time. - -You can also request buildroot overrides from the -https://admin.fedoraproject.org/updates/[Bodhi web application]. - -The link:Bodhi/BuildRootOverrides[buildroot override instructions] -explain the buildroot override process in more detail. - -[[handling-feedback-from-automated-tests]] -=== Handling feedback from automated tests - -Fedora's automated testing systems, Taskotron and OpenQA, may run -automated tests on your update. Several of the Taskotron/Tasks are -documented. The openQA tests are functional tests of some critical -Workstation and Server features. - -In the Bodhi web interface, updates have a _Automated Tests_ tab which -displays the results of all automated tests. Tests shown with a red -background failed. The tests are not all 100% accurate, but they are -fairly often correct. If you see a failure, it is a very good idea to -click on the result (which will take you to a detailed log) and -investigate the issue. If you are unsure what the test indicates, you -can contact the QA team for help. - -[[waive-a-result]] -==== Waive a result - -At present, a failure of the _dist.rpmdeplint_, _dist.abicheck_, or -_org.centos.prod.ci.pipeline.complete_ tests will prevent your update -from being released. On the update's _Details_ page in the Bodhi web -interface, the *Test Gating Status* will be shown as _N of N required -tests failed_. If you are sure such a failure is a false one, you can -'waive' the result using the tool, from the package (there is -https://github.com/fedora-infra/bodhi/pull/2095[work pending] to be able -to waiver more easily, directly from the Bodhi UI). - -You can submit a waiver for a failing result with specifying the and the -: - -  waiverdb-cli -t YOUR_TESTCASE_HERE \ - -s '{"item": "this-is-the-subject", "type": "also-this-is-part-of-the-subject"}' - -p "fedora-26" -c "This is fine" - -Example: - -  waiverdb-cli -t dist.rpmdeplint \ - -s '{"item": "python-requests-1.2.3-1.fc26", "type": "koji_build"}'  - -p "fedora-26" -c "This is fine" - -You can also waive a failing result by result's id, which you can -retrieve from resultsdb with curl. To do that, you'll need the name and -the . For example: - - curl "https://taskotron.fedoraproject.org/resultsdb_api/api/v2.0/results?testcases=dist.python-versions&item=python-alembic-0.9.7-1.fc27" | jq ".data[0].id" - -This should print out the of the failing result. You can then submit a -waiver for this failing result with - - waiverdb-cli -p fedora-27 -r YOUR_ID_HERE -c "This is fine." - -Also, if you enabled automatic stable push at a karma threshold, this -will be disabled if any automated test fails. If you have examined the -result and you are sure it is a false one and there is no problem with -the package, you may re-enable the automatic push mechanism or submit -the package to _stable_ manually once it meets the other requirements of -the link:Updates Policy[Updates Policy]. - -[[waive-the-absence-of-a-result]] -==== Waive the absence of a result - -Submitting a waiver using subject/testcase allows to waive the absence -of a result (eg. the test never ran for some reason, so there is no -result item). - -If which testcase you should be specified it is not clear/known, it is -possible to run this python script, chainging it with the corrects -parameter: - - #!/usr/bin/env python - """ Ask a question of greenwave.  """ - # Usage: either modify and set PRODUCT_VERSION and NVR_LIST and run,  - # or pass version as first arg and then NVRs as further args - import pprint - import requests - import sys - PRODUCT_VERSION = 'fedora-27' if len(sys.argv) == 1 else sys.argv[1] - NVR_LIST = [] or sys.argv[2:]  # Insert your NVRs here, or pass them via command line args - for nvr in NVR_LIST: -     url = ( -         'https://greenwave-web-greenwave.app.os.fedoraproject.org/' -         'api/v1.0/decision') -     payload = dict( -         #verbose=True, -         decision_context='bodhi_update_push_stable', -         product_version=PRODUCT_VERSION, -        subject=[{'item': nvr, 'type': 'koji_build'}], -     ) -     response = requests.post(url, json=payload) -     print("-" * 40) -     print(nvr, response, response.status_code) -     data = response.json() -     print(pprint.pformat(data)) - -The output will show that Greenwave is requiring a specific testcase to -run, but it cannot find a result for it (neither pass nor failure). So -now it is possible to submit a waiver with the specified testcase in the -output and the subject already known. - -[[troubleshooting]] -==== Troubleshooting - -If you run the tool and it gives you the following error: - -  Error: The config option "resultsdb_api_url" is required - -Edit and add the following line: - -  resultsdb_api_url=`https://taskotron.fedoraproject.org/resultsdb_api/api/v2.0 - -[[branched-milestone-freezes]] -=== Branched milestone freezes - -For a short period before each milestone release, the stable -link:Repositories#fedora[_fedora_] repository is frozen. These periods -are shown as the link:Milestone freezes[Milestone freezes] (Beta Freeze, -Final Freeze) on schedules. During these periods, builds will not be -marked _stable_ and pushed from -link:Repositories#updates-testing[_updates-testing_] to _fedora_ even -after being submitted manually or automatically. In the normal course of -events, they will be pushed after the milestone release is approved at a -Go_No_Go_Meeting. If you believe your update deserves to break a -milestone freeze, a _freeze exception_ may be granted through the -QA:SOP_freeze_exception_bug_process[freeze exception process]. Accepted -release blocking bugs are granted the same status through the -QA:SOP_blocker_bug_process[blocker bug process]. - -For more on the Fedora development process, see -link:Fedora Release Life Cycle[Fedora Release Life Cycle]. - -[[security-updates]] -== Security updates - -There is an additional process that layers over the regular update -process for bugs identified as security issues. If a bug is assigned to -you that blocks a link:Security Tracking Bugs[security tracking bug], -you must follow that process in addition to this one. - -[[new-package-submissions]] -== New package submissions - -If you want to build a new package, but you aren't sure which releases -to send it to: - -* New packages should always be built for Rawhide -* New packages can be built for Branched and stable releases if adding -them would provide value to users of those releases without significant -risk of causing harm - -The submission process for new packages, after they have passed the -Package_Review_Process and been link:Package_SCM_admin_requests[given an -SCM repository], is exactly the same as that for package updates. - -[[consider-creating-a-package-test-plan]] -== Consider creating a package test plan - -If you QA:SOP_test_case_creation[create test cases] for your package, -and QA:SOP_package_test_plan_creation[categorize them appropriately], -they will be automatically linked in Bodhi, so that testers will have -some guidance for planned update testing. - -Category:Package Maintainers[Category:Package Maintainers] diff --git a/content/en-US/old/what-happened-to-pkgdb.adoc b/content/en-US/old/what-happened-to-pkgdb.adoc deleted file mode 100644 index cfc0251..0000000 --- a/content/en-US/old/what-happened-to-pkgdb.adoc +++ /dev/null @@ -1,317 +0,0 @@ -[[why-pkgdb-is-being-decommissioned]] -= Why PkgDB Is Being Decommissioned - -In general, PkgDB works well for the current workflow of a package’s -lifecycle. Currently, a package has several branches that are tied to -Fedora releases such as “f24” or “f25”. These branches have implied -service levels (SLs) and end of life (EOL) dates based on the Fedora -release itself. Although the implied SLs and EOLs in these branches have -worked well for Fedora in the past, it’s becoming increasingly difficult -to juggle different application lifecycles and their dependencies’ -lifecycles under the umbrella of these limited number of SLs and EOLs, -especially when trying to keep up with upstream. In the past, we have -not been able to have different package lifecycles within a Fedora -release due to the nature of its design. With -https://docs.pagure.org/modularity/[Modularity], that will become a -reality, and Fedora packagers and module maintainers will need a new way -of branching in dist-git to enable this functionality. - -Since PkgDB was written with the old way of branching in mind, there -ended up being two logical paths forward. We could significantly rewrite -PkgDB to work with the new branching methodology, or we could migrate -PkgDB's existing functionality to other tooling. After talking with some -folks in the Fedora community, the latter seemed to be the right -approach because Fedora was moving to "Pagure over Dist-Git", and that -was going to duplicate and clash with a lot of PkgDB's functionality -anyways. - -[[how-is-pkgdbs-functionality-being-replaced]] -== How Is PkgDB's Functionality Being Replaced? - -PkgDB has two primary functions. It provides package repo ACLs, and -package related "admin requests" and "admin actions". After PkgDB will -be replaced, ACLs will be handled in -https://src.fedoraproject.org/[Pagure over Dist-Git (placeholder link)] -at the package level like you would handle a traditional code repository -on https://pagure.io/[pagure.io]. As for "admin requests" and "admin -actions", those will be replaced by a CLI tool called -https://pagure.io/fedrepo_req[fedrepo-req] (see: -https://fedorapeople.org/groups/factory2/sprint-032/mprahl-fedrepo-req-admin.mp4[a -demo]) that will submit JSON formatted tickets on your behalf to a -ticket queue in a specific Pagure project monitored by the Fedora -Release Engineering group. - -For more information on this or information on how other features in -PkgDB are being replaced, please read the "How To Make This Change" -section of the -https://fedoraproject.org/wiki/Infrastructure/Factory2/Focus/ArbitraryBranching[Arbitrary -Branching Focus Document] written by the Factory 2.0 team. - -[[helpfaqs]] -== Help/FAQs - -[[how-do-i-give-a-user-commit-access-to-a-dist-git-repo]] -=== How do I give a user commit access to a dist-git repo? - -1. Browse to your project on https://src.fedoraproject.org/[Pagure over -Dist-Git (Top Level link)] -2. Click 'browse' in the top right, to open a search box -3. Enter the package name and select the proper package from the -results -4. Click on "Settings" -5. Scroll down to "Users and Groups" -6. Click on "add user" -7. Type the username in the form -8. Select "commit" instead of the default of "ticket" to set the level -of access -9. Click "Add" - -[[how-do-i-request-commit-access-to-a-dist-git-repo]] -=== How do I request commit access to a dist-git repo? - -Email the PACKAGENAME-owner@fedoraproject.org alias asking to be given -access, or file a bugzilla bug on the package asking for access. - -[[how-do-i-request-a-new-package-or-a-new-branch]] -=== How do I request a new package or a new branch - -The ticketing functionality of PkgDB was replaced by a set of command -line tools called https://pagure.io/fedrepo_req[fedrepo-req], which are -packaged in Fedora and EPEL as -https://apps.fedoraproject.org/packages/fedrepo-req[`fedrepo-req`]. The -`fedrepo-req` command requests the creation of repositories for new -packages, and the `fedrepo-req-branch` command requests new branches for -existing packages. Please review the manual pages for information on -using these tools. - -Please note that new branch requests, when processed, will only cause -the creation of an entry in the PDC. You must then create the branch in -git manually. - -[[how-do-i-orphan-a-package]] -=== How do I orphan a package? - -Visit the package's repo in pagure and navigate to the settings for that -repo. I.e. - -https://src.fedoraproject.org/rpms/PACKAGE_NAME/settings - -Navigate down to the _Give Project_ section and "give" the project to -the "orphan" user. - -For completeness, under the _Users and Groups_ section, remove yourself -from the list. - -[[how-do-i-retire-a-package]] -=== How do I retire a package? - -Run _fedpkg retire_ in a local git checkout of the package's repo. - -[[how-can-i-watch-a-packages-commits]] -=== How can I watch a package's commits? - -Navigate to the project's repo: - -https://src.fedoraproject.org/rpms/PACKAGE_NAME - -* There should be a little icon with an eyeball in the top right. -* Click it. -* There should be a drop-down with various options for different kinds -of "watch" activity. -* The one you want should say "watch commits". - -[[how-can-i-get-added-to-the-cc-list-of-a-package-bug-reports]] -=== How can I get added to the CC list of a package bug reports? - -This used to be called "watchbugs" in pkgdb. Similar to "watchcommits", -which is addressed in the question above this one... - -Navigate to the project's repo: - -https://src.fedoraproject.org/rpms/PACKAGE_NAME - -* There should be a little icon with an eyeball in the top right. -* Click it. -* There should be a drop-down with various options for different kinds -of "watch" activity. -* The one you want is "watch issues and PRs". - -[[how-do-i-become-the-default-assignee-of-a-branch-in-bugzilla]] -=== How do I become the default assignee of a branch in bugzilla? - -File a pull-request on the -https://pagure.io/releng/fedora-scm-requests/blob/master/f/rpms[releng/fedora-scm-requests] -repo to add your FAS username. - -[[how-do-i-change-the-upstream-monitoringanitya-flag-for-my-packages]] -=== How do I change the upstream-monitoring/anitya flag for my packages? - -File a pull-request on the -https://pagure.io/releng/fedora-scm-requests/blob/master/f/rpms[releng/fedora-scm-requests] -repo to tweak the ``monitoring`` setting for your packages. - -[[how-do-i-transfer-ownership-of-a-package-to-someone-else]] -=== How do I transfer ownership of a package to someone else? - -Navigate to the project's repo's *settings* page: - -https://src.fedoraproject.org/rpms/PACKAGE_NAME/settings - -Scroll down to the "give project" section. There you can give the -package to someone else. - -[[how-do-i-adopt-an-orphaned-package-or-unretire-a-package]] -=== How do I adopt an orphaned package or unretire a package? - -For now, file a https://pagure.io/releng/issues[release engineering -ticket] with the name of the package, what you need done and in the case -of unretirement, the re-review of the package (if required). - -In the case of adopting an orphaned package, they should be able to give -it to you with the -https://pagure.io/releng/blob/master/f/scripts/distgit/give-package.py[give-package.py] -script. - -In the case of unretiring a package, they should follow the -https://docs.pagure.org/releng/sop_unretire.html[SOP for unretiring a -package]. - -[[how-do-i-find-out-who-owns-a-package]] -=== How do I find out who owns a package? - -1. Browse to the project on https://src.fedoraproject.org/[Pagure over -Dist-Git (placeholder link)] you are interested in -2. On the right side of the page, there is a heading called -"Contributors". Under that heading, there will be a username with "(main -admin)" displayed next to it. That is the owner of the package. - -[[how-do-i-find-out-the-list-of-orphaned-packages]] -=== How do I find out the list of orphaned packages? - -All orphaned packages will be owned by the "orphan" FAS user account in -https://src.fedoraproject.org/[Pagure over Dist-Git (placeholder link)]. - -You may use the user interface to view all the projects owned by the -"orphan" user, but this will include repos other than just packages -(like containers or modules): -https://src.fedoraproject.org/user/orphan[https://src.fedoraproject.org/user/orphan -(placeholder link)] - -You may use the REST API to view only the orphaned RPM repos by -visiting: -https://src.fedoraproject.org/api/0/projects?namespace=rpms&owner=orphan[https://src.fedoraproject.org/api/0/projects?namespace=rpms&owner=orphan -(placeholder link)] - -[[how-do-i-find-the-list-of-retired-packagesbranches-incomplete]] -=== How do I find the list of retired packages/branches? (incomplete) - -Retired branches are tracked in PDC by setting the "active" flag to -"false" on a branch. - -To view all packages with a master branch that is retired, you can visit -the following: -https://pdc.fedoraproject.org/rest_api/v1/component-branches/?active=false&type=rpms&name=master[https://pdc.fedoraproject.org/rest_api/v1/component-branches/?active=false&type=rpms&name=master] - -To view all retired package branches, you can visit the following: -https://pdc.fedoraproject.org/rest_api/v1/component-branches/?active=false&type=rpms[https://pdc.fedoraproject.org/rest_api/v1/component-branches/?active=false&type=rpms] - -To view all retired packages, a script will need to be written to query -PDC and perform a process of elimination. - -[[how-do-i-find-a-branchs-sls]] -=== How do I find a branch's SLs? - -A branch's SLs (termed SLA in PDC) are stored in the Product Definition -Center (PDC). An entry in PDC is required for a package to be used in a -module. As an example, if you wanted to view the Python package's SLs -for the 2.7 branch, you can visit the link below. You'll notice that the -URL contains three parameters to the request. The "type" is set to -"rpms", which filters the request down to just RPM packages. The -"global_component" is set to "python", which filters it down to only -branches belonging to any "python" component (e.g. an RPM, container, -module, etc). Lastly, the "name" is set to "2.7, which filters it down -to only "2.7" branches of components. All these filters together give -you a unique result of the Python 2.7 RPM branch. -https://pdc.fedoraproject.org/rest_api/v1/component-branches/?type=rpms&global_component=python&name=2.7[https://pdc.fedoraproject.org/rest_api/v1/component-branches/?type=rpms&global_component=python&name=2.7] - -[[how-do-i-find-what-sls-are-available-for-use]] -=== How do I find what SLs are available for use? - -All available SLs are defined in the Product Definition Center (PDC) at: -https://pdc.fedoraproject.org/rest_api/v1/component-branch-slas/[https://pdc.fedoraproject.org/rest_api/v1/component-branch-slas/] - -[[how-do-i-set-an-sl-on-my-branch]] -=== How do I set an SL on my branch? - -The SL of your branch is set when you request your branch. For more -information on requesting a branch, please review the -https://fedoraproject.org/w/index.php?title=Infrastructure/WhatHappenedToPkgdb#How_do_I_request_a_new_package.2C_a_new_branch.2C_or_to_unretire_a_package.3F[How -do I request a new package, a new branch, or to unretire a package?] -section of this FAQ. - -[[will-there-be-an-f27-branch]] -=== Will there be an "f27" branch? - -Yes, we will automatically create an "f27" branch that will in general -act like the "f26" branch but with explicit SLs that match what we would -expect from the implicit SLs of a traditional Fedora 27 release. This -means packagers don't have to change their branching strategy if they -don't want to. For f28, we intend to propose to FESCo that we do not -create global "f28" branches for all packages. - -(If one branch is suitable for multiple Fedora releases, it may be less -work for the packager to create a single branch that is used by all -those releases instead of maintaining a branch per release. To arrive at -this scenario, at some point we have to stop automatically creating new -branches for new distro releases.) - -[[in-what-circumstances-should-i-request-a-new-style-branch]] -=== In what circumstances should I request a new-style branch? - -For context, go back to review Changes/ArbitraryBranching. Traditional -Fedora dist-git branches are _named in correspondence with a release of -the distro_. "New-style" branches allow packagers to name a branch -"arbitrarily". See advice on choose a name in the next subsection. - -There could be many reasons to request a new-style branch. The primary -reason is if you'd like a branch that doesn't have an SL of a -traditional Fedora release. If for instance, you create a branch that -can serve multiple Fedora releases, that would end up being less work -for you as the packager since you only maintain one branch instead of -many with the same code base. Another instance is if your package needs -to have breaking changes that are frequent and violate the lifecycle of -a traditional Fedora release. The latter example could not, however, be -included in a Fedora release since it's SL is lower than the SL of a -release. - -[[how-should-i-name-my-branch]] -=== How should I name my branch? - -At this time, there are no restrictions on how you name your branches -except that they may not be derogatory or offensive; they may not -violate the https://getfedora.org/code-of-conduct[Fedora Community Code -of Conduct]. - -Try to use branch names that best describe the SL you are trying to -provide. For instance, if you maintain a package that is at version 2.7 -for a while, you could create a branch called "2.7" which would be -updated with every 2.7.x release upstream. Another example is if you are -always trying to package the latest upstream version, you could call -your branch "latest". It's really up to you, but just try to be -informative and considerate when choosing names. - -Requests for new branches will still pass through a member of the -'cvsadmin' group for approval. They may adopt more specific policy over -time. - -[[how-do-i-pick-an-sl-for-my-branch]] -=== How do I pick an SL for my branch? - -See https://fedoraproject.org/wiki/Module:Guidelines#SLs_and_EOLs[this -section] of the Module guidelines for information on selecting the -appropriate SLs. - -[[how-do-i-find-the-list-of-modules-that-pull-in-my-branch]] -=== How do I find the list of modules that pull in my branch? - -Try https://pagure.io/releng/pull-request/6970[this script]. diff --git a/content/en-US/packaging_setup.adoc b/content/en-US/packaging_setup.adoc deleted file mode 100644 index 4b0f2df..0000000 --- a/content/en-US/packaging_setup.adoc +++ /dev/null @@ -1,56 +0,0 @@ -= How do I setup my system for packaging work? - -All the tools you need to do packaging work in Fedora are freely available through the official Fedora repositories. - - -[[install-the-packaging-client-tools]] -== Install the packaging client tools - -The _fedora-packager_ package provides tools to help you setup and work with Fedora. -When you install it, that package brings in everything necessary for general packaging work. -Run the following command link:https://fedoramagazine.org/howto-use-sudo/[using sudo]: - --------------------------------- -sudo dnf install fedora-packager --------------------------------- - -[[configure-your-git]] -== Configure git - -First, configure your user name and email address for Git. -These are linked in each commit you do to Fedora packages. - --------------------------------------------------- -git config --global user.name "John Doe" -git config --global user.email johndoe@example.com --------------------------------------------------- - - -[[set-up-koji-client-config]] -== Set up Koji client configuration - -Fedora and EPEL use the Fedora build system https://fedoraproject.org/wiki/Using_the_Koji_build_system[Koji] to build packages. -Use the following command to https://fedoraproject.org/wiki/Using_the_Koji_build_system#Fedora_Account_System_.28FAS2.29_Setup[setup your Koji client configuration]. -Do not use _sudo_ or run this command as the _root_ user: - ---------------------- -fedora-packager-setup ---------------------- - -[[get-a-kerberos-ticket]] -== Get a Kerberos ticket - -You should know your Fedora Account System login name. -Write this name to the _.fedora.upn_ file in your home directory, for use by additional tools. -Substitute your FAS login name for _your-fasname_: - ------------------------------------ -echo _your-fasname_ > ~/.fedora.upn ------------------------------------ - -Then get a Kerberos ticket using this command. -Use all uppercase letters for FEDORAPROJECT.ORG as shown: - --------------------------------------- -kinit _your-fasname_@FEDORAPROJECT.ORG --------------------------------------- diff --git a/content/en-US/stepping_out.adoc b/content/en-US/stepping_out.adoc deleted file mode 100644 index c0b62aa..0000000 --- a/content/en-US/stepping_out.adoc +++ /dev/null @@ -1,10 +0,0 @@ -:Tags: dnf, orphaning -:Slug: stepping-away-from-a-package -= How to step away from a package? - -This package describes the steps one would need to follow to step away from -maintainaing a package in Fedora. - -There are two cases to consider: -- The maintainer found someone to take over the package -- The maintainer did not find someone interested in taking over the package diff --git a/content/en-US/update_my_package.adoc b/content/en-US/update_my_package.adoc deleted file mode 100644 index 8425727..0000000 --- a/content/en-US/update_my_package.adoc +++ /dev/null @@ -1,16 +0,0 @@ -:Tags: rpms, fedpkg, updating -:Slug: automatic-updates -= How to update my package? - -This document describe the different steps to import and update a package in -Fedora. - -Questions to answer here (unordered): -- How do I use stream branches? -- How to submit patches to a package I use? -- How to help maintaining this package I use? -- Who can change a package I maintain? -- Remind me how to update this package I maintain - fedpkg(/git)/koji/bodhi... -- CI integration - diff --git a/develop_server.sh b/develop_server.sh deleted file mode 100755 index 8c2f27f..0000000 --- a/develop_server.sh +++ /dev/null @@ -1,103 +0,0 @@ -#!/usr/bin/env bash -## -# This section should match your Makefile -## -PY=${PY:-python} -PELICAN=${PELICAN:-pelican} -PELICANOPTS= - -BASEDIR=$(pwd) -INPUTDIR=$BASEDIR/content -OUTPUTDIR=$BASEDIR/output -CONFFILE=$BASEDIR/pelicanconf.py - -### -# Don't change stuff below here unless you are sure -### - -SRV_PID=$BASEDIR/srv.pid -PELICAN_PID=$BASEDIR/pelican.pid - -function usage(){ - echo "usage: $0 (stop) (start) (restart) [port]" - echo "This starts Pelican in debug and reload mode and then launches" - echo "an HTTP server to help site development. It doesn't read" - echo "your Pelican settings, so if you edit any paths in your Makefile" - echo "you will need to edit your settings as well." - exit 3 -} - -function alive() { - kill -0 $1 >/dev/null 2>&1 -} - -function shut_down(){ - PID=$(cat $SRV_PID) - if [[ $? -eq 0 ]]; then - if alive $PID; then - echo "Stopping HTTP server" - kill $PID - else - echo "Stale PID, deleting" - fi - rm $SRV_PID - else - echo "HTTP server PIDFile not found" - fi - - PID=$(cat $PELICAN_PID) - if [[ $? -eq 0 ]]; then - if alive $PID; then - echo "Killing Pelican" - kill $PID - else - echo "Stale PID, deleting" - fi - rm $PELICAN_PID - else - echo "Pelican PIDFile not found" - fi -} - -function start_up(){ - local port=$1 - echo "Starting up Pelican and HTTP server" - shift - $PELICAN --debug --autoreload -r $INPUTDIR -o $OUTPUTDIR -s $CONFFILE $PELICANOPTS & - pelican_pid=$! - echo $pelican_pid > $PELICAN_PID - cd $OUTPUTDIR - $PY -m pelican.server $port & - srv_pid=$! - echo $srv_pid > $SRV_PID - cd $BASEDIR - sleep 1 - if ! alive $pelican_pid ; then - echo "Pelican didn't start. Is the Pelican package installed?" - return 1 - elif ! alive $srv_pid ; then - echo "The HTTP server didn't start. Is there another service using port" $port "?" - return 1 - fi - echo 'Pelican and HTTP server processes now running in background.' -} - -### -# MAIN -### -[[ ($# -eq 0) || ($# -gt 2) ]] && usage -port='' -[[ $# -eq 2 ]] && port=$2 - -if [[ $1 == "stop" ]]; then - shut_down -elif [[ $1 == "restart" ]]; then - shut_down - start_up $port -elif [[ $1 == "start" ]]; then - if ! start_up $port; then - shut_down - fi -else - usage -fi diff --git a/modules/ROOT/assets/images/Bodhi-builds-from-side-tag.png b/modules/ROOT/assets/images/Bodhi-builds-from-side-tag.png new file mode 100644 index 0000000..6ba9610 Binary files /dev/null and b/modules/ROOT/assets/images/Bodhi-builds-from-side-tag.png differ diff --git a/modules/ROOT/assets/images/Bodhi-builds-refresh-from-side-tag.png b/modules/ROOT/assets/images/Bodhi-builds-refresh-from-side-tag.png new file mode 100644 index 0000000..5403f82 Binary files /dev/null and b/modules/ROOT/assets/images/Bodhi-builds-refresh-from-side-tag.png differ diff --git a/modules/ROOT/assets/images/pizza.png b/modules/ROOT/assets/images/pizza.png new file mode 100644 index 0000000..bdecba7 Binary files /dev/null and b/modules/ROOT/assets/images/pizza.png differ diff --git a/modules/ROOT/nav.adoc b/modules/ROOT/nav.adoc new file mode 100644 index 0000000..1848a38 --- /dev/null +++ b/modules/ROOT/nav.adoc @@ -0,0 +1,16 @@ +* xref:Joining_the_Package_Maintainers.adoc[Joining the Package Maintainers] +** xref:How_to_Get_Sponsored_into_the_Packager_Group.adoc[How to Get Sponsored into the Packager Group] +* xref:How_to_Sponsor_a_New_Contributor.adoc[How to Sponsor a New Contributor] +* New Package Process +** xref:New_Package_Process_for_Existing_Contributors.adoc[for Existing Contributors] +** xref:New_Package_Process_for_New_Contributors.adoc[for New Contributors] +* xref:Package_Review_Process.adoc[Package Review Process] +** xref:Policy_for_Stalled_Package_Reviews.adoc[Policy for Stalled Package Reviews] +* xref:Package_Renaming_Process.adoc[Package Renaming Process] +* xref:Package_Orphaning_Process.adoc[Package Orphaning Process] +* xref:Package_Retirement_Process.adoc[Package Retirement Process] +* xref:Package_Maintenance_Guide.adoc[Package Maintenance Guide] +* xref:Package_Update_Guide.adoc[Package Update Guide] +* xref:Staying_Close_to_Upstream_Projects.adoc[Staying Close to Upstream Projects] +* xref:Using_the_Koji_Build_System.adoc[Using the Koji Build System] +* xref:Upstream_Release_Monitoring.adoc[Upstream Release Monitoring] diff --git a/modules/ROOT/pages/How_to_Get_Sponsored_into_the_Packager_Group.adoc b/modules/ROOT/pages/How_to_Get_Sponsored_into_the_Packager_Group.adoc new file mode 100644 index 0000000..9bcabd9 --- /dev/null +++ b/modules/ROOT/pages/How_to_Get_Sponsored_into_the_Packager_Group.adoc @@ -0,0 +1,202 @@ += How to Get Sponsored into the Packager Group +:toc: + +[[sponsorship_model]] +== Sponsorship model + +Getting sponsored allows anyone interested to become a Fedora maintainer +and get direct commit and upload access to their proposed software packages. +We require people to get sponsored into the `packager` group +before getting this access to Fedora +to ensure that they have someone that they can go to with questions. +Sponsorship is *not* automatic +and requires that you find a willing sponsor. +Depending on the sponsor and how much time they have to spend with you, +they may require that you demonstrate +that you have the knowledge to maintain Fedora packages properly +(including an understanding of the Fedora packaging guidelines) +or they may be willing to take you on +if you just show that you are eager and willing +to learn those things from them. +A sponsor will assist you +with some aspects of packaging and the submission process +but will expect you to read about the process and https://docs.fedoraproject.org/en-US/packaging-guidelines/[guidelines for packages] +for a large amount of your understanding of how things work. + +[[convincing_someone_to_sponsor_you]] +== Convincing someone to sponsor you + +There are several ways to get sponsored into the `packager` group +depending on your interest. +In many cases doing a mixture of different things +will increase your chances of being sponsored. + +[[submitting_quality_new_packages]] +=== Submitting quality new packages + +Until you are sponsored into the `packager` group +you are not able to own packages +or to check in changes to packages which you own. +However, you can still create an initial package +and submit it for review +as talked about at xref:Joining_the_Package_Maintainers#adding_a_new_package[Joining the Package Maintainers]. +When you open your review request in bugzilla, +you should block the https://bugzilla.redhat.com/show_bug.cgi?id=FE-NEEDSPONSOR[FE-NEEDSPONSOR] tracking bug, +that way all of the sponsors +will be able to see your sponsorship request. +Although `FE-NEEDSPONSOR` is set on the package's review request, +it is the person that needs to be sponsored into the `packager` group, +not the package. +The package undergoes a xref:Package_Review_Process.adoc[ review and approval] +that is separate from someone sponsoring you. +Note that it is possible to have accepted packages +which you cannot import because you have not been sponsored. +See below. + +When submitting a new package, +usually a sponsor finds you, +but you can take a look at the https://accounts.fedoraproject.org/group/packager/[list of packager sponsors] +(only accessible with a https://fedoraproject.org/wiki/Account_System[Fedora Account]) +for someone you know. +Sending bulk requests to the list is discouraged. +If you can't find anyone that you have a connection with, +you may want to try hanging out in the https://fedoraproject.org/wiki/How_to_communicate_using_IRC[#fedora-devel IRC channel] +to get to know some people. +Also you might find a sponsor in a that fits to your submitted package. + +Sponsors who work with people submitting new packages +are looking to see how well you are going to be able to maintain this package +which is primarily about whether you can package according to Fedora's https://docs.fedoraproject.org/en-US/packaging-guidelines/[Packaging Guidelines] +but they'll also take into account +how you'll be able to respond to bugs against the code itself. +If you like, +you can include other information about your involvement with the Fedora and upstream communities +that you think might help the sponsors in their decision. +If you are an upstream author of the package you are submitting +or if you are active in the community that surrounds it, +please say so. +If you can line up one or more existing Fedora contributors +who are willing to maintain the package along with you, +even if they are not sponsors, +please indicate that as well. + +The sponsors that look at new package submissions +often ask new packagers to do some package reviews +in order to further show that they know what they're doing. +If you do some reviews ahead of time, +you can show the sponsors that you've both read these pages +and understand the guidelines. +Go ahead and link to other package review requests +where you've left comments and reviews +(More on reviews link:#show_your_expertise_by_commenting_on_other_review_requests[below]). + +Basically, +the more information that you make available, +the quicker you will find a sponsor. + +If you have accepted packagesand still have not managed to find a sponsor, +feel free to file a ticket in the https://pagure.io/packager-sponsors/[sponsors ticketing system]. + +[[show_your_expertise_by_commenting_on_other_review_requests]] +=== Show Your Expertise by Commenting on other Review Requests + +To show you familiarity with Fedora's guidelines, +perform unofficial (also called preliminary) reviews +in other maintainers' package review request. +Please clearly state when doing these reviews, +that these are yet unofficial, +and do not change the review requests status +except for adding you to the CC list. +To let sponsors know of your preliminary reviews, +link to them in your review request. +The quality of your reviews help convincing a sponsor of your knowledge. +They will also help out the other reviewers, +which will be much appreciated. +After you got sponsored, you can finish your unofficial reviews. + +Reviews follow the https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/[review guidelines]. +Note that it's not strictly necessary +for you to work through the entire checklist, +but please do as much as you can; +the more you indicate that you understand, +the better your chances of being sponsored. + +You can search in the https://fedoraproject.org/PackageReviewStatus/in_progress.html[list of reviews in progress] +for review requests to comment on. +If you want to work on review requests that nobody else officially reviews, +see the http://fedoraproject.org/PackageReviewStatus/reviewable.html[list of unassigned review requests]. + +[[show_your_expertise_by_opening_pull_requests]] +=== Show Your Expertise by Opening Pull Requests + +The https://pagure.io[Pagure] based https://src.fedoraproject.org[src.fedoraproject.org] system +allows you to Fork, modify, and open Pull Requests for packages +even if you are not yet part of the package maintainer's group. +This is an excellent way to help other package maintainers, +and demonstrate your expertise. +When requesting sponsorship, you should list these PRs. +In many cases, +maintainers will also be happy to co-maintain the package with you, +and get you sponsored. +More on that in the next section. + +[[become_a_co_maintainer]] +=== Become a co-maintainer + +Another way to enter the `packager` group +is by co-maintaining a package that is already in Fedora. +To get sponsored this way +you need to convince the current owner of that package +to let you co-maintain the package and tho act as your mentor +-- teaching you how to package properly in Fedora +and how to use the tools available for building and distributing packages. +To get an owner to agree to this, +you may need to demonstrate +that you have some understanding of packaging already +or at least, that you are eager to learn. +Submitting patches on bug reports, +preparing updated packages if the maintainer is behind on creating an update, +or otherwise communicating with the maintainer that you are willing to help +are ways to show +that you are worth the package owner's investment to train you. + +In some cases the package owner is a sponsor in the `packager` group +and can sponsor you themselves. +If they are not a sponsor, +they can get another existing sponsor to do so, +either by contacting a sponsor personally +and asking them to proxy the sponsorship +or by opening a ticket in the https://pagure.io/packager-sponsors/[packager sponsors pagure instance] +stating that they are a package owner +who would like you to co-maintain their package. +They agree to be responsible for mentoring you in how to follow the https://docs.fedoraproject.org/en-US/packaging-guidelines/[Fedora Packaging Guidelines] +and how to use the tools Fedora provides for building and pushing packages +but need someone to sponsor you +since they are not sponsors themselves. +A sponsor will add you to the `packager` group +once that agreement for mentorship exists. + +[[other_paths]] +=== Other paths + +Sponsors can decide to sponsor you for any other reason as well. +For example, +you may be upstream for a package +and want to maintain just that package in Fedora, +or a sponsor may know your work and packaging history +and deem you worthy of sponsorship +with no further information. +The sponsorship decision is left up to the sponsor. + +== Provenpackagers + +https://docs.fedoraproject.org/en-US/fesco/Provenpackager_policy/[Provenpackagers] are members of the *provenpackager* group. +In addition to the rights granted to members of *packager*, +provenpackagers are able to commit changes +to packages they do not own or maintain. + +[[how_to_sponsor]] +== How to sponsor + +If you are looking for information on sponsoring someone, +take a look at xref:How_to_Sponsor_a_New_Contributor.adoc[how to sponsor a new contributor]. diff --git a/modules/ROOT/pages/How_to_Sponsor_a_New_Contributor.adoc b/modules/ROOT/pages/How_to_Sponsor_a_New_Contributor.adoc new file mode 100644 index 0000000..4ff061c --- /dev/null +++ b/modules/ROOT/pages/How_to_Sponsor_a_New_Contributor.adoc @@ -0,0 +1,151 @@ += How to Sponsor a New Contributor +:toc: + +[[becoming_a_fedora_package_collection_sponsor]] +== Becoming a Fedora Package Collection Sponsor + +The Fedora Package Collection has been setup so +to encourage "learning by doing" +and the development of cooperative relationships +between Fedora packagers. +Once packagers have acquired sufficient packaging knowledge +to help others through the process, +they may apply for sponsor status. +As "sufficient knowledge" is unworkably vague, +the following guidelines have been established. +Prospective sponsors should: + +* Maintain at least three packages. + +* Have done five high quality, nontrivial package reviews. + +* Have been members of the packager group +for at least one release cycle +(generally six months) +so that they have seen the process of branching +for a new release. + +These are still somewhat vague to allow for flexibility +but should provide a reasonable idea of how much experience is required. + +If you're a packager +and feel that you are ready +and would like to move up to sponsor status, +simply file a ticket in the https://pagure.io/packager-sponsors/issues[packager sponsors ticket system]. +These tickets are automatically sent to the sponsors list. +A report will be added +containing information on your reviewed and owned/comaintained packages, +but feel free to provide additional information that can't easily be found +such as informal reviews done +or prospective packagers you would like to sponsor. + +Votes will be collected in the ticket for a week. +At the end of that time, +if the differential between positive and negative votes +stands at +3 or greater, +your request will be approved +and you'll be promoted to sponsor status immediately. +If not, your request will be closed. +You may reapply anytime you feel you have more support. +After waiting an hour or so +for the new permissions to propagate through the system, +you will be able to sponsor new packagers. + +[[sponsoring_someone_for_fedora_package_collection]] +== Sponsoring Someone for Fedora Package Collection + +Sponsoring someone +for access to Fedora Package Collection +is relatively simple. +If you are looking for someone to sponsor, +take a look at the https://accounts.fedoraproject.org/[Fedora Account system] +for contributors who are currently searching for a sponsor. +Note that they should also have submitted a package review request +for a package which they are proposing to add to Fedora +on https://bugzilla.redhat.com[Red Hat Bugzilla]. +In this request they should write that they need a sponsor. + +Bugzilla will send a notification mail for the new review request +to the fedora-package-review mailing list. +Take a look at their package and review it. +If it looks reasonable and it seems that the comply with the https://docs.fedoraproject.org/en-US/packaging-guidelines/[Packaging Guidelines], +then they are probably a good candidate to be sponsored. + +Add any comment for changes to the review request on Bugzilla +which look as though they'd be needed for compliance +as well as the fact that you're volunteering to sponsor them. +Once they've made those changes, +you can approve the package +and sponsor the user in the Fedora account system. +Before you approve the user, +please make sure that his/her email in https://accounts.fedoraproject.org/[Fedora Account system] is the same as in https://bugzilla.redhat.com[Red Hat Bugzilla]. +After that, +go to https://accounts.fedoraproject.org/group/packager/, +log in, +then add the username in the 'add user' field +located to the right of the top of the "Members" section, +then press enter. + +A new packager cannot, at this time, +make changes to packages he does not own or comaintain +until he applies to become a https://docs.fedoraproject.org/en-US/fesco/Provenpackager_policy/[provenpackager] +but you should still keep an eye on them. +Generally the easiest way to do this +is for them to become comaintainers of at least the initial package they review. +You should be sure to review their commits to the Git repository +for how they look, +and consider watching their Bugzilla activity +at least for a while (Preferences→Email Preferences→https://bugzilla.redhat.com/userprefs.cgi?tab=email[User Watching]). +Respond with any comments that you might have +and guide them, +providing assistance as they need it for any tasks. +A provenpackager can step in if necessary. + +So what's the downside to sponsoring someone? +Your sponsoree will likely have questions about processes; +one of your responsibilities as a sponsor +is to help them with the answers. +A sponsor isn't expected to be omniscient, though, +so you can feel free to ask for others' advice and opinions +if you get a really hard question. +https://docs.fedoraproject.org/en-US/fesco/Packager_sponsor_responsibilities/[Sponsor responsibilities are detailed here]. + +[[sponsoring_someone_for_provenpackagers]] +== Sponsoring Someone for provenpackagers + +https://docs.fedoraproject.org/en-US/fesco/Provenpackager_policy/[Provenpackagers] have access to most packages. +FESCo members should forward requests for provenpackagers +to the sponsors mailing list +where sponsors can give their advice +on the provenpackager request. +Provenpackagers may nominate themselves, +but having a sponsor endorse the nomination +or proposing the packager to become a provenpackager +(the packager should agree) +is certainly a good thing. + +By granting membership into the provenpackager group for a maintainer +you are confirming that +(at least in your mind) +they meet the criteria for that group, +and that you would trust them fully +with any of the packages you either maintain +or even just use. + +Provenpackagers are approved on at least 3 positive votes with no negative votes. +In the event of negative votes, +the decision will be made by FESCo at their next meeting. +See the https://docs.fedoraproject.org/en-US/fesco/Provenpackager_policy/[provenpackager description] for more information. + +[[welcome_note]] +== Welcome Note + +Once you have sponsored someone, +we request that you send a note to Fedora devel mailing list +welcoming the new contributor +and cc the person you have sponsored. +Public recognition of any contributor +would help them feel appreciated +and motivate them to contribute more. +It would also help establish Fedora as a community of people and friends +rather than merely a technical body of work. diff --git a/modules/ROOT/pages/Joining_the_Package_Maintainers.adoc b/modules/ROOT/pages/Joining_the_Package_Maintainers.adoc new file mode 100644 index 0000000..695053f --- /dev/null +++ b/modules/ROOT/pages/Joining_the_Package_Maintainers.adoc @@ -0,0 +1,272 @@ += Joining the Package Maintainers +:toc: + +So, you have decided to become a package maintainer in the Fedora Project? +This guide will lead you through your first package submission. +It can be a completely new package, +or update to an existing package. + +== Preparation + +[[read_the_guidelines]] +=== Read the Guidelines + +If you don't know how to create an RPM package, +refer to the tutorial at https://docs.fedoraproject.org/en-US/quick-docs/create-hello-world-rpm/[How to create a GNU Hello RPM package] +or the more advanced and much more detailed https://docs.fedoraproject.org/en-US/quick-docs/creating-rpm-packages/index.html[Creating RPM packages]. + +Read the https://docs.fedoraproject.org/en-US/packaging-guidelines/[Packaging Guidelines] and https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/[Package Naming Guidelines]. + +You need to be thoroughly familiar with these. +They govern all package submissions. +If you have questions, ask on the Fedora List. + +[[create_a_bugzilla_account]] +=== Create a Bugzilla Account + +Make sure you have an account in https://bugzilla.redhat.com/[Red Hat Bugzilla]. + +The email address that you use for your Bugzilla account +should be the same email address as you use in the xref:create_a_fedora_account[Fedora Account System] for all things related to Fedora Packaging. + +[[create_a_fedora_account]] +=== Create a Fedora Account + +Create an account in the https://fedoraproject.org/wiki/Account_System?rd=Infrastructure/AccountSystem[Fedora Account System]. +(This is _not_ the same as the Bugzilla account.) + +. Visit the account system home: https://accounts.fedoraproject.org/ + +. Click on _New account_ and fill in the blanks. +Note that the email you give should be +the same as the one you gave Bugzilla. +This allows the system to link privileges +between the two accounts. + +. After you create your account, +please be sure to sign the CLA +(if you click on the _My Account_ link in the top right, +you should see _CLA: CLA Done_). + +. You will also need to upload a public RSA SSH key. +You need to use the matching private key +to access Fedora machines via SSH. +You can read more about this https://fedoraproject.org/wiki/Cryptography[here]. + +[[join_the_important_mailing_lists]] +=== Join the important Mailing Lists + +You should join the Fedora https://lists.fedoraproject.org/admin/lists/devel-announce@lists.fedoraproject.org/[devel-announce] mailing list. +It is a low traffic announcements only list, +where important development information is posted. + +You should join the Fedora https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org/[devel] mailing list, +where discussions about the development of Fedora are held. +This is a high traffic mailing list. + +You should also consider joining the https://lists.fedoraproject.org/admin/lists/package-announce@lists.fedoraproject.org/[package-announce] mailing list +-- The commits mailing list gets notifications +on all commits in any package +in the Fedora repository. +This is a very high traffic mailing list. +The Fedora package database sends commit mails for packages you (co-)maintain. + +Another mailing list you might consider +(at least to view the archives) +is https://lists.fedoraproject.org/admin/lists/packaging@lists.fedoraproject.org/[packaging]. +This is the mailing list of the https://fedoraproject.org/wiki/Packaging_Committee[Fedora Packaging Committee], +who determine the official packaging guidelines for Fedora projects. + +[[introduce_yourself]] +=== Introduce yourself + +Next, you should introduce yourself to the community on the mailing list. +The primary purpose of this is +to begin the process of building trust +by allowing the Fedora community members +to get to know you a bit more. + +We want to break anonymity and foster real-world community within the project. +You are under no obligation to reveal personal secrets. +The objective is to establish a level of trust +between yourself and the other members of the project. +But you should at least use your real name +when communicating with us. +Also, a brief description of who you are, +your motivations +and perhaps a description of the software you have submitted for review +are advisable. + +.... +Subject: Self Introduction: + +Body: Add any information you believe is applicable +including past experience in free and open source projects, +a link to the review request you have filed and +a brief description of yourself. You can also post +your GPG key information if you want to. +.... + +Feel free to participate in all the discussion +that goes on in any of the lists. +Community discussion and feedback is always encouraged. + +[[find_software_you_wish_to_packagemaintain_for_fedora]] +=== Find software you wish to package/maintain for Fedora + +The package you are submitting can be of any Free and Open Source project +that is not already packaged in Fedora. +Before creating your package, +make sure that the software is not already in the Fedora repository, +or waiting for review. + +* Search the https://src.fedoraproject.org/[Fedora packages] for packages already in the repository. + +* Search in the http://fedoraproject.org/PackageReviewStatus/[Review Tracker] for packages under review. + +* Also check the https://src.fedoraproject.org/user/orphan[orphaned or retired packages that need new maintainers]. + +* Be aware of https://fedoraproject.org/wiki/Forbidden_items[forbidden items]. + +[[understand_your_responsibilities]] +=== Understand your responsibilities + +Software components included in Fedora need to be maintained actively, +and bugs — especially security issues - +need to be fixed in a timely manner. +As a Fedora package maintainer, +it is your primary https://docs.fedoraproject.org/en-US/fesco/Package_maintainer_responsibilities/[responsibility] to ensure this. +We encourage you to get https://docs.fedoraproject.org/en-US/fesco/Policy_for_encouraging_comaintainers_of_packages/[co-maintainers] +and seek the help of the Fedora community +via the development mailing list +whenever needed. + +[[read_other_submissions]] +=== Read Other Submissions + +Read some other package submissions +to learn about packaging +and gain familiarity with the process and requirements. + +One way of doing this is to join the mailing list. +All comments on Fedora package reviews are sent to this +(read-only from your point of view) +list. + +[[configure_your_git]] +=== Configure Your Git + +The first thing to do when you set up Fedora packaging +is to configure your username and email address for Git. +These are linked in each commit you do to Fedora packages. + +.... +git config --global user.name "John Doe" +git config --global user.email johndoe@example.com +.... + +[[install_the_developer_client_tools]] +=== Install the developer client tools + +To build Packages for the Fedora Collection or EPEL +n the Fedora build system +you need https://fedoraproject.org/wiki/Using_the_Koji_build_system[Koji]. + +The package provides tools to help you setup and work with fedora. +It will bring in everything necessary for general packaging work. +Run the following as root: + +.... +dnf install fedora-packager +.... + +After installation set your Fedora Account System username in +(do this as your normal user, not root). +You can do this via: + +.... +echo "yourfasid" > ~/.fedora.upn +.... + +(replacing `yourfasid`, of course.) + +You can now use `koji` to try to build your RPM packages +in the Fedora build system, +even on platforms or Fedora versions you don't have. +Note that you can (and definitely should) +test out builds ("scratch" builds) +even before your package has been approved +and you have been sponsored. +A simple way to do a scratch build using koji +is to do this at the command line: + +.... +koji build --scratch TARGET path_to_source_RPM +.... + +Where: + +* `TARGET` is a distribution keyword such as `f25` (for Fedora 25). +You can run `koji list-targets` to see all targets. +To build for the next release (rawhide), _do not_ use `dist-rawhide` +— use `fX` where X is one more than the latest stable or branched release. + +* Note that you need to supply the _path_ to the source RPM +(which ends in .src.rpm), +and *not* a URL. +(If you only have the spec file, +use `rpmbuild --nodeps -bs SPECFILE` +to create the new source RPM). + +Your koji builds can only depend on packages +that are actually in the `TARGET` distribution repository. +Thus, you can't use koji to build for released distributions +if your package depends on other new packages +that https://fedoraproject.org/wiki/Bodhi[Bodhi] hasn't released yet. +You _can_ use koji to build for rawhide +(the next unreleased version), +even if it depends on other new packages, +as long as the other packages were built for Rawhide +as described below. +If you need to build against a package +that is not yet a stable released update, +you can https://pagure.io/releng/new_issue[file a ticket with rel-eng] +and request that that package is added as a buildroot override. +For packages in EPEL, +you have to use the component `epel` +to get the request to the right persons. + +You can learn more about koji via: + +.... +koji --help # General help +koji --help-commands # list of koji commands +koji COMMAND --help # help on command COMMAND +.... + +xref:Using_the_Koji_Build_System.adoc[Using the Koji build system] has more information about using Koji. + +[[adding_a_new_package]] +== Adding a new package + +Follow xref:New_Package_Process_for_New_Contributors.adoc[New Package Process for New Contributors]. + +[[getting_help]] +== Getting Help + +We know that this process can be as clear as mud sometimes, +and we're always trying to make it better. +If you run into any problems, +or have any questions +please ask on the mailing list +or in on freenode.net. + +[[one_off_contributions]] +== One-off contributions + +Changes to https://src.fedoraproject.org/browse/projects/[existing packages] +can be suggested by submitting https://docs.pagure.org/pagure/usage/pull_requests.html[pull requests]. +You must have a xref:create_a_fedora_account[Fedora account] to create a pull request. +See xref:Package_Maintenance_Guide.adoc#using_fedpkg_anonymously[using fedpkg anonymously] +for instructions +and https://fedoraproject.org/wiki/Infrastructure/HTTPS-commits[Infrastructure/HTTPS-commits] for more information. diff --git a/modules/ROOT/pages/New_Package_Process_for_Existing_Contributors.adoc b/modules/ROOT/pages/New_Package_Process_for_Existing_Contributors.adoc new file mode 100644 index 0000000..d1ced9a --- /dev/null +++ b/modules/ROOT/pages/New_Package_Process_for_Existing_Contributors.adoc @@ -0,0 +1,132 @@ += New Package Process for Existing Contributors +:toc: + +This is a short version of the New Package Process, +streamlined to show how existing contributors can make new packages. + +. Read the https://docs.fedoraproject.org/en-US/packaging-guidelines/[Packaging Guidelines] +and https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/[Package Naming Guidelines]. +Really. +Be comfortable with them. + +. Make a package. + +** You should make sure that it is a new package. +A list of existing packages in Fedora Packages is here: https://src.fedoraproject.org/projects/rpms/* + +** Some information on how to create an RPM package is in https://docs.fedoraproject.org/en-US/quick-docs/creating-rpm-packages[Creating RPM packages]. + +** Make sure that your package meets the https://docs.fedoraproject.org/en-US/packaging-guidelines/[Packaging Guidelines] +and https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/[Package Naming Guidelines] + +** Be aware of https://fedoraproject.org/wiki/Forbidden_items[forbidden items] +and https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/[Package Review Guidelines]. +They will be used during the package review. + +. Upload your SRPM and SPEC files onto the internet somewhere. + +** If you have already got a Fedora Account +then you can use your storage at http://fedorapeople.org for this. + +. Make sure you have a Bugzilla account at bugzilla.redhat.com + +. Fill out https://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Fedora&format=fedora-review[Bugzilla Fedora review form] to create a review request. + +** Make sure you put the name of the package in the `Review Summary` field, +along with a very brief summary of what it is + +** Make sure that you put the URL paths for the SPEC file and the SRPM file in the `Review Description` + +** Put a description of your package +(usually, this can be the same thing as what you put in the spec `%description`) +in `Review Description` + +** The review process is described in detail in https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/[Package Review Guidelines]. + +. Watch the review request in Bugzilla. +Fix any blockers that the reviewer(s) point out. + +. When the package is approved by the reviewer, +request a git module with `fedpkg request-repo PACKAGE-NAME BUGZILLA-TICKET-NUMBER` +and when the repo is created +request branches with `fedpkg request-branch --repo PACKAGE-NAME BRANCH`. +You might need to get a pagure-API-token +before being able to successfully request the repo. Wait until the requests are approved. + +. Once the requests are approved, +checkout the git module with `fedpkg clone `. +(xref:Package_Maintenance_Guide.adoc[Package Maintenance Guide] has more information about `fedpkg`.) + +. Import your srpm + +** First `kinit username@FEDORAPROJECT.ORG` + +** Then you can import the approved SRPM into the rawhide branch by running `fedpkg import libfoo-x.x.x.src.rpm; git commit -m "Initial import (#nnnnnn)."` (where `nnnnnn` is your Bugzilla package review bug number). + +** Obviously, replace `libfoo-x.x.x.src.rpm` with the full path to your approved SRPM. + +** You should see it upload the sources, +and finish successfully. +If you didn't set up `ssh-agent` +it will ask often for your ssh-key passphrase. +This is normal. + +** Now run `git push` to get the final versions in your rawhide branch. + +. You can now import the package to your branches +(which you requested in Step 7) +too + +** The quickest way to do this is to use `fedpkg switch-branch BRANCH` +to switch the branch +(where `BRANCH` can be `f13` and so on). + +** Now you can `git merge rawhide`. +This will get `.spec` file, `.gitignore` and source file +together with any patches and other files from the rawhide branch +and create an identical commit. + +** Previous step already created commit for you, +now you can push the results using `fedpkg push` or `git push`. + +. Request builds + +** For each branch that you'd like to request a build for, +switch using `fedpkg switch-branch` and run `fedpkg build`. + +** If everything goes well, +it should queue up your branch for building, +the package will cleanly build, +and you're done! + +** If it fails to build, +the buildsystem will send you an email +to report the failure +and link you to the logs. +Commit any needed changes to git, +bump the spec release number +and request a new build. + +. Close the Bugzilla ticket +(assuming that the package built successfully) + +* You should close it with resolution `NEXTRELEASE` or `RAWHIDE`, +depending on where you built the package. +The resolution field will appear after you set the status field to `CLOSED`. + +. If this package will be built for any version of Fedora that is already released +please submit it for inclusion in the `fedora-updates` repository +for those versions of Fedora. +See xref:Package_Update_Guide.adoc#Later_Branched_and_stable_releases[Package Update Guide] for more details. + +. Add the package to the https://fedoraproject.org/wiki/How_to_use_and_edit_comps.xml_for_package_groups[comps file(s)] if appropriate. + +. Consider enabling xref:Upstream_Release_Monitoring.adoc[Upstream Release Monitoring] for the package. + +We know that this process can be as clear as mud sometimes, +we're always trying to make it better. +If you run into any problems, +or have any questions, +please ask on the https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/[Fedora development list]. + +xref:Package_Maintenance_Guide.adoc[Package Maintenance Guide] may also be of use. diff --git a/modules/ROOT/pages/New_Package_Process_for_New_Contributors.adoc b/modules/ROOT/pages/New_Package_Process_for_New_Contributors.adoc new file mode 100644 index 0000000..f1889b7 --- /dev/null +++ b/modules/ROOT/pages/New_Package_Process_for_New_Contributors.adoc @@ -0,0 +1,301 @@ += New Package Process for New Contributors +:toc: + +This is a long version of the New Package Process, +containing more details so new contributors can follow it more easily. +Also the mandatory xref:How_to_Get_Sponsored_into_the_Packager_Group.adoc[sponsoring] step is included. + +[[make_a_package]] +== Make a Package + +* If you don't know how to create an RPM package, +see the https://docs.fedoraproject.org/en-US/quick-docs/creating-rpm-packages/index.html[How to create an RPM package]. + +* Make sure that your package meets the https://docs.fedoraproject.org/en-US/packaging-guidelines/[Packaging Guidelines] and https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/[Package Naming Guidelines]. + +* Be aware of the https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/[Package Review Guidelines] +(they will be used during the package review). + +* Make sure your package builds. +This is surprisingly important +because a significant number of submissions don't. + +[[upload_your_package]] +== Upload Your Package + +Upload your SRPM and SPEC files onto the Internet somewhere +so that others can retrieve them. +This can be anywhere accessible by a URL, +but it is important that the files be directly accessible, +not hidden behind some service +that makes people wait to download things +or redirects through advertising pages. + +If you want to make ad-hoc builds available for users +while you are getting the package into the official repositories, +consider using https://copr.fedorainfracloud.org[Copr]. +It is a lightweight automated build system +that can create repositories using the SRPM you upload. +You can use this Copr space to point reviewers to your src.rpm and spec. + +[[create_your_review_request]] +== Create Your Review Request + +Fill out https://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Fedora&format=fedora-review[Bugzilla Fedora review form]. + +* Before submitting your request, +be sure there’s not a previous request for the same package. +There is a convenient search box on the http://fedoraproject.org/PackageReviewStatus/[package review status page]. + +* Make sure that you put the *name of the package* +(excluding version and release numbers) +in the `Review Summary` field, +along with a very *brief summary* of what the package is. + +* Put a *description* of your package +(usually, this can be the same thing +as what you put in the spec `%description`) +in the `Review Description` field. +Include the *URLs* to your *SRPM* and *SPEC* files. + +* Explain in the ticket that this is your first package +and you need a sponsor. +Also, include any information that may help prospective sponsors. +If you've been active in other review work, include links. +If you're the upstream maintainer, be sure to say so. + +* For bonus points, +include a link to a successful koji build +so that everyone knows you did all of your homework. + +The review process is described in detail on the xref:Package_Review_Process.adoc[Package Review Process] page. + +[[inform_upstream]] +== Inform Upstream + +The Fedora Project prefers xref:Staying_Close_to_Upstream_Projects.adoc[Staying Close to Upstream Projects]. +Inform the developers that you are packaging the software. +You can do that by sending them an email +introducing yourself and pointing out the review request. +This sets up the stage for future conversations. +They will usually advertise the fact +that their software is now part of Fedora +or might want to inform you +of important bugs in the existing release, +future roadmaps +etc. + +[[watch_for_feedback]] +== Watch for Feedback + +Watch the Bugzilla report for your first package. +You should get notifications of changes by email. +Fix any blockers that the reviewer(s) point out. + +[[get_sponsored]] +== Get Sponsored + +When the package is APPROVED by the reviewer, +you must separately obtain member sponsorship +in order to check in and build your package. +Sponsorship is not automatic +and may require that you further participate in other ways +in order to demonstrate your understanding of the packaging guidelines. +The key to becoming sponsored is +to convince an existing sponsor-level member +that you understand and follow the project's guidelines and processes. + +See xref:How_to_Get_Sponsored_into_the_Packager_Group.adoc[How to Get Sponsored into the Packager Group] +for more information on the process of becoming sponsored. + +Your sponsor can add you to the packager group. +You should receive an email confirmation of your sponsorship. + +[[add_package_to_source_code_management_scm_system_and_set_owner]] +== Add Package to Source Code Management (SCM) system and Set Owner + +Before proceeding, please sync your account by login on https://src.fedoraproject.org/[Fedora Package Sources] +using your FAS credentials. + +If you are becoming a maintainer for a new package, +instead of being a co-maintainer, +use https://pagure.io/fedpkg[fedpkg] +to request a new git repository for your package. +The sub-command is `fedpkg request-repo` +which includes help text for setting up the Pagure API token +the command requires. +When creating your API-key +choose toogle-all for the ACLs. +You must specify the repository name and review bug number. +For example: + +.... +fedpkg request-repo python-prometheus_client 1590452 +.... + +The request will be reviewed and processed by an admin, +usually within 24 hours. +Once the ticket is processed, +you will have access to commit and build the package. + +[[check_out_the_module]] +== Check out the module + +You _could_ check out your module now, +but before doing that, +consider doing `mkdir ~/fedora-scm ; cd ~/fedora-scm` +— that way, all your files are inside a single directory. +Also, run `ssh-add`, +so that you won't have to keep typing in your key password. + +Now you are ready to checkout your module from the SCM: + +.... + fedpkg clone your-package +.... + +[[test_your_package]] +== Test Your Package + +Refer to https://fedoraproject.org/wiki/Using_Mock_to_test_package_builds[Using Mock to test package builds] +and xref:Using_the_Koji_Build_System.adoc#scratch_builds +for more information on testing your package. +Mock uses your local system +while Koji command line tool uses the Fedora build system server. + +[[import_commit_and_build_your_package]] +== Import, commit, and build your package + +Now that you've checked out your (empty) package module with `fedpkg`, +cd into the module's main branch: + +.... +cd +.... + +Run fedpkg to import the contents of the SRPM into the SCM: + +.... +fedpkg import PATH_TO_SRPM +.... + +.... +# Review Changes, press 'q' to stop; Revert with: git reset --hard HEAD +git commit -m "Initial import (#XXXXXX)." +git push +fedpkg build +.... + +Obviously, replace `PATH_TO_SRPM` with the full path +(not URL) +to your approved SRPM, +and `XXXXXX` with the package review bug number. + +This imports into, commits, and builds only the *main* +(https://fedoraproject.org/wiki/Releases/Rawhide[Rawhide]) +branch. + +If the push fails with this kind of message: + +.... +W access for why DENIED to YOUR_ACCOUNT +fatal: The remote end hung up unexpectedly +Could not push: Command '['git', 'push']' returned non-zero exit status 128 +.... + +Then you don't have the necessary rights to modify that package branch. +View https://src.fedoraproject.org/rpms/PACKAGE_NAME to request those rights. + +For more information on using the Fedora package maintenance system, +see the xref:Package_Maintenance_Guide.adoc[Package maintenance guide]. + +[[update_your_branches]] +== Update Your Branches (if desired) + +Branches are `f#` +(formerly `F-#` and before that `FC-#`), +`main`, +etc. +So `f` is the branch for Fedora. + +To switch to a branch first: + +.... +fedpkg switch-branch BRANCH +.... + +(e.g. `f34`) + +Merge the initial commit from main (Rawhide), +creating an identical commit in the branch: + +.... +git merge rawhide +.... + +Push the changes to the server: + +.... +git push +.... + +Build the package: + +.... +fedpkg build +.... + +If there is another branch to work with +repeat _To switch to a branch_ +and import and commit to each branch. + +If everything goes well, +it should queue up your branch for building, +the package will cleanly build, +and you're done! + +If it fails to build, +the build system will send you an email +to report the failure +and show you to the logs. +Commit any needed changes to git, +bump the SPEC release number, +and request a new build. + +[[submit_package_as_update_in_bodhi]] +=== Submit Package as Update in Bodhi + +The Fedora update system called Bodhi +is used for pushing updates, +classifying packages +etc. +Do not submit Rawhide (main branch) builds via Bodhi. + +You can push an update using Bodhi +via the command line +using this in each branch: + +.... +fedpkg update +.... + +See the xref:Package_Update_Guide.adoc[Package Update Guide] for more details. + +[[make_the_package_available_in_comps_files]] +== Make the package available in "comps" files + +If appropriate for the package, +make it available in "comps" files +so that it can be selected during installation +and included in dnf package group operations. +See https://fedoraproject.org/wiki/How_to_use_and_edit_comps.xml_for_package_groups?rd=PackageMaintainers/CompsXml[How to use and edit comps.xml for package groups] for more info. + +[[watch_for_updates]] +=== Watch for updates + +Fedora has the infrastructure available +for monitoring new upstream releases +of the software you are packaging. +Refer to xref:Upstream_Release_Monitoring.adoc[Upstream Release Monitoring] +for more details. + diff --git a/modules/ROOT/pages/Package_Maintenance_Guide.adoc b/modules/ROOT/pages/Package_Maintenance_Guide.adoc new file mode 100644 index 0000000..45d3a8b --- /dev/null +++ b/modules/ROOT/pages/Package_Maintenance_Guide.adoc @@ -0,0 +1,622 @@ += Package Maintenance Guide +:toc: + +This page provides some basic instructions for day-to-day usage +of the http://git-scm.com/[git]-based package maintenance system for Fedora. +It is intended primarily for new and current Fedora package maintainers, +but does briefly xref:using_fedpkg_anonymously[cover anonymous read-only use of the system]. +It is not a guide to RPM packaging per se. + +Some pre-existing knowledge of git may be useful, +but is not a pre-requisite. +In fact, Fedora packaging can be a relatively painless introduction to it. + +You may have been looking for, or also be interested in: + +* https://docs.fedoraproject.org/en-US/quick-docs/creating-rpm-packages/[Creating RPM packages] +* https://docs.fedoraproject.org/en-US/packaging-guidelines/[Packaging Guidelines] + +[[installing_fedpkg_and_doing_initial_setup]] +== Installing _fedpkg_ and doing initial setup + +Start by installing `fedpkg` with `dnf install fedpkg`. +This will be your primary interface to the packaging system. + +You also must have an ssh key configured in the https://accounts.fedoraproject.org/[Fedora Accounts System] +to be able to make changes to any package +(including your own). +`fedpkg` will expect the correct ssh key to be available in your keyring. + +Before uploading sources with `new-sources` and `upload` +and building packages in Koji, with `build` for example, +you have to get your Kerberos credential first with `kinit`, e.g. + +.... +kinit [FAS name]@FEDORAPROJECT.ORG +.... + +Keep `FEDORAPROJECT.ORG` in capital case. + +Set your Fedora Account System username in file `~/.fedora.upn`. +You can do this via `echo "FAS_USERNAME" > ~/.fedora.upn`. + +[[common_fedpkg_commands]] +== Common fedpkg commands + +This section lists typical fedpkg commands in a normal workflow, +with short descriptions. +In this workflow, +we will be operating on the https://fedoraproject.org/wiki/Releases/Rawhide[Rawhide] branch of the package. + +=== Check out a package +.... +fedpkg co +cd +.... + +This retrieves a copy of the package sources from the server. +It's known as your 'working copy'. + +=== Update your checked-out copy from the Fedora server +.... +fedpkg pull +.... + +=== Retrieve package sources +.... +fedpkg sources +.... + +This pulls any sources stored in the "lookaside cache" +(see below for more). +Steps like `fedpkg prep` and `fedpkg srpm` will do this if necessary, +but you may want a copy right away. + +=== Make your changes to the package + +This is not an RPM packaging guide, +so we'll assume you know what you're doing here. +New sources and patches go in the working copy directory for now. + +=== Run the prep stage +Extract source, apply patches etc. within the checkout directory: +.... +fedpkg prep +.... + +This is useful for making sure your patches apply cleanly, +and inspecting the source tree if you need to do so. + +=== Do a local build of the current state +.... +fedpkg local +.... + +This is the simplest kind of test build, +but it's usually cleaner and a better test +to do a Mock or Koji scratch build (see below). + +=== Do a mock build of the current state +.... +fedpkg mockbuild +.... + +This fires off a https://github.com/rpm-software-management/mock/wiki[Mock] build, if you have Mock configured correctly. +https://fedoraproject.org/wiki/Using_Mock_to_test_package_builds[Using Mock to Test Package Builds] can help there. + +=== Generate a .src.rpm from the current state +.... +fedpkg srpm +.... + +You can request a Koji _scratch build_ +(a test build, which will not go to any repository) +of the generated .src.rpm +with the `koji build --scratch` command (see `man koji`). + +=== Do a scratch build using Koji + +See xref:Using_the_Koji_Build_System#scratch_builds[Koji scratch builds]. + +=== Check changes you have made +.... +fedpkg diff +.... + +This is handy for making sure you did not touch something by mistake, +or forget to bump the release, +or forget to include a changelog. + +=== Run some checks (rpmlint) on your package +.... +fedpkg lint +.... + +If you want to whitelist some rpmlint errors +and prevent them from appearing, +you can create an rpmlint config file named `.rpmlintrc` +and it will get applied. + +=== Stage any small patches or new source files for commit +.... +git add SOMEFILE +.... + +Git does not consider all files in the working directory +to be a part of the git repository by default +(handy for keeping other files around that are relevant, +like the source tree). +This tells git to start considering these files as part of the repository locally. +When you `commit` and `push` later, +this change is communicated to the server. + +=== Upload new source files to the lookaside cache +.... +fedpkg new-sources +.... + +WARNING: +This will replace the current list of source files, not add to it. + +.... +fedpkg upload +.... + +'Pristine' upstream sources (like release tarballs) +and other larger source files +are stored in the lookaside cache system, +not committed directly to git. +This provides more efficient storage and transfer of the files. +The sources and `.gitignore` files in the repository keep it in sync with the lookaside cache. +Any time you use `fedpkg new-sources` or `fedpkg upload`, +you must remember to `commit` changes to those files. + +`new-sources` 'starts from scratch', +replacing all files currently in the lookaside cache. +You will typically use this command for many packages with just a single source tarball, +each time you update to a new upstream version. +`upload` just adds the given file to those already in the cache. +Do remember not to leave stale sources lying around. + +=== Switch to a different release branch +.... +fedpkg switch-branch +.... + +Each Fedora release has its own branch in each package repository +so different builds can be sent to each release. +See below for more details on working with branches. + +=== Generate git changelog from package changelog +.... +fedpkg clog +.... + +This command extracts your package changelog entry to the file `clog`, +so you can use it as the git changelog if you like. +Some maintainers draw a distinction between the two, +some do not. + +=== Commit changes +.... +fedpkg commit (-F clog) (-p) (-c) +.... + +This behaves by default like `git commit -a`: +It stages modified files and commits all at once, +though it does not add files which git is not yet tracking. + +This creates a sort of bundle, +a 'commit', of your changes to the repository, +with a unique identity and a changelog. +Other maintainers — and you yourself, later — +can view the history of changes to the repository +with the commit as the finest level of detail. +It is good practice to use many relatively small commits, +each for a single purpose. +Do not combine a version bump +with a bunch of whitespace fixes and some scriptlet changes +all in one commit, +create separate commits for each. + +The `-F clog` parameter will use the `clog` file from the previous step as the changelog. +`-p` will push (see below) at the same time as committing. +`-c` combines the clog and `commit -F clog` steps into one, if you like that. + +=== Push changes +.... +fedpkg push +.... + +This sends all the new commits in your local working copy to the upstream server. +If you are still learning the system, +now is a good time to `fedpkg co` another copy of the repository somewhere else, +compare what you get to your working copy, +and run a test build on it. + +=== Do an 'official' build of the latest pushed changes +.... +fedpkg build +.... + +=== Submit 'official' builds from a stream branch +.... +fedpkg build +.... + +There is no difference in the command line +to submit multiple builds from a stream branch. +But you need to create a config file `package.cfg` in the repository +and set option for the builds. +For example config file is created in a stream branch `8` of package `foo`, which has content: + +.... +[koji] +targets = f28 epel7 +.... + +This example shows when you execute the `build` command, +`fedpkg` is able to submit builds for releases, `f28` and `epel7`. + +In practice, you are able to specify two shortcut names `fedora` and `epel` for convenience. +`fedpkg` retrieves current active Fedora and EPEL releases automatically. +Hence, if you do not want to select a subset of releases, +or just simply going to build packages for active releases +without knowing the concrete release name, +shortcut names would be helpful. +You can specify to build for `rawhide`, use name `master`. + +=== Do a Container Layered Image Build +.... +fedpkg container-build +.... + +See https://fedoraproject.org/wiki/Changes/Layered_Docker_Image_Build_Service[Container Layered Image Build] for details. + +=== Submit a package update for the latest build +.... +fedpkg update +.... + +CAUTION: This is the first point at which you might possibly cause real mess for a real user, +so use it with caution. +If you are following the example and operating on Rawhide, +your build would go live for Rawhide users +some few hours after you ran this command. + +Unlike most of the above commands, +this operates on the state you have pushed to git, +not the local state. +If you have issues +make sure you have pushed and committed all patches +and handled the sources correctly. + +See xref:Package_Update_Guide.adoc#updating_inter_dependent_packages[Updating inter-dependent packages] +if you are making inter-dependent changes +to more than one package. + +[[typical_fedpkg_session]] +== Typical fedpkg session + +A typical session may look like this: + +.... +fedpkg clone foo +cd foo +fedpkg sources +fedpkg new-sources foo-0.0.2.tar.bz2 +gedit foo.spec # change the required things in the specfile. + # rpmdev-bumpspec is useful for simple version updates +fedpkg mockbuild # check that the changes you made are correct +fedpkg diff +fedpkg lint +fedpkg commit -p -c # commit and push in one go +.... + +[[working_with_branches]] +== Working with branches + +Each Fedora release is represented by a branch in the git repository. +You can switch between them like this: + +.... +fedpkg switch-branch f34 +fedpkg switch-branch f33 +fedpkg switch-branch rawhide +.... + +The `rawhide` branch is for https://fedoraproject.org/wiki/Releases/Rawhide[Rawhide]. +You can maintain each branch entirely separately, if you like, +laboriously copying changes between them +(so long as you always stay within the https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/[Updates Policy] requirements). +However, git provides us with several handy tools for working with branches. +Here's an example: + +.... +fedpkg clone bzrtools +# Make some changes in the rawhide branch +fedpkg new-sources bzrtools-2.2.tar.gz +gedit bzrtools.spec +fedpkg commit +fedpkg switch-branch f34 +git merge rawhide +# for push into repo +fedpkg push +.... + +This will _merge_ the changes from the `rawhide` branch to the `f34` branch. +Git aficionados may note this is a somewhat unusual workflow, +but it is appropriate to the context of package management. +Remember, +after pushing to and building for a stable release +or a https://fedoraproject.org/wiki/Releases/Branched[Branched] release +after https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#updates-testing-activation[updates-testing activation], +you will have to xref:Package_Update_Guide.adoc[submit an update] +before any other Fedora users will see your build. + +Note that merges will only be sure to work cleanly +so long as the branches have not previously diverged. +That is, if you do this: + +.... +fedpkg clone bzrtools +# Make some changes in the rawhide branch +fedpkg commit +fedpkg switch-branch f34 +# Make some changes in the f34 branch +fedpkg commit +fedpkg switch-branch rawhide +# Make some more changes in the rawhide branch +fedpkg commit +fedpkg switch-branch f34 +git merge rawhide +.... + +you may encounter a _merge conflict_. + +Remember that git is a _collaborative_ system, +and used as such in Fedora package management. +It is often the case that you must consider +changes made by others +in working on a package, +and consider how your changes will affect others. + +[[resolving_merge_conflicts]] +=== Resolving merge conflicts + +This is a large topic and somewhat beyond the scope of this guide, +but we can give basic pointers. +There are other good references in the http://git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging[git book] +and at https://help.github.com/articles/resolving-a-merge-conflict-from-the-command-line[GitHub]. + +When you merge and a conflict occurs, +you can edit the files that have conflicts. +Remove the conflict markers in the files +and merge the changes manually. +Use `git diff` or `fedpkg diff` to inspect the changes +against the pre-conflict state +and verify you are happy with the resolution. +Then you can commit the files with `fedpkg commit` or `git commit -a`. +Git will know if you have resolved the conflict +by checking that all the conflict markers have been removed. + +[[using_git_mergetool_to_resolve_conflicts]] +=== Using git mergetool to resolve conflicts + +Git provides a graphical diff program to help resolve conflicts. +This can be handy for visualizing what changes have occurred +and dealing with them as a set. + +.... +git config --global merge.tool meld +fedpkg switch-branch f{{FedoraVersionNumber}} +git merge rawhide +# Conflicts occurred +git mergetool # Opens up a meld showing a three way diff of + # the merge, working tree, and the last commit +# Resolved all the conflicts in the GUI +git add CONFLICTEDFILES +git commit +.... + +[[requesting_special_dist_tags]] +== Requesting special dist tags + +When a change to a package affects a large number of dependencies +(e.g. all perl, python, ruby or ghc packages), +requiring them to be rebuilt, +it may be better to initially do the builds in a special repository, +so that there is less disruption in Rawhide. + +If you think you have an update that falls under this case +you can request a special dist tag +by filing a https://pagure.io/releng/new_issue[release engineering ticket]. +Someone from https://docs.pagure.org/releng/[release engineering] will likely want +to discuss your needs +to make sure this is really an appropriate case +(it's OK ask if you aren't sure) +and that you get what you need. + +[[using_fedpkg_anonymously]] +== Using fedpkg anonymously + +You can use fedpkg like this: + +.... +fedpkg clone --anonymous +.... + +to check out a package without requiring identification. +Obviously, you will not be able to push any changes to this repository, +but it is useful for non-packagers +who simply want to examine a package +and make changes for their own use. + +If the intention is to submit changes to a Fedora developer, +the package repository can be forked +and a pull request submitted. +Forking is done in the https://src.fedoraproject.org[src.fedoraproject.org] web ui. +You need a https://accounts.fedoraproject.org/[Fedora account] to be able to fork. +After the fork has been created, +typical `fedpkg` session might look like this: + +.... +fedpkg clone --anonymous forks/my-username/rpms/somepackage +cd somepackage +gedit somepackage.spec # change the required things in the specfile. + # rpmdev-bumpspec is useful for simple version updates +spectool -g somepackage.spec # download the referenced sources to local machine + # fedpkg new-sources cannot be performed anonymously, that is left + # for the maintainer to do after the pull request has been merged +fedpkg mockbuild # check that the changes you made are correct +fedpkg diff +fedpkg lint +git checkout -b my-branch # create a branch to use in the pull request +fedpkg commit -p -c # commit and push in one go +.... + +Afterwards, +a pull request from `my-branch` to the main package repository +can be created in the _src.fedoraproject.org_ web ui. + +[[tips_and_tricks]] +== Tips and tricks + +[[local_branch_names]] +=== Local branch names + +If you use git commands to branch and checkout directly, +you can define whatever local branch names you want. +If you use `fedpkg switch-branch`, +it will default to creating the names used in the examples above. + +[[current_branch_and_state_in_shell_prompt]] +=== Current branch and state in shell prompt + +It is often helpful to know what branch you are working on +at a glance. +You can add this information to your bash prompt +with the information https://fedoraproject.org/wiki/Git_quick_reference?rd=Git_Quickref#Display_current_branch_in_bash[here]. + +[[importing_a_.src.rpm_to_update]] +=== Importing a .src.rpm to update + +The command usually used to initially populate a git package repository +from a .src.rpm that has been through the xref:Package_Review_Process.adoc[Package Review Process] +can also be used to update a normal working copy, +if you have an old-school packaging process +to which you are particularly attached. +Just run `fedpkg import file.src.rpm` +and it will upload new tarballs into lookaside cache, +update a working copy of the last version found in git, +and commit all changes. +`fedpkg import --help` documents some other parameters it can accept. + +CAUTION: This approach makes it harder to verify that your changes are safe +and do not overwrite changes made to the package by others. +For this reason, its use is not recommended. + +[[making_changes_on_an_older_branch_without_breaking_the_upgrade_path]] +=== Making changes on an older branch without breaking the upgrade path + +Here is the scenario: +You have built your package successfully on the `f34` branch, +but there is a problem keeping your package from building on `last`. + +Solution: +Make your changes in the branch +and then add a digit to the very right of the release tag. +There is no need to change the release in the other branches. +This allows upgrades to work smoothly +if the user upgrades to a newer release of Fedora. + +.... +Name: foo +Version: 1.0 +Release: 1%{?dist} + +Name: foo +Version: 1.0 +Release: 1%{?dist}.1 +.... + +Then tag and build as usual. +This approach was initially discussed https://www.redhat.com/archives/fedora-extras-list/2006-May/msg00083.html[in this mailing list thread]. + +[[removing_a_package_build_pending_for_rawhide_or_branched]] +=== Removing a package build pending for Rawhide or Branched + +From time to time +you may want to remove a package build you submitted to Rawhide or to Branched +prior to the Alpha freeze +(both cases where the build would usually go +out to the main https://docs.fedoraproject.org/en-US/quick-docs/repositories/[repository] +without further gating). +This could happen in a situation +where a bug or issue is found in your package +that will be resolved upstream in the next release, +or you realize you made a significant mistake in the build +that cannot easily be corrected. + +CAUTION: This should only be done on the same day of the build, +before it is included in a compose. +If your build was already included in a compose you must not untag it! +Check the https://pdc.fedoraproject.org//[Product Definition Center] to get the starting time of the last compose. + +You can remove the package by using https://fedoraproject.org/wiki/Koji[Koji]: + +.... +koji untag-pkg f35 foo-1.1.3-1.fc35 +.... + +where `foo-1.1.3-1.fc35` is replaced with the name of your package build. +See `koji help` or xref:Using_the_Koji_Build_System.adoc[Using the Koji Build System] for more information. + +[[ssh_fingerprint]] +=== ssh fingerprint + +The recommended option is to include `VerifyHostKeyDNS yes` +in your `~/.ssh/config` file. +This will result in using DNS to check that the key is correct. + +But you can also manually check +against the list of keys at https://admin.fedoraproject.org[https://admin.fedoraproject.org]. +The strings there are what ends up in your `~/.ssh/known_hosts` file. +So you can accept the fingerprint when prompted +and then check that the correct string for src.fedoraproject.org +ended up in your `~/.ssh/known_hosts` file. + +[[problems_connecting_to_the_repository]] +=== Problems connecting to the repository + +The `fedpkg` tool clones repositories using the ssh:// protocol, +so this should not be a problem normally +(as long as you have your ssh key). +If you cloned using the `git` utility itself, +check the `.git/config` file +to ensure the remote repository is being accessed via an ssh:// protocol, +and not git://. + +[[it_builds_here_why_doesnt_it_build_there]] +=== It builds here, why doesn't it build there? + +Is your package building locally +— even with Mock, even as a scratch build! +— but not when you run `fedpkg build`? +Before you get too frustrated, +remember `fedpkg build` runs on the package as it exists in the upstream repository, +not your local working copy. +Make sure you have committed and pushed all changes and source files, +and handled the lookaside cache correctly. +Other issues that have been reported, +are issues because of https://bugzilla.redhat.com/show_bug.cgi?id=1179139[build/make check parallelization] +and failures because of test suites that depend on operations finish on precise timing +(and a busy build system may not be able to perform operations on time). + +== References + +* https://src.fedoraproject.org/ +* https://fedoraproject.org/wiki/Infrastructure/Kerberos[Infrastructure/Kerberos] +* https://fedoraproject.org/wiki/Packaging_tricks?rd=PackageMaintainers/PackagingTricks[PackageMaintainers/PackagingTricks] +* https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle?rd=Policy_for_package_lifecycle[Fedora_Release_Life_Cycle] +* https://fedoraproject.org/wiki/Infrastructure/VersionControl/dist-git[Infrastructure/VersionControl/dist-git] diff --git a/modules/ROOT/pages/Package_Orphaning_Process.adoc b/modules/ROOT/pages/Package_Orphaning_Process.adoc new file mode 100644 index 0000000..3d78a4f --- /dev/null +++ b/modules/ROOT/pages/Package_Orphaning_Process.adoc @@ -0,0 +1,67 @@ += Package Orphaning Process +:toc: + +This page contains instructions for working with orphan packages +as specified in https://fedoraproject.org/wiki/Policy_for_Orphan_and_Retired_Packages[Policy for Orphan and Retired Packages]. + +[[orphaning_procedure]] +== Orphaning Procedure + +. If the package has co-maintainers, contact them +to ask whether one of them wants to take over ownership of the package. +This step is optional. +If no co-maintainer can be found to take over the package, +the package should be given to the `orphan` user. + +The current list of maintainers can be found in the _Users & Groups_ tab +of the setting for the package repo. +The URL will look something like this: +`https://src.fedoraproject.org/rpms/PACKAGE_NAME/settings.` + +. After the first step is finished, +go again to the settings tab for your package's Pagure repository. +Navigate down to the _Give Project_ section +and _give_ the project to the new maintainer +or the `orphan` user (in case no new maintainer was selected). + +. For completeness, +under the _Users and Groups_ section, +remove yourself from the list as well. + +. Also reset your watch status +if you do not want to be CC'ed on new package bugs. + +. If the package was given to the `orphan` user, +announce on the https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/[devel mailing list] +which package you orphaned, +so that others have a chance to take over as maintainer. + +. Reassign the package's tickets to the orphan user, +`extras-orphan@fedoraproject.org`. + +After completing these steps, the package is orphaned. +If nobody takes over the orphan package in six weeks, +it is automatically retired by https://docs.pagure.org/releng/[Release Engineering]. + +[[claiming_ownership_of_an_orphaned_package]] +== Claiming Ownership of an Orphaned Package + +. Check why the package was orphaned +by looking for the email at https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/[devel]. + +. Announce on https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/[devel] which packages you want to take over. + +. Log in to https://src.fedoraproject.org/[src.fedoraproject.org]. +On the page with the orphaned package, +click the _✋ Take_ button in the left column. +(If the option doesn't work for you, +https://pagure.io/releng/new_issue?template=package_unorphan&title=Unorphan%20%3Cpkgname%3E[submit a ticket to the Release Engineering team], +stating which package you want to claim +and that this option didn't work.) + +. Reassign and claim all open bug reports for the package in Bugzilla. + +[[lists_of_orphan_and_retired_packages]] +== Lists of Orphan and Retired Packages + +* https://src.fedoraproject.org/user/orphan[A list of currently orphaned and/or retired packages] diff --git a/modules/ROOT/pages/Package_Renaming_Process.adoc b/modules/ROOT/pages/Package_Renaming_Process.adoc new file mode 100644 index 0000000..dc2701b --- /dev/null +++ b/modules/ROOT/pages/Package_Renaming_Process.adoc @@ -0,0 +1,35 @@ += Package Renaming Process +:toc: + +For a variety of reasons it may become necessary to rename a package in Fedora. +The goal of this page is to outline the process +that must be followed +when such an event occurs. + +[[re_review_required]] +== Re-review required + +When you wish to rename a package, +you *MUST* request a re-review of your package through the xref:Package_Review_Process.adoc[Package Review Process]. +In this review request, +you *MUST* state that this is a re-review request for a package rename, +and the old package name that this is replacing. + +The reviewer of the package *MUST* explicitly acknowledge this fact, +and check the package for the proper Obsoletes and Provides +(see https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/#_renamingreplacing_existing_packages[Naming Guidelines] for more information.) +They *MUST* document in the review request that they have done so. + +[[after_the_review]] +== After the review + +After the review is completed, and is satisfactory +(for the avoidance of doubt, +the lack of a clean upgrade path for users of the package +in the form of proper Provides and Obsoletes +is considered a blocker to the review), +request git for the package +as you normally would for a new package. + +After the new package is imported into git, +you can follow the xref:Package_Retirement_Process.adoc[Package Retirement Process] for the old package. diff --git a/modules/ROOT/pages/Package_Retirement_Process.adoc b/modules/ROOT/pages/Package_Retirement_Process.adoc new file mode 100644 index 0000000..ef053bf --- /dev/null +++ b/modules/ROOT/pages/Package_Retirement_Process.adoc @@ -0,0 +1,186 @@ += Package Retirement Process +:toc: + +When a package reaches the end of its useful life, +the Package Retirement Process lets other people +— and automated processes! — +know both not to expect any more releases, and why it was removed. The process is governed by https://fedoraproject.org/wiki/Policy_for_Orphan_and_Retired_Packages[Policy for Orphan and Retired Packages]. + +[[what_can_be_retired] +== What can be retired == + +Packages can normally only be retired in the following branches: + +* Branched (until the Final Freeze) +* Rawhide +* EPEL branches (epel7, epel8) + +== Procedure + +Please execute the following steps in the order indicated. + +=== RPM + +If the package is being replaced by some other package, +ensure that the `Obsoletes`/`Provides` tags are properly set by the new package +as specified in https://docs.fedoraproject.org/en-US/packaging-guidelines/#renaming-or-replacing-existing-packages[Renaming/Replacing Guidelines]. + +=== Git + +Run `fedpkg retire DESCRIPTION` +in Fedora branches Rawhide and Branched (if it exists at the moment) +and all EPEL branches (if applicable). +`DESCRIPTION` should explain why the package was retired. +Examples of good messages are _Obsoleted by bar_ and _Renamed to bar_. + +The command will remove all files from the branch, +add a file name `dead.package` containing the description +and push the changes. + +Do not run the command in any supported or end-of-life Fedora release branch. +Packages must not be retired from stable releases. + +Start retiring from the oldest branch, +i.e. retire on Branched before you retire on Rawhide. +If you retire Rawhide before Branched, +it will still work, but will block the package in more Koji tags, +because tag inheritance will not be used automatically then. + +=== Comps + +Remove the package from https://fedoraproject.org/wiki/How_to_use_and_edit_comps.xml_for_package_groups[comps] if it is listed. + +=== Spins + +Remove the package from any https://pagure.io/fedora-kickstarts[spin kickstart file]. + +[[upstream_release_monitoring]] +=== Upstream Release Monitoring + +Remove the package from xref:Upstream_release_monitoring.adco[Upstream release monitoring] if it is listed. + +=== Koji + +To keep retired packages from being pushed to the mirrors, +they need to be blocked in Koji. +This will happen automatically during the next compose +(for rawhide, the branched release and for EPEL). + +You can check whether a package is blocked in koji +with `koji list-pkgs --show-blocked`. +There should an entry with `[BLOCKED]` +for each branch the package was retired in. +It is enough for a package to be blocked in an older tag +to be also blocked in a newer tag +due to inheritance. Example output: + +.... +$ koji list-pkgs --show-blocked --tag f21 --package curry +Package Tag Extra Arches Owner +----------------------- ----------------------- ---------------- --------------- +curry f20 gemi [BLOCKED] +.... + +Please wait for two days to allow for a compose to happen +and mirrors to be updated. +If the package is not blocked automatically after two days, +please file a https://pagure.io/releng/new_issue[ticket for release engineering] +and mention package names +and the branches where the packages need to be blocked. +Use only one ticket for all the packages you retired at once, +do not open one ticket for each package if you retired several packages. + +== EPEL + +The retirement process can be used for EPEL as well +with one difference: + +* You can remove the package from any EPEL branch +whether or not it has been released. + +For example, if your package has been added to base RHEL in RHEL-6.4 +then perform the steps above +but use the `el6` branch instead of `rawhide`. + +When you need to add package from EPEL to any RHEL release, +only retire EPEL branch when package is released in that RHEL release. + +[[claiming]] +== Claiming Ownership of a Retired Package + +If you really want to maintain a retired package, +you need to be aware that if upstream is dead, +fixing release critical bugs, etc +becomes your responsibility. +This is to ensure the high quality and standards of packaging +remain for Fedora package collection. +There may be additional issues with retired packages. +If possible, consult with the former maintainer for more information. +The process is a bit different from unorphaning a package. + +. See if you can figure out why the package was retired +including searching for information about orphaned packages on https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/[devel mailing list] +or emailing the former maintainer. +You can also check `dead.package` in the SCM +(url like: https://src.fedoraproject.org/rpms/system-config-network/blob/rawhide/f/dead.package[https://src.fedoraproject.org/rpms/**package_name_here**/blob/rawhide/f/dead.package]) + +. Announce on https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/[devel] +which packages you would like to become the owner of. + +. Retired Fedora packages (rawhide branch retired) require a re-review +if they are retired for more than eight weeks +or if there is no previous review of the package. +Submit a review request (a new bugzilla ticket) +and have the package approved by a reviewer +as if it were new to Fedora. +See the xref:Package_Review_Process.adoc[Package Review Process] for more information. +To unretire a EPEL branch if the package is still in Fedora, +no re-review is required. + +. Request unretirement by filing a https://pagure.io/releng/new_issue?template=package_unretirement&title=Unretire%20%3Cpkgname%3E[releng ticket]. +Specify all branches that need to be un-retired +(including `rawhide` for Rawhide, unless it is for EPEL only) +and include the link to re-review. +In this ticket, +request that the https://docs.pagure.org/releng/[Release Engineering team] unblock the package +for the releases that the package should be un-retired for. +In this request, +clearly specify which branches should be unblocked. + +. Restore the contents in Git and prepare a new build and update (if necessary). + +[[obsoleting_packages]] +== Obsoleting Packages + +While not strictly part of the process, +please consider what will happen +to systems which have the now-retired packages installed. +Generally, such packages will simply remain on the system as it is updated, +becoming increasingly outdated. + +Please consider adding your package to https://src.fedoraproject.org/rpms/fedora-obsolete-packages/[fedora-obsolete-packages]. + +Please follow https://docs.fedoraproject.org/en-US/packaging-guidelines/#renaming-or-replacing-existing-packages[the relevant packaging guidelines] +if another package will be providing +similar or identical functionality to the retired package, +or if it is necessary that the package be removed from end-user systems +on system updates. + +[[complete_removal]] +== Completely Removing a Package + +In rare cases, such as when licensing issues are discovered, +it may be necessary to completely remove a package from Fedora. +This differs from normal retirement +in that the package is removed also from stable and end-of-life releases. + +For complete removal, first follow the xref:Procedure[procedure for normal removal]. + +Additionally, retire the package in '''all''' dist-git branches. +Since `fedpkg retire` refuses to work on stable branches, +simulate it with the following: +.... +$ DESC="my description"; git rm -r . && echo "$DESC" > dead.package && git add dead.package && git commit -m "$DESC" +.... + +Finally, add the package to fedora-obsolete-packages. diff --git a/modules/ROOT/pages/Package_Review_Process.adoc b/modules/ROOT/pages/Package_Review_Process.adoc new file mode 100644 index 0000000..b296576 --- /dev/null +++ b/modules/ROOT/pages/Package_Review_Process.adoc @@ -0,0 +1,327 @@ += Package Review Process +:toc: + +[[review_purpose]] +== Review Purpose + +In order for a new package to be added to Fedora, +the package must first undertake a formal review. +The purpose of this formal review is to try to ensure +that the package meets the quality control requirements for Fedora. +This does not mean that the package +(or the software being packaged) +is perfect, +but it should meet baseline minimum requirements for quality. + +Reviews are currently done for +totally new packages, +xref:Package_Renaming_Process.adoc#re_review_required[package renames], +old packages that were once retired returning to the collection, +and packages merged from the old Fedora Core repository. + +Note that some new packages may be exempt from the review process. +Please see https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/#_package_review_process[the list of criteria]. +If an exemption is warranted, +the contributor can skip directly to +requesting a repository for it. +The request to create a repo should include the `--exception` flag +instead of a bug number: +.... +fedpkg request-repo --exception +.... + +[[review_process]] +== Review Process + +There are two roles in the review process, +that of the contributor and that of the reviewer. +In this document, we'll present both perspectives. + +=== Contributor + +A Contributor is defined as someone who wants to submit +(and maintain) +a new package in Fedora. +To become a contributor, +you must follow the detailed instructions to xref:Joining_the_Package_Maintainers.adoc[Joining the Package Maintainers]. + +As a Contributor, you should have already made a package +which adheres to the https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/[Package Naming Guidelines] +and https://docs.fedoraproject.org/en-US/packaging-guidelines/[Packaging Guidelines]. +There are also some packages that cannot be included in Fedora, +to check if your package applies, +check if it contains any https://fedoraproject.org/wiki/Forbidden_items[Forbidden Items]. + +When you're happy with your spec file, +you should then submit that SRPM to a package review. +Currently, this is done by following these steps: + +* Put your spec file and SRPM somewhere on the Internet +where it can be directly downloaded +(just http(s), no registration pages or special download methods, please). +If you have no place to put your spec and SRPM, +use https://copr.fedorainfracloud.org/[copr]. + +* Fill out a https://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Fedora&format=fedora-review[request for review in bugzilla]. +Make absolutely certain to file this bug +with an account tied to your FAS email address, +otherwise your followup requests will be closed as invalid. + +TIP: If nobody comments on your review request, +you might want to mail to a mailing list (for example, devel) +asking for a "review swap". +This is an offer to do a review of someone else's package +in exchange for them reviewing your package. +This is usually one-for-one, +or can be some other private arrangement +depending on the difficulty of the respective packages. + +* If you do not have any package already in Fedora, you need a sponsor. +Add https://bugzilla.redhat.com/show_bug.cgi?id=FE-NEEDSPONSOR[FE-NEEDSPONSOR] to the bugs being blocked by your review request. +For more information read xref:How_to_Get_Sponsored_into_the_Packager_Group.adoc[How to Get Sponsored into the Packager Group]. + +* Wait for someone to review your package! +At this point in the process, the `fedora-review` flag is blank, +meaning that no reviewer is assigned. + +* There may be comments from people that are not formally reviewing the package, +they may add `NotReady` to the _Whiteboard_ field, +indication that the review request is not yet ready, +because of some issues they report. +After you have addressed them, +please post the URLs to the updated SPEC and SRPM file +and clear the Whiteboard. +It is expected that you will respond to commentary, +including updating your submission to address it; +if you do not, your ticket will be closed. + +* A reviewer takes on the task of reviewing your package. +They will set the `fedora-review` flag to `?`. + +* The reviewer will review your package. +You should fix any blockers that the reviewer identifies. +Once the reviewer is happy with the package, +the `fedora-review` flag will be set to `+`, +indicating that the package has passed review. + +* If you have not yet been sponsored, +request sponsorship by https://pagure.io/packager-sponsors/new_issue[raising an issue at package sponsors]. + +* When your package passes the review + you should use `fedpkg` to request a Git repository for it. + Before you can request a Git repository for the package, + you will need a https://pagure.io/settings/token/new[pagure api token] + with _Create a new ticket_ ACL + added into `~/.config/rpkg/fedpkg.conf`: +.... +[fedpkg.pagure] +token = +.... + +* Request a Git repository for the package. +For example, if your bugzilla review ticket is 12345, +use: `fedpkg request-repo 12345`. +Check that your review bug is valid. +It must have the `fedora-review` set to `+`, +and it must be assigned to your reviewer. +Otherwise your repository request will be closed as invalid. + +* If you want to add your package to more Fedora releases +and not just Rawhide, +let's say to Fedora 34, +you can use the following command to request additional branches: +`fedpkg request-branch --repo f34`. +You must wait for your repository to be created +before filing your branch request, +otherwise your branch request will be closed as invalid. + +* When this is complete +(https://pagure.io/releng/fedora-scm-requests/issues[tickets in Pagure] for requests above are closed as processed), +checkout the package: +.... +fedpkg clone +.... + +* Now you can xref:Joining_the_Package_Maintainers.adoc#import_commit_and_build_your_package[import your SRPM package]. +Do a final check of spec file tags, etc. + +* Request a Koji build by running `fedpkg build`. +(You will need to set up https://fedoraproject.org/wiki/Infrastructure/Kerberos[Kerberos for Fedora project]) + +* Repeat the process for other branches you may have requested above: +** Checkout given branch: `fedpkg switch-branch f34` +** Let Koji build the package for this branch: `fedpkg build` + +* Request updates for Fedora release branches, if necessary, +using `fedpkg update` +or another Bodhi interface as detailed in https://fedoraproject.org/wiki/Bodhi[Bodhi]. + +* If possible, add your package to xref:Upstream_Release_Monitoring.adoc[Upstream Release Monitoring]. + +* To be notified if your package stops building successfully +when dependencies are updated in Fedora, +you can enable https://fedoraproject.org/wiki/Koschei[Koschei]. + +* You should make sure the review ticket is closed. +You are welcome to close it +once the package has been built on the requested branches. +If you built for one of the Fedora release branches +you can ask Bodhi to close the ticket for you +when it completes the process. +If you close the ticket yourself, use `NEXTRELEASE` as the resolution. + +You do not need to go through the review process again +for subsequent package changes, +and should not reference the review ticket in subsequent updates +you create in Bodhi. + +=== Reviewer + +The Reviewer is the person who chooses to review a package. + +The Reviewer can be any Fedora account holder +who is a member of the https://accounts.fedoraproject.org/group/packager/[packager group]. +(If the Contributor is not yet sponsored, +the review can still proceed to completion +but they will need to find a sponsor at some point.) + +* Search http://fedoraproject.org/PackageReviewStatus/[Package Review Tracker] for a review request +that needs a reviewer: `fedora-review` flag is blank or the bug is assigned to `nobody@fedoraproject.org`. + +* If you notice some issues that need to be solved +before you want to start a formal review, +add these issues in a comment +and set the _Whiteboard_ of the bug to contain `NotReady`. +This helps other possible reviewers +to notice that the review request is not yet ready for further review action. + +* If you want to formally review the package, +set the `fedora-review` flag to `?` +and assign the bug to yourself. + +* Review the package + +** Go through the MUST items listed in https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/[Review Guidelines] . + +** Go through the SHOULD items in https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/[Review Guidelines] . + +** The https://pagure.io/FedoraReview[FedoraReview] tool +(packaged as `fedora-review`) +can help to automate this process. + +* Include the text of your review in a comment in the ticket. +For easy readability, simply use a regular comment +instead of an attachment. + +* Take one of the following actions: +** *ACCEPT* - If the package is good, set the `fedora-review` flag to `+`. + +** *FAIL, LEGAL* - If the package is legally risky for whatever reason +(known patent or copyright infringement, trademark concerns) +close the bug as `WONTFIX` +and leave an appropriate comment +(i.e. _we don't ship mp3, so stop submitting it_). +Set the `fedora-review` flag to `-`, +and have the review ticket block https://bugzilla.redhat.com/show_bug.cgi?id=FE-Legal[FE-Legal]. + +** *FAIL, OTHER* - If the package is just way off +or unsuitable for some other reason, +and there is no simple fix, +then close the bug as `WONTFIX` +and leave an appropriate comment +(i.e. _we don't package pornography for redistribution, sorry._ +Or, _this isn't a specfile, it's a McDonald's menu, sorry._) +Set the `fedora-review` flag to `-`. + +** *NEEDSWORK* - Anything that isn't explicitly failed should be left open +while the submitter and reviewer work together to fix any potential issues. +Mark the bug as `NEEDINFO` +while waiting for the reviewer to respond to improvement requests. +This makes it easier for reviewers to find open reviews +which require their input. + +* Once a package is flagged as `fedora-review +` (or `-`), +the Reviewer's job is done +although they may be called upon to assist the Contributor +with the import/build/update process +and to ensure that the Contributor closes the ticket +when the process is complete. + +[[definitions_for_fedora_review_flag_settings]] +== Definitions for fedora-review flag Settings + +[cols=",,",] +|=== +|fedora-review |(BLANK) |Package Needs Review +|fedora-review |? |Package Under Review +|fedora-review |- |Package Failed Review, dropped for legal or other issues. +|fedora-review |+ |Package Approved +|=== + +[[special_blocker_tickets]] +== Special blocker tickets + +There are a few tickets which can be placed in the "Blocks" field +to indicate specific ticket statuses: + +[cols=",",] +|=== +|FE-NEEDSPONSOR |The submitter requires a sponsor; the review can be done by anyone, but a sponsor will need to come and sponsor the submittor. +|FE-DEADREVIEW |The review has been closed out because the submitter has left; users looking for packages to submit may find some possibilities in these dead tickets. +|FE-Legal |The package is currently awaiting review by the legal team. +|=== + +[[the_whiteboard]] +== The Whiteboard + +To save time for reviewers, +the https://fedoraproject.org/PackageReviewStatus/reviewable.html[New, reviewable Fedora package review tickets] page +will hide certain tickets which are not reviewable. +The _Whiteboard_ field can be used +to mark a ticket with various additional bits of status +which will cause it to be hidden +or displayed differently. + +[cols=",",] +|=== +|NotReady |The package is not yet ready for review. It is possible to open a review ticket, mark it as NotReady, and continue to work on it until it's ready to be seen by a reviewer. +|BuildFails |The package fails to build. +|AwaitingSubmitter |The package review is stalled and cannot proceed without input from the submitter. +|Trivial |The package is trivial to review. See below. +|=== + +The `Trivial` status is intended to indicate packages which, +as an aid to new reviewers, +are especially uncomplicated and easy to review. +A ticket should not be marked as being trivial unless: + +* The package is known to build +and a link to a scratch build is included. + +* The ticket explains any rpmlint output which is present. + +* The spec contains nothing which is unnecessary in modern Fedora +(such as `BuildRoot:`, a `%clean` section or `%defattr`). + +* The spec is free from excessive or complicated macro usage. + +* The spec uses only the least complicated scriptlets +which are taken directly from the https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/[Scriptlets] page. + +* The package contains no daemons. + +* The package is not especially security sensitive. + +* The code has undergone a thorough inspection for licensing issues. +Anomalies which would be found by `licensecheck` should be explained. + +In short, this should be reserved only for those tickets +which should be easily approachable +by someone doing their first package review. + +[[tracking_of_package_requests]] +== Tracking of Package Requests + +The http://fedoraproject.org/PackageReviewStatus[Package Review Tracker] provides various review-related reports +and a simple way to search for reviews +by package name or reporter name or others. diff --git a/modules/ROOT/pages/Package_Update_Guide.adoc b/modules/ROOT/pages/Package_Update_Guide.adoc new file mode 100644 index 0000000..7487863 --- /dev/null +++ b/modules/ROOT/pages/Package_Update_Guide.adoc @@ -0,0 +1,546 @@ += Package Update Guide +:toc: + +This document shows how to submit an update +for a package you maintain in Fedora. +It assumes you already have a package in the Fedora repositories. +It is not a guide to using the Fedora package source control system: +see xref:Package_Maintenance_Guide.adoc[Package Maintenance Guide] for that. + +* For details of the policy on requirements for updates +at various stages of the https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle[Fedora Release Life Cycle], +refer to the https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/[Updates Policy]. + +== Overview + +This page is intended for new and existing package maintainers. +Testers and regular users may be interested in the https://fedoraproject.org/wiki/QA:Updates_Testing[updates-testing] repository +and the https://fedoraproject.org/wiki/QA:Update_feedback_guidelines[Update feedback guidelines]. +This page specifically covers the update submission process. + +There are two significantly different package update submission workflows in Fedora: + +* https://fedoraproject.org/wiki/Releases/Rawhide[Rawhide] +and https://fedoraproject.org/wiki/Releases/Branched[Branched] up to the https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#updates-testing-activation[Updates-testing Activation]. + +* Branched releases after Updates-testing Activation, +and stable releases. + +The repository layouts differ somewhat for Rawhide, Branched and stable releases, +but the update workflows split up as described above. + +[[rawhide_and_early_branched]] +== Rawhide and early Branched + +[[single_packages]] +=== Single Packages + +The update workflow for single package builds +in Rawhide and Branched before updates-testing activation +is simple: + +. Build the package with `fedpk build`. See xref:Package_Maintenance_Guide.adoc[Package Maintenance Guide] for more details. + +This is all you need to do, +a Bodhi update will be created automatically, +from which potential tests will be run. + +* If the built package doesn't have tests, +or if they succeed, +the update will be marked as _stable_ +and your package will appear in subsequently created build roots, +as well as in the next daily compose of Rawhide or Branched +and will be used in any image composes built from that tree. + +* If the built package has tests which fail, +this will be recorded in the update. +You can now either xref:waive_a_result[waive the failing tests] +if you're sure that the test shouldn't fail, +or fix whatever is wrong with the package, +build it again, +which in turn will create an update, +running the tests +(on the now hopefully fixed package), +and so forth. + +[[multiple_packages]] +=== Multiple Packages + +Some updates require changes in multiple related packages, +e.g. if a library is upgraded to a new major version +and packages using it need to be rebuilt. + +Fedora has the concept of using side-tags for these situations, +which means the builds are done "on the side" +and do not affect packages out of the side-tag, +nor are they available for installing +until the side-tag is merged. + +Packagers can create side-tags on their own, +allowing them to build disruptive components in isolation +and submit the builds in a side-tag +as one update in Bodhi, +to be tested and subsequently merged into the main distribution. + +[[creating_a_side_tag]] +==== Creating a side-tag + +To create a side-tag for building packages for Rawhide, +the easiest way is to be +in the checked out `rawhide` branch of one of the packages +and issue the following command: + +.... +fedpkg request-side-tag +.... + +Alternatively, you can specify the parent/base tag +from which to create the side-tag, e.g.: + +.... +fedpkg request-side-tag --base-tag f32-build +.... + + +NOTE: Side-tags for particular Fedora releases are based off its respective build tag. +I.e. if you wanted to create a side-tag for Rawhide +while it's ramping up for Fedora 32, +the parent tag to choose would be `f32-build`. + +This will tell you the commands to + +. build a package in the specific side-tag and +. wait for the respective build root to be recreated, e.g.: + +.... +$ fedpkg request-side-tag --base-tag f32-build +Side tag 'f32-build-side-7863' (id 7863) created. +Use 'fedpkg build --target=f32-build-side-7863' to use it. +Use 'koji wait-repo f32-build-side-7863' to wait for the build repo to be generated. +.... + +The latter is important +if any builds depend on previous ones in the side-tag. +Use `koji wait-repo --build ` to ensure +that the respective build is available +in the build root +for subsequent builds. + +[[bodhi_update_for_builds_in_a_side_tag]] +==== Bodhi update for builds in a side-tag + +When you're done building all packages you want in a side-tag, +you have to submit them as an update to Bodhi +before they can be made available generally +to be installed and built upon. + +In the _Create New Update_ form in Bodhi, +choose the _Use Side-Tag_ drop-down +to create an update from the latest package builds in the respective tag: + +image:Bodhi-builds-from-side-tag.png[Bodhi-builds-from-side-tag.png,title="Bodhi-builds-from-side-tag.png"] + +As with single packages, tests will be run +whose result affects if the update can be moved to stable. +The difference is that tests have to succeed +(or be waived) +for all builds in the update. +If you have to update the list of builds, +e.g. to fix problems found during testing, +edit the update +and refresh the list of builds using the 🔃 (refresh) button: + +image:Bodhi-builds-refresh-from-side-tag.png[Bodhi-builds-refresh-from-side-tag.png,title="Bodhi-builds-refresh-from-side-tag.png"] + +The web interface only works if you are the creator of the side-tag. +If you are a proven packager submitting an update for a side-tag, +you currently need to use the bodhi cli: + +.... +$ bodhi updates new --from-tag --notes "whatever" --user +.... + +Once the update moves to stable, +the builds will be tagged to the main tag of the release, +i.e. are available for the general public. + +[adding_removing_builds_to_from_a_side_tag] +==== Adding/Removing builds to/from a side-tag +As a packager, +you can add or remove builds from your side-tag +using these commands: + +.... +$ koji tag +$ koji untag +.... + +This can be used to remove a build that made a test fail +or to add a build that was originally missed. +If you add or remove a build from a side-tag, +you will have to refresh the corresponding update in Bodhi. + +[[later_branched_and_stable_releases]] +== Later Branched and stable releases + +At the https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#updates-testing-activation[updates-testing activation] point, +the Bodhi update feedback system is enabled by https://docs.pagure.org/releng/[Release Engineering] +and builds submitted with `fedpkg build` +are no longer automatically sent to any official https://docs.fedoraproject.org/en-US/quick-docs/repositories/[repository]. +The update workflow for releases of this type is: + +. Build the package with `fedpkg build` + +. Submit an update for the package +with `fedpkg update`, +the https://bodhi.fedoraproject.org/[Bodhi web interface], +or the https://crates.io/crates/bodhi-cli[Bodhi CLI tool]. +This causes the package to be sent +to the https://docs.fedoraproject.org/en-US/quick-docs/repositories/#the-updates-testing-repository[updates-testing] repository. + +. Monitor the update's status +and the feedback you receive +via the web interface or email, +and modify it with updated or additional builds if necessary. + +. After the update meets the criteria in the https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/[Updates Policy] +and you are satisfied it should be released as a stable update, +submit the update to https://docs.fedoraproject.org/en-US/quick-docs/repositories/#stable-is-not-a-repository[stable] +with `bodhi updates request stable` +or the web interface. + +[[update_attributes]] +=== Update attributes + +At the time you submit the update, +you will be asked for several attributes. +The type of the update should be fairly self-explanatory: +Either it fixes bugs, +adds new features, +or is a new package. + +If you are asked whether you want to send the update +to _updates-testing_ or _stable_, +this is a no-op: +all updates now go through _updates-testing_. It does not matter what you choose. + +There are several schools of thought +on filling out the update description. +Some would suggest you consider the target audience: +for a stable release, in particular, many Fedora users will see this text, +and many of them may not be particularly familiar with your package. +Consider not simply describing literally the changes in the update, +but explaining as if to an outsider +why your are updating the package, +what benefits it will bring to them (if any), +and anything they may want to note +in order to have a smooth update experience. + +If you associate one or more bug reports with your update, +Bodhi will post comments into Bugzilla +to alert those following the bug reports +that an update is available. +If you mark your update as fixing the bug(s), +Bodhi will move the report(s) through +the `MODIFIED`, `ON_QA` and `CLOSED ERRATA` states +of the https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow[bug workflow] +as your update reaches various points in the process. +Using this mechanism can be very useful +both for you and for users of your package. + +You may set a _karma_ (feedback) level +at which the update will automatically be submitted to _stable_. +This is optional. +If you choose to use it, +please carefully consider an appropriate feedback level. +For a relatively obscure package which is quite stable, +1 or 2 may be an appropriate value. +For a popular, sensitive and complex package +such as `firefox` or `kernel`, +the default of 3 may be insufficient +and a choice of 5 +or even 10 +may be appropriate. + +[[who_will_receive_your_update_when]] +=== Who will receive your update, when? + +When a release is in Branched state, +the _updates-testing_ repository is enabled by default +so most users will see the package, +but only packages from the stable _fedora_ repository +are used in building milestone releases (Beta and Final) +and nightly images. + +Where a package goes when it is marked as _stable_ +differs between Branched and stable releases. +In Branched releases, +_stable_ packages are pushed to the base _fedora_ repository. +In stable releases, +_stable_ packages are pushed to the _updates_ repository. +However, from the point of view of the packager, +this is an insignificant implementation detail. +For more details, see https://docs.fedoraproject.org/en-US/quick-docs/repositories/[Repositories]. + +When a release is in stable state, +the _updates-testing_ repository is disabled by default, +but QA team members and others run with it enabled +in order to provide testing and Bodhi feedback. +The main user population will see your update only when it passes Bodhi, +is marked as _stable_ +and reaches the _updates_ repository. + +[[updating_inter_dependent_packages]] +=== Updating inter-dependent packages + +If an update you wish to submit would cause a dependency issue of any kind +(a strict package dependency error, +or simply another package failing to operate correctly) +if updated alone, +you must not submit the package as a single-package update. +You must always collect all inter-dependent or related packages together +into a single multi-package update, +such that no user will face problems +if they install all the packages in the update together. + +For example: +if you maintain a package `libfoo` +which the package `bar` depends on, +and you need to update `libfoo`, +you should check that `bar` continues to function correctly +with the updated version of `libfoo`. +If it does not, +you must ensure the appropriate changes are made to `bar`, +and include the updated `bar` in your update +along with the updated `libfoo`. + +The `fedpkg` tool does not handle multi-package updates. +You can add multiple packages to an update using the https://bodhi.fedoraproject.org/updates/new[Bodhi web application], +or the command line tool. +You can pass as many package names as you like to `bodhi updates new` command +to create a new multi-package update, +or use `bodhi updates edit` to edit an existing update. + +It is possible you will run into problems with permissions +when trying to add builds of packages +you do not have commit privileges for +to an update, +or trying to add a build +for a package you do have privileges for +to someone else's update. +If you encounter a situation like this, +you should contact the https://docs.pagure.org/releng/[release engineering] team +or a proven packager +for help. + +You may need a _buildroot override_ +to complete a multi-package update successfully. +For instance in the case described above, +you may need to rebuild `bar` against the new `libfoo` package +and submit both packages together +as a multi-package update. +However, in the normal course of events, +you would not be able to build another package against your new `libfoo` build +until it reached the stable state. +To resolve this dilemma, +you can request a buildroot override, +which causes the `libfoo` build +to be included in the buildroot for a short time +in order to get the `bar` package build done. + +You can request a buildroot override with bodhi: +This would submit a buildroot override +with a duration of two days. +Buildroot overrides are usually granted within 15-30 minutes of submission. +If you submit an override request with the bodhi tool, +it will suggest a command +that will let you monitor when the package appears in the buildroot, +so you can fire your dependent build at the appropriate time. + +You can also request buildroot overrides from the https://bodhi.fedoraproject.org/overrides/new[Bodhi web application]. + +The https://fedoraproject.org/wiki/Bodhi/BuildRootOverrides[buildroot override instructions] explain the buildroot override process in more detail. + +[[handling_feedback_from_automated_tests]] +=== Handling feedback from automated tests + +Fedora's automated testing system, OpenQA, +may run automated tests on your update. +The OpenQA tests are functional tests +of some critical Workstation and Server features. + +In the Bodhi web interface, updates have an _Automated Tests_ tab +which displays the results of all automated tests. +Tests shown with a red background failed. +The tests are not all 100% accurate, +but they are fairly often correct. +If you see a failure, it is a very good idea to click on the result +(which will take you to a detailed log) +and investigate the issue. +If you are unsure what the test indicates, +you can contact the QA team for help. + +[[waive_a_result]] +==== Waive a result + +At present, a failure of the _dist.rpmdeplint_, _dist.abicheck_, or _org.centos.prod.ci.pipeline.complete_ tests +will prevent your update from being released. +On the update's _Details_ page in the Bodhi web interface, +the *Test Gating Status* will be shown as +_N of N required tests failed_. +If you are sure such a failure is a false one, +you can 'waive' the result using the tool `waiverdb-cli`. + +You can submit a waiver for a failing result with `waiverdb-cli` +specifying the `subject` and the `testcase`: + +.... +waiverdb-cli -t YOUR_TESTCASE_HERE -s '{"item": "this-is-the-subject", "type": "also-this-is-part-of-the-subject"}' -p "fedora-26" -c "This is fine"` +.... + +Example: + +.... +waiverdb-cli -t dist.rpmdeplint -s '{"item": "python-requests-1.2.3-1.fc26", "type": "koji_build"}' -p "fedora-26" -c "This is fine"` +.... + +You can also waive a failing result by result's id, +which you can retrieve from resultsdb with curl. +To do that, you'll need the `testcase` name and the `nvr`. For example: + +.... +curl "https://taskotron.fedoraproject.org/resultsdb_api/api/v2.0/results?testcases=dist.python-versions&item=python-alembic-0.9.7-1.fc2" | jq ".data[0].id" +.... + +This should print out the of the failing result. +You can then submit a waiver for this failing result with + +.... +waiverdb-cli -p fedora-27 -r YOUR_ID_HERE -c "This is fine." +.... + +Also, if you enabled automatic stable push at a karma threshold, +this will be disabled if any automated test fails. +If you have examined the result +and you are sure it is a false one +and there is no problem with the package, +you may re-enable the automatic push mechanism +or submit the package to _stable_ manually +once it meets the other requirements of the https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/[Updates Policy]. + +[[waive_the_absence_of_a_result]] +==== Waive the absence of a result + +Submitting a waiver using subject/testcase +allows to waive the absence of a result +(eg. the test never ran for some reason, so there is no result item). + +If it is not clear which testcase you should specify, +the answer can be fetched with this Python script: + +[source,python] +---- +#!/usr/bin/env python +""" Ask a question of greenwave. """ +# Usage: either modify and set PRODUCT_VERSION and NVR_LIST and run, or pass version as first arg and then NVRs as further args +import pprint +import requests +import sys +PRODUCT_VERSION = 'fedora-27' if len(sys.argv) == 1 else sys.argv[1] +NVR_LIST = [] or sys.argv[2:] # Insert your NVRs here, or pass them via command line args +for nvr in NVR_LIST: + url = ( + 'https://greenwave-web-greenwave.app.os.fedoraproject.org/' + 'api/v1.0/decision') + payload = dict( + #verbose=True, + decision_context='bodhi_update_push_stable', + product_version=PRODUCT_VERSION, + subject=[{'item': nvr, 'type': 'koji_build'}], + ) + response = requests.post(url, json=payload) + print("-" * 40) + print(nvr, response, response.status_code) + data = response.json() + print(pprint.pformat(data)) +---- + +The output will show that +Greenwave is requiring a specific testcase to run, +but it cannot find a result for it +(neither pass nor failure). +So now it is possible to submit a waiver +with the specified testcase in the output +and the subject already known. + +==== Troubleshooting + +If you run the tool and it gives you the following error: + +.... +Error: The config option "resultsdb_api_url" is required +.... + +Edit `/etc/waiverdb/client.conf` and add the following line: + +.... +resultsdb_api_url=https://taskotron.fedoraproject.org/resultsdb_api/api/v2.0 +.... + +[[branched_milestone_freezes]] +=== Branched milestone freezes + +For a short period before each milestone release, +the stable https://docs.fedoraproject.org/en-US/quick-docs/repositories/#the-fedora-repository-in-branched-releases[fedora] repository is frozen. +These periods are shown as _Milestone freezes_ +(Post-branch Freeze, Beta Freeze, Final Freeze) +on schedules. +During these periods, builds will not be marked _stable_ +and pushed from _updates-testing_ to _fedora_ +even after being submitted manually or automatically. +In the normal course of events, +they will be pushed after the milestone release is approved +at a https://fedoraproject.org/wiki/Go_No_Go_Meeting[Go No Go Meeting]. +If you believe your update deserves to break a milestone freeze, +a _freeze exception_ may be granted +through the https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process[freeze exception process]. +Accepted release blocking bugs are granted the same status +through the https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process[blocker bug process]. + +For more on the Fedora development process, see https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle[Fedora Release Life Cycle]. + +[[security_updates]] +== Security updates + +For bugs identified as security issues, +there is an additional process +that layers over the regular update process. +If a bug is assigned to you +that blocks a https://fedoraproject.org/wiki/Security_Tracking_Bugs[Security Tracking Bug], +you must follow that process in addition to this one. + +[[new_package_submissions]] +== New package submissions + +If you want to build a new package, +but you aren't sure which releases to send it to: + +* New packages should always be built for Rawhide + +* New packages can be built for Branched and stable releases +if adding them would provide value to users of those releases +without significant risk of causing harm + +The submission process for new packages, +after they have passed the xref:Package_Review_Process.adoc[Package Review Process] +and been given an SCM repository, +is exactly the same as that for package updates. + +[[consider_creating_a_package_test_plan]] +== Consider creating a package test plan + +If you https://fedoraproject.org/wiki/QA:SOP_test_case_creation[create test cases] for your package, +and https://fedoraproject.org/wiki/QA:SOP_package_test_plan_creation[categorize them appropriately], +they will be automatically linked in Bodhi, +so that testers will have some guidance +for planned update testing. diff --git a/modules/ROOT/pages/Policy_for_Stalled_Package_Reviews.adoc b/modules/ROOT/pages/Policy_for_Stalled_Package_Reviews.adoc new file mode 100644 index 0000000..2b46ccd --- /dev/null +++ b/modules/ROOT/pages/Policy_for_Stalled_Package_Reviews.adoc @@ -0,0 +1,51 @@ += Policy for Stalled Package Reviews +:toc: + +Occasionally package reviews fail to make forward progress +due to lack of response from one of the parties involved in the review. +This policy addresses two classes of reviews: +Those stalled because the review submitter is not responding, +and those which have been assigned to a reviewer +but are stalled because that reviewer is not responding. +The idea is to move the ticket to a state +where other interested parties can submit the package +or take over the review. +Of course there is no intent to punish anyone, +and tickets can always be assigned back to the same reviewer +or reopened. + +[[reviewer_not_responding]] +== Reviewer not responding + +* When a review ticket is assigned to a reviewer +who does not respond to comments for one month, +a comment is added to the ticket indicating that the review is stalled +and that a response is needed soon. + +* If there is no response within one week, +the `fedora‑review` flag is set to the empty value. +The ticket is reassigned to `nobody@fedoraproject.org` +(use the _Reassign bug to owner and QA contact of selected component_ radio button for this) +with the intention to move the ticket back to a state +where another reviewer can work on it. + +[[submitter_not_responding]] +== Submitter not responding + +* When the submitter of a review ticket has not responded to comments for one month, +a comment is added to the ticket indicating that the review is stalled +and that a response is needed soon. + +* If there is no response within one week, +the ticket is closed with resolution `NOTABUG`, +and the `fedora-review` flag is set to the empty value. + +* The bug may be set as blocking https://bugzilla.redhat.com/show_bug.cgi?id=FE-DEADREVIEW[FE-DEADREVIEW]. +The intention is to close the bug +so that it can be submitted by someone else in a separate bug, +and also to make it easy to find bugs closed in this way. + +If the bug is resubmitted by someone else, +it is also reasonable to change the resolution on the closed bug to `DUPLICATE` +and mark it as a duplicate of the new bug +so that reviewers of the new ticket can easily find the work that was done on the old one. diff --git a/modules/ROOT/pages/Staying_Close_to_Upstream_Projects.adoc b/modules/ROOT/pages/Staying_Close_to_Upstream_Projects.adoc new file mode 100644 index 0000000..d7d7554 --- /dev/null +++ b/modules/ROOT/pages/Staying_Close_to_Upstream_Projects.adoc @@ -0,0 +1,302 @@ += Staying Close to Upstream Projects +:toc: + +The Fedora Project focuses, +as much as possible, +on not deviating from upstream in the software it includes in the repository. +The following guidelines are a general set of best practices, +and provide reasons why this is a good idea, +tips for sending your patches upstream, +and potential exceptions Fedora might make. +The primary goal is to share the benefits of a common codebase for end users and developers +while simultaneously reducing unnecessary maintenance efforts. + +upstream (noun):: +In free and open source projects, +the _upstream_ of a program or set of programs +is the project that develops those programs. +Fedora is _downstream_ of those projects. +This term comes from the idea that water and the goods it carries float downstream +and benefit those who are there to receive it. + +to upstream (verb):: +A short-hand way of saying "push changes to the upstream project". + +[[what_are_deviations_from_upstream]] +== What are deviations from upstream? + +* *Patches*: Patches are the most common and obvious type of change from upstream. +Patches might be written by the package maintainer, +cherry picked or backported from upstream +or picked from other distributions. + +* *Running sed or equivalent on a spec file*: +While this change is less obvious, +it should be considered functionally equivalent to a patch +for the purposes of this guide. +Also a patch is preferable +because running sed can sometimes change the software in unintended ways +especially when the package maintainer is pushing a new upstream release as an update +and such changes might not be obvious compared to a failed patch. + +* Desktop files, systemd unit files, etc. are sometimes added as *additional sources*: +If you do this as a package maintainer, +you need to notify upstream and ideally get them included as part of the upstream source. +Maintaining them separately often involves additional maintenance. + +* *Configuration options*: +For instance, if a particular upstream software allows both MySQL and Postgres as a database backend, +other distributions might have picked Postgres +and Fedora package might be configured to use the MySQL backend by default instead. +If upstream or other distributions are favoring one of the options over the others, +talk to them, +find out why +and rely on well tested and consistent options as much as possible. + +* *Underlying libraries and other software components*: +Even without intentional modifications, +software in Fedora can still be different from upstream or other distributions, +due to precise library versions or other software components your package depends on. +For instance, Firefox may expose a sqlite bug, +and Fedora might be the only distribution building that precise version of Firefox +against that specific version of sqlite. +You should talk to upstream and find out whether there are any such known issues, +and search through upstream bug trackers +or other popular distribution bug trackers +to figure out such problems. + +* *Miscellaneous*: +The above list is not comprehensive. +Even seemingly minor changes like the specific desktop theme or fonts +can exhibit bugs in other software, +or can expose a bug in the theme or font +but only with some specific software. +For instance, LibreOffice might have a problem displaying a list +when using the Adwaita theme and Dejavu font. +When analyzing issues, +make sure you consider the impact of every change +either in Fedora or by users themselves. + +[[why_push_changes_upstream]] +== Why push changes upstream? + +* *Common Benefit And Reduced Maintenance Burden*: +When Fedora carries patches that are specific to Fedora or deviations from upstream projects, +those patches are not shared by every distribution. +This puts the burden of maintaining those patches on Fedora, +which includes keeping those patches in a functional state +by rewriting or forward-porting them for every upstream release. +This effort can quickly add up to be overwhelming, +while not being in the spirit of sharing the benefits +(as well as the effort in maintaining) +free and open source software. + +* *Documentation*: +Upstream projects are documented formally +(in the form of man/info pages and longer guides) +and informally in many user forums or mailing lists as answers to user questions. +Deviations from upstream projects can thus confuse end users and upstream developers +when those patches cause changes in behavior that are Fedora specific +and not documented properly, +even where the formal documentation +(such as man pages) +are also patched to describe the changes. + +* *Translations*: +Maintaining translations upstream gains the advantage of established translation communities, +which are most likely more experienced with the project terms. +Downstream projects benefit when using those translations. +In addition, it lifts the burden of hosting, +and of the need to merge often from upstream to downstream and back again. +To make sure translation work continues upstream. +Any string changes that were introduced by patches should be maintained by the downstream community. + +* *Upstream Acceptance*: +Fedora is downstream of many thousands of software projects. +Much of this software is packaged by maintainers who are not programmers +or lack expertise in the language(s) the software is written in. +In some cases the software has a large and complex codebase +(such as the kernel or Libreoffice) +and the package maintainers might not have the same level of understanding in all areas +compared to subsystem maintainers or upstream developers. +For this and other reasons, +Fedora needs the acceptance of upstream software developers. +These developers may view any significant patches as a fork +or refuse to take bug reports from Fedora users +due to the differences in the codebase. +Fedora as a project strives to be welcoming and cooperative with upstream developers +as much as possible. +We must avoid Fedora specific patches +and any patches that are useful should be sent upstream to these developers +via mailing lists, bug trackers, or direct email. + +* *Quality Assurance*: Patches that are accepted upstream +are usually reviewed or tested by many people +including developers and testers. +This includes testing by other GNU/Linux distributions. +A deviation from the common codebase used by many +is a potential chance of introducing a regression that is specific to Fedora. + +* *Security*: +A special case of the "Quality Assurance" issue +is that changes that have surprising security implications +are more likely to be detected by upstream +(who often have deeper knowledge of the program). + +* *Fast incremental improvements*: +Staying close to upstream versions is helpful +when doing version bumps for updates that bring in new features. +This prevents tedious backporting of only security and bug fixes. +Deviations from upstream can significantly hamper the speed of delivering improvements +from new versions to end users. +However, regressions are to be avoided, +and potential improvements and new features must be carefully assessed +against the risk of harming the users experience. +Refer to https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/[Updates Policy] for more details. + +* *ABI or API Deviations*: +Patches that introduce a new application binary interface (ABI) +or application program interface (API) +must be especially avoided, +even if the ABI/API changes are planned to land upstream. +When these patches get upstream +(if ever), +upstream developers might introduce changes in the ABI/API +during the code review process before merging the code. +This could break other software in the repository +that makes use of the Fedora-patched ABI/API. + +* *Direct End User Feedback*: +When users run into problems with any software that is in Fedora, +they can report the problems directly upstream. +By not deviating from upstream, +it remains a central location for all bug reports on that software, +leaving Fedora package maintainers to concentrate on good packaging +instead of acting in between users and upstream issues. + +[[tips_on_upstreaming_patches]] +== Tips On Upstreaming Patches + +* Talk to upstream. +Maintaining a regular flow of communication with the upstream project +is helpful in understanding the upstream developers well, +and encourages them to be more responsive to your requests. +It also helps in understanding technical issues, +such as how they prefer patches to be submitted. + +* Make the patches generic enough to be maintained by upstream developers. +Explain the need for your patches, +that is, what bugs they fix or what features they add. +Any references to bugzilla reports or user requests +can be quite useful for the developers who receive your patches. + +* Do not consider any change to be too small to be sent upstream. +Even minor changes like fixing a permission problem in a file +or excluding an empty file +can and should be reported upstream +even if upstream does not necessarily act on all of them quickly. + +* Divide patches into small and independent chunks that remain functional, +so they can be understood, reviewed, and accepted or rejected individually. + +* If the patch introduces new strings or changes existing ones, +make the changes as generic as possible. + +* Fix your coding style to match the upstream project's guidelines. +This might seem trivial +but many upstream projects insist on following their guidelines +so that their codebase looks internally self consistent +and is more maintainable. + +* Where possible, encourage upstream point-releases that fix bugs and security issues only, +to avoid the possibility of regressions. + +* Test your changes as throughly as you can before you send them upstream. +Broken patches leave a long-lasting bad impression. + +* Be patient and cooperative. +If feedback is offered, +discuss changes, answer questions, and provide revisions that fix any problems. +Don't flame or argue unnecessarily with upstream developers. +The overall goal is persuade upstream developers to get your patches committed upstream +and not to demonstrate "who is better." +Don't forget the human element in these conversations. +If necessary, +we will have to carry some patches downstream to enforce our policies +even if upstream does not agree with us at that point. + +[[some_examples_of_exceptions]] +== Some Examples Of Exceptions + +* *Severe Security Issues Or Major Bug Fixes*: +For any major issues such as security holes or data loss problems, +waiting on a new release from upstream can be too much of a delay. +In these instances, it may be better to backport those fixes from upstream +or fix the issue by writing your own patch +and do an update in Fedora. +If you are writing a new patch, +send it upstream so that Fedora shares the benefits +and avoid deviations in new releases that follow. +Be careful when expeding the patching however. +A security patch that is not comprehensive +can leave unexpected security holes still open +or a patch to fix a major problem can worsen the problem. +Get your patches peer reviewed as much as possible. +Due to differences in release schedules between upstream projects and Fedora releases, +maintainers would have to keep in mind feature and development freezes in Fedora +and fix problems accordingly. + +* *Non-free or patent encumbered software*: +If upstream projects include software that is non-free or has known patent issues, +such software does not meet the https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/[Licensing Guidelines] +and Fedora will not include them. +In many instances, such code is optional in the form of plugins +that Fedora simply does not need to include +in its software repository. +In other cases, +it might be possible to work with upstream on making it optional +or patch specific portions. + +* *Unmaintained Or Unresponsive Upstream Projects*: +In cases where upstream projects are either unmaintained or unresponsive, +it might be acceptable to patch the software. +If upstream is unmaintained, +you might want to consider sharing patches with other distributions +or taking over maintenance +if you have the time, skills, and interest. +Be wary of maintaining software with no upstream +since all the burden of maintaining the codebase +as well as packaging issues are with you. +If upstream is unresponsive and many distributions are deviating significantly, +it might be a opportunity for a cross distribution fork +(Similar to XFree86 and Xorg). + +* *Patches Heading Upstream*: +Any patches that are known to be headed upstream +_might_ be patched temporarily in Fedora +if the patches provide important bug fixes +or in rare cases, features to users. +If this is done, +maintenance effort of the patches should be low impact +for the small amount of time until upstream merges the patches +and does a new release. + +* *Distribution Integration*: +There are features that are critical or very good to have for Fedora as a distribution +but not been significant enough +for various upstream projects to accept related enhancements just yet. +Use your discretion carefully when choosing to integrate any such patches +since there is a trade off +between upstream acceptance and Fedora integration +and associated costs/benefits. + +* *Bundling of Libraries*: +Refer to the https://docs.fedoraproject.org/en-US/packaging-guidelines/#bundling[Bundling and Duplication of system libraries] section of the Packaging Guidelines for details. +Fixes related to bundling should of course be sent upstream if possible. + +== References + +* http://fedoraproject.org/wiki/Objectives +* https://fedoraproject.org/wiki/Packaging/Guidelines#All_patches_should_have_an_upstream_bug_link_or_comment +* http://fedoraproject.org/wiki/PackageMaintainers/TrackingUpstream +* http://fedoraproject.org/wiki/PackageMaintainers/TrackingDownstream diff --git a/modules/ROOT/pages/Upstream_Release_Monitoring.adoc b/modules/ROOT/pages/Upstream_Release_Monitoring.adoc new file mode 100644 index 0000000..ed59624 --- /dev/null +++ b/modules/ROOT/pages/Upstream_Release_Monitoring.adoc @@ -0,0 +1,95 @@ += Upstream Release Monitoring +:toc: + +[[tldr_get_packages_monitored]] +== TLDR; Get Packages Monitored + +Get bug reports for a project's releases in Fedora's Bugzilla with three steps: + +. Add the project to https://release-monitoring.org[Anitya]. +. Map the project to a Fedora package in Anitya. +. Tweak the monitoring setting for your packages at https://src.fedoraproject.org/rpms/[Fedora Package Sources]. + +[[bugzilla_bugs_by_the_new_hotness]] +== Bugzilla bugs by the-new-hotness + +* https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=MODIFIED&bug_status=ON_DEV&bug_status=ON_QA&bug_status=VERIFIED&bug_status=RELEASE_PENDING&bug_status=POST&classification=Fedora&columnlist=product%2Ccomponent%2Cassigned_to%2Cbug_status%2Cresolution%2Cshort_desc%2Cchangeddate%2Copendate&email1=upstream-release-monitoring%40fedoraproject.org&emailreporter1=1&emailtype1=substring&list_id=1733771&order=changeddate%20DESC%2Cbug_id%20DESC&query_based_on=&query_format=advanced[OPEN bugs] + +* https://bugzilla.redhat.com/buglist.cgi?bug_status=CLOSED&classification=Fedora&email1=upstream-release-monitoring%40fedoraproject.org&emailreporter1=1&emailtype1=substring&order=changeddate%20DESC%2Cbug_id%20DESC&query_based_on=&query_format=advanced[CLOSED bugs] + +== Details + +One of the core foundation of Fedora is _First_ +which implies having the latest versions of software +(in rawhide and sometimes in released branches), +but as a package maintainer +it can be tedious to keep up with the releases from multiple projects. + +Fedora thus offers a service to help with this. +This service is divided into three components: + +* Anitya +* monitoring settings at Fedora Package Sources +* https://github.com/fedora-infra/the-new-hotness/[The-new-hotness] + +=== Anitya + +Available at https://release-monitoring.org[release-monitoring.org], +Anitya provides a web service where anyone can register a project. +Anitya will then broadcast a http://fedmsg.com[fedmsg] message +when it finds a new release. +Checks are run by cron twice a day. + +Anitya is not specific to Fedora +but we are using it as a way to learn about new releases. +Edit entries there to your heart's content. + +Bugs, features request and patches should go to https://github.com/fedora-infra/anitya/issues[anitya/issues]. + +[[monitoring_settings_at_src.fedoraproject.org]] +=== Monitoring settings at src.fedoraproject.org + +Fedora package maintainers can use the bottom left column +at the package's page at https://src.fedoraproject.org/[src.fedoraproject.org] +to have it monitored by the-new-hotness (see below). + +[[the_new_hotness]] +=== The-New-Hotness + +https://github.com/fedora-infra/the-new-hotness/[The-new-hotness] is an application that listens to the fedmsg bus +and acts upon receiving messages from https://release-monitoring.org[release-monitoring.org]. + +When it receives a message indicating that a project has a new release, +and that project is mapped to a Fedora package, +it will check in pkgdb2 if the Fedora package is marked to be monitored. + +If the package is marked to be monitored, +the-new-hotness will open a ticket on https://bugzilla.redhat.com[Bugzilla] +mentioning the availability of the new release. +It will then clone the git repository, +bump the version and reset the release, +download the new sources (if it can) +and attempt a scratch build in koji. + +The result of the scratch build is then added to the open bugzilla ticket. + +Subsequent successful koji builds are added to the ticket as well. + +NOTE: In some cases the scratch build will always fail +(for example if the `Source0` in the spec file cannot be adjusted automatically), +if you wish to avoid receiving the notification that the scratch-build failed, +you can set the monitoring flag in pkgdb2 to _nobuild_ (or _Bugs only_). +Then the bugzilla ticket will be created upon finding a new version, +but no scratch build will be made. + +[[related_projects]] +== Related Projects + +* http://github.com/tannewt/open-source-watershed[OSWatershed] - Monitors several distributions at once +* https://ppisar.fedorapeople.org/cpandistributionsinfedora.xhtml[Perl package monitoring] +* http://rpms.famillecollet.com/rpmphp/[Reports from Remi] PECL, pear and R extensions upstream comparison and stable repo with rawhide comparison for all packages +* http://distrowatch.com/table.php?distribution=fedora[DistroWatch.com: Fedora] +* http://youri.zarb.org/[Youri] http://check.mageia.org/[in action] http://svnweb.mageia.org/adm/puppet/modules/youri-check/[puppet modules] A generic framework +* https://github.com/jness/ossvt[ossvt] Developed for https://ius.io/[IUS] +* https://fedorapeople.org/cgit/till/public_git/cnucnu.git/[cnucnu] — the tool previously used to provide this service for Fedora +* http://repology.org/metapackages/outdated-in-repo/fedora_rawhide/[Repology] cross distro version comparision diff --git a/modules/ROOT/pages/Using_the_Koji_Build_System.adoc b/modules/ROOT/pages/Using_the_Koji_Build_System.adoc new file mode 100644 index 0000000..5f75523 --- /dev/null +++ b/modules/ROOT/pages/Using_the_Koji_Build_System.adoc @@ -0,0 +1,411 @@ += Using the Koji build system +:toc: + +[[using_koji_in_fedora]] +== Using Koji in Fedora + +The https://fedoraproject.org/wiki/Koji[Koji Build System] is Fedora's RPM buildsystem. +Packagers use the `koji` client to request package builds +and get information about the buildsystem. +Koji runs on top of Mock to build RPM packages for specific architectures +and ensure that they build correctly. + +There is also a https://fedoraproject.org/wiki/Zh/%E4%BD%BF%E7%94%A8Koji%E7%BC%96%E8%AF%91%E6%89%93%E5%8C%85%E7%B3%BB%E7%BB%9F[simplified Chinese edition]. + +[[installing_koji]] +=== Installing Koji + +[[koji_setup]] +==== Koji Setup + +Before using Koji to build packages, +you must have the `fedora-packager` package installed: + +.... +dnf install fedora-packager +.... + +You must also have a valid kerberos ticket: + +.... +KRB5_TRACE=/dev/stdout kinit your_fas_username@FEDORAPROJECT.ORG +.... + +Here, `FEDORAPROJECT.ORG` must be in capital case. + +Store your FAS username (all lower case) in `~/.fedora.upn`. +This is not actually needed for Kerberos +but for other tools that use the Fedora client certificate +to determine the FAS username. + +For more information, see https://fedoraproject.org/wiki/Infrastructure/Kerberos[Kerberos setup]. + +[[koji_config]] +==== Koji Config + +The global-local client configuration file for koji is `/etc/koji.conf`. +You should not need to change this from the defaults +for building Fedora packages. +These allow you to use the primary build system +as well as secondary arch build systems. + +You can use the `koji` command directly, +or use `fedpkg`, a script that interacts with the RPM Packaging system and other subsystems, +like git and koji itself. + +[[building_with_fedpkg_targets]] +=== Building with fedpkg targets + +When building with `fedpkg` within a git repository, +every push is automatically tagged via git. +All you have to do to build the package is to run `fedpkg build`. +This triggers a build request for the branch. +Easy! + +It is also possible to target a specific koji tag: + +.... +fedpkg build --target TARGET +.... + +For example, +if building on rawhide +against a side-tag for updating API for many packages, +such as `dist-f14-python`, +use the following: + +.... +fedpkg build --target 'dist-f14-python' +.... + +[[chained_builds]] +==== Chained builds +WARNING: chain-builds only work when building on rawhide. +To chain-build packages to update a released OS version, +https://fedoraproject.org/wiki/Bodhi/BuildRootOverrides[set up an override using bodhi] +requesting packages to be included in the proper buildroot. + +Sometimes you want to make sure +that one build has succeeded before launching the next one, +for example when you want to rebuild a package +against a dependency that has just been rebuilt. +In that case, use a chain build with: + +.... +fedpkg chain-build libwidget libgizmo +.... + +The current package is added to the end of the CHAIN list. +Colons (`:`) can be used in the CHAIN parameter to define groups of packages. +Packages in any single group will be built in parallel +and all packages in a group must build successfully +and populate the repository +before the next group will begin building. +For example: + +.... +fedpkg chain-build libwidget libaselib : libgizmo : +.... + +causes `libwidget` and `libaselib` to be built in parallel, +followed by `libgizmo`, +and then the package in your current directory. +If no groups are defined, +packages will be built sequentially. + +If a build fails, +following builds are canceled, +but the builds that already succeeded are pushed to the repository. + +[[scratch_builds]] +=== Scratch Builds + +Sometimes it is useful to be able to build a package against the buildroot +without actually including it in the release. +This is called a scratch build. + +The following section covers using koji directly, +as well as the fedpkg tool, +to do scratch builds. + +To create a scratch build from changes you haven't committed, do the following: + +.... +rpmbuild -bs foo.spec +koji build --scratch rawhide foo.srpm +.... + +From the latest git commit: + +.... +koji build --scratch rawhide 'git url' +.... + +If you have committed the changes to git +and you are in the current branch, +you can do a scratch build with `fedpkg`, +which wraps the koji command line tool with the appropriate options: + +.... +fedpkg scratch-build +.... + +To run a scratch build for a specific architecture: + +.... +fedpkg scratch-build --arches +.... + +``can be a comma separated list of several architectures. + +Finally, it is possible to combine the scratch-build command +with a specific koji tag in the form: + +.... +fedpkg scratch-build --target TARGET +.... + +Run `fedpkg scratch-build --help` or `koji build --help` for more information. + +[[build_failures]] +=== Build Failures + +If your package fails to build, you get an error, for example: + +.... +420066 buildArch kernel-2.6.18-1.2739.10.9.el5.jjf.215394.2.src.rpm, +ia64): open (build-1.example.com) -> FAILED: BuildrootError: +error building package (arch ia64), mock exited with status 10 +.... + +Investigate why the build failed by looking at the log files. +If there is a `build.log`, start there. +Otherwise, look at `init.log`. + +Each job you successfully start gets a unique task ID, +which is listed in its output. + +Logs can be found in the web interface, +in the _Task_ pages for the failed task. +Alternatively, use `koji watch-log`, along with the task ID, +to view the logs. +See the help output for more details. + +[[advanced_use_of_koji]] +=== Advanced use of Koji + +We've tried to make Koji self-documenting wherever possible. +The command line tool prints a list of valid commands, +and each command supports `--help`. For example: + +.... +$ koji help + +Koji commands are: +build Build a package from source +cancel-task Cancel a task +help List available commands +latest-build Print the latest rpms for a tag +latest-pkg Print the latest builds for a tag +[...] +.... + +.... +$ koji build --help + +usage: koji build [options] tag URL +(Specify the --help global option for a list of other help options) + +options: +-h, --help show this help message and exit +--skip-tag Do not attempt to tag package +--scratch Perform a scratch build +--nowait Don't wait on the build +[...] +.... + +[[using_koji_to_generate_a_mock_config_to_replicate_a_buildroot]] +==== Using koji to generate a mock config to replicate a buildroot + +koji can be used to replicate a build root for local debugging. + +.... +koji mock-config --help +Usage: koji mock-config [options] name +(Specify the --help global option for a list of other help options) + +Options: + -h, --help show this help message and exit + --arch=ARCH Specify the arch + --tag=TAG Create a mock config for a tag + --task=TASK Duplicate the mock config of a previous task + --buildroot=BUILDROOT + Duplicate the mock config for the specified buildroot + id + --mockdir=DIR Specify mockdir + --topdir=DIR Specify topdir + --topurl=URL url under which Koji files are accessible + --distribution=DISTRIBUTION + Change the distribution macro + -o FILE Output to a file +.... + +For example to get the latest buildroot for `dist-f12-build` run: + +.... +koji mock-config --tag dist-f12-build --arch=x86_64 --topurl=http://kojipkgs.fedoraproject.org/ dist-f12 +.... + +You must pass `--topurl=http://kojipkgs.fedoraproject.org/` to any mock-config command +to get a working mock-config from Fedora's koji. + +[[using_koji_to_control_tasks]] +==== Using Koji to control tasks + +List tasks: + +.... +koji list-tasks +.... + +List only tasks requested by you: + +.... +koji list-tasks --mine +.... + +requeue an already-processed task (general syntax is: `koji resubmit [options] taskID`): + +.... +koji resubmit 3 +.... + +[[building_a_package_with_the_command_line_tool]] +==== Building a Package with the command-line tool + +Instead of using the `fedpkg` target, +you can also directly use the command line tool, `koji`. + +To build a package, the syntax is: + +.... +koji build +.... + +For example: + +.... +koji build dist-f14 'git url' +.... + +The koji build command creates a build task in Koji. +By default, the tool will wait and print status updates until the build completes. +You can override this with the `--nowait` option. + +NOTE: For fedora koji, +the git url MUST be based on pkgs.fedoraproject.org. +Other arbitrary git repos cannot be used for builds. + +[[koji_tags_and_packages_organization]] +=== Koji tags and packages organization + +==== Terminology + +In Koji, it is sometimes necessary to distinguish +between a package in general, +a specific build of a package, +and the various rpm files created by a build. +When precision is needed, these terms should be interpreted as follows: + +* *Package*: The name of a source rpm. +This refers to the package in general +and not any particular build or subpackage. +For example: kernel, glibc, etc. + +* Build: A particular build of a package. +This refers to the entire build: +all arches and subpackages. +For example: kernel-2.6.9-34.EL, glibc-2.3.4-2.19. + +* RPM: A particular rpm. +A specific arch and subpackage of a build. +For example: kernel-2.6.9-34.EL.x86_64, kernel-devel-2.6.9-34.EL.s390, glibc-2.3.4-2.19.i686, glibc-common-2.3.4-2.19.ia64 + +[[tags_and_targets]] +==== Tags and targets + +Koji organizes packages using tags. +In Koji a tag is roughly a collection of packages: + +* Tags support inheritance +* Each tag has its own list of valid packages (inheritable) +* Package ownership can be set per-tag (inheritable) +* When you build you specify a target rather than a tag + +A build target specifies where a package should be built +and how it should be tagged afterward. +This allows target names to remain fixed +as tags change through releases. + +[[koji_commands_for_tags]] +==== Koji commands for tags + +===== Targets + +You can get a full list of build targets with the following command: + +.... +$ koji list-targets +.... + +You can see just a single target with the `--name` option: + +.... +$ koji list-targets --name f30 +Name Buildroot Destination +--------------------------------------------------------------------------------------------- +f30 f30-build f30-pending +.... + +This tells you a build for target `f30` +will use a buildroot with packages from the `f30-build` tag +and tag the resulting packages as f30-pending. + +You probably do not want to build against rawhide. +If Fedora N is the latest one out, +to build to the next one, choose `f\{N+1}`. + +===== Tags + +You can get a list of tags with the following command: + +.... +$ koji list-tags +.... + +===== Packages + +As mentioned above, +each tag has its own list of packages that may be placed in the tag. +To see that list for a tag, use the `list-pkgs` command: + +.... +$ koji list-pkgs --tag dist-f14 +.... + +The first column is the name of the package, +the second tells you which tag the package entry has been inherited from, +and the third tells you the owner of the package. + +[[latest_builds]] +===== Latest Builds + +To see the latest builds for a tag, use the `latest-pkg` command: + +.... +$ koji latest-pkg --all dist-f14 +.... + +The output gives you not only the latest builds, +but which tag they have been inherited from +and who built them. diff --git a/modules/ROOT/pages/index.adoc b/modules/ROOT/pages/index.adoc new file mode 100644 index 0000000..b890d2a --- /dev/null +++ b/modules/ROOT/pages/index.adoc @@ -0,0 +1,9 @@ += The Pizza Project +John Doe; Jane Doe +:page-authors: {author}, {author_2} + +The Pizza Project is a useful project with a very bad name — it helps you with writing some new documentation for Fedora. + +In fact, this is just a source template for a new piece of the Fedora Docs. + +image::pizza.png[Pizza] diff --git a/modules/ROOT/pages/wiki/How_to_Get_Sponsored_into_the_Packager_Group.wiki b/modules/ROOT/pages/wiki/How_to_Get_Sponsored_into_the_Packager_Group.wiki new file mode 100644 index 0000000..5d40c80 --- /dev/null +++ b/modules/ROOT/pages/wiki/How_to_Get_Sponsored_into_the_Packager_Group.wiki @@ -0,0 +1,57 @@ +{{autolang|base=yes}} + +{{admon/note|Get a Fedora Account|You should already have a Fedora Account or you did not follow the [[Join_the_package_collection_maintainers|Join the Fedora Package Collection Maintainers Guide]]. Please read the guide first and come back here later. If you do not want to become a package maintainer in the Fedora Project, you do not need to be sponsored.}} + +== Sponsorship model == +Getting sponsored allows anyone interested to become a Fedora maintainer and get direct commit and upload access to their proposed software packages. We require people to get sponsored into the packager group before getting this access to Fedora to ensure that they have someone that they can go to with questions. Sponsorship is '''not''' automatic and requires that you find a willing sponsor. Depending on the sponsor and how much time they have to spend with you, they may require that you demonstrate that you have the knowledge to maintain Fedora packages properly (including an understanding of the Fedora packaging guidelines) or they may be willing to take you on if you just show that you are eager and willing to learn those things from them. A sponsor will assist you with some aspects of packaging and the submission process but will expect you to read about the process and [https://docs.fedoraproject.org/en-US/packaging-guidelines/ guidelines for packages] for a large amount of your understanding of how things work. + +== Convincing someone to sponsor you == + +There are several ways to get sponsored into the packager group depending on your interest. In many cases doing a mixture of different things will increase your chances of being sponsored. + +=== Submitting quality new packages === + +Until you are sponsored into the packager group you are not able to own packages or to check in changes to packages which you own. However, you can still create an initial package and submit it for review as talked about on the [[Join_the_package_collection_maintainers#Adding_a_new_package| joining the package collection maintainers page]]. When you open your review request in bugzilla, you should block the [https://bugzilla.redhat.com/show_bug.cgi?id=FE-NEEDSPONSOR FE-NEEDSPONSOR] tracking bug, that way all of the sponsors will be able to see your sponsorship request. Although FE-NEEDSPONSOR is set on the package's review request, it is the person that needs to be sponsored into the packager group, not the package. The package undergoes a [[Package_Review_Process | review and approval]] that is separate from someone sponsoring you. Note that it is possible to have accepted packages which you cannot import because you have not been sponsored. See below. + +When submitting a new package, usually a sponsor finds you, but you can take a look at the [https://accounts.fedoraproject.org/group/packager/ list of packager sponsors] (only accessible with a [[Account System|Fedora Account]]) for someone you know. Sending bulk requests to the list is discouraged. If you can't find anyone that you have a connection with, you may want to try hanging out in the [[How_to_communicate_using_IRC|#fedora-devel IRC channel]] to get to know some people. Also you might find a sponsor in a [[Category:Packaging_SIGs|Packaging Special Interest Group]] that fits to your submitted package. + +Sponsors who work with people submitting new packages are looking to see how well you are going to be able to maintain this package which is primarily about whether you can package according to Fedora's [https://docs.fedoraproject.org/en-US/packaging-guidelines/ Packaging Guidelines] but they'll also take into account how you'll be able to respond to bugs against the code itself. If you like, you can include other information about your involvement with the Fedora and upstream communities that you think might help the sponsors in their decision. If you are an upstream author of the package you are submitting or if you are active in the community that surrounds it, please say so. If you can line up one or more existing Fedora contributors who are willing to maintain the package along with you, even if they are not sponsors, please indicate that as well. + +The sponsors that look at new package submissions often ask new packagers to do some package reviews in order to further show that they know what they're doing. If you do some reviews ahead of time, you can show the sponsors that you've both read these pages and understand the guidelines. Go ahead and link to other package review requests where you've left comments and reviews (More on reviews [[#Show Your Expertise by Commenting on other Review Requests| below]]). + +Basically, the more information that you make available, the quicker you will find a sponsor. + +If you have accepted packages and still have not managed to find a sponsor, feel free to file a ticket in the [https://pagure.io/packager-sponsors/ sponsors ticketing system]. + +=== Show Your Expertise by Commenting on other Review Requests === + +To show you familiarity with Fedora's guidelines perform unofficial (also called preliminary) reviews in other maintainers' package review request. Please clearly state when doing these reviews, that there are yet unofficial, and do not change the review requests status except for adding you to the CC list. To let sponsors know of your preliminary reviews. link to them in your review request. The quality of your reviews help convincing a sponsor of your knowledge. They will also help out the other reviewers, which will be much appreciated. After you got sponsored, you can finish your unofficial reviews. + +Reviews follow the [https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/ review guidelines]. Note that it's not strictly necessary for you to work through the entire checklist, but please do as much as you can; the more you indicate that you understand, the better your chances of being sponsored. + +You can search in the [https://fedoraproject.org/PackageReviewStatus/in_progress.html list of reviews in progress] for review requests to comment on. If you want to work on review requests that nobody else officially reviews, see the [http://fedoraproject.org/PackageReviewStatus/reviewable.html list of unassigned review requests]. + +=== Show Your Expertise by Opening Pull Requests === + +The [https://pagure.io Pagure] based [https://src.fedoraproject.org src.fedoraproject.org] system allows you to Fork, modify, and open Pull Requests for packages even if you are not yet part of the package maintainer's group. This is an excellent way to help other package maintainers, and demonstrate your expertise. When requesting sponsorship, you should list these PRs. In many cases, maintainers will also be happy to co-maintain the package with you, and get you sponsored. More on that in the next section. + +=== Become a co-maintainer === + +Another way to enter the packager group is by co-maintaining a package that is already in Fedora. To get sponsored this way you need to convince the current owner of that package to let you co-maintain the package and they will act as your mentor -- teaching you how to package properly in Fedora and how to use the tools available for building and distributing packages. To get an owner to agree to this you may need to demonstrate that you have some understanding of packaging already or at least, that you are eager to learn. Submitting patches on bug reports, preparing updated packages if the maintainer is behind on creating an update, or otherwise communicating with the maintainer that you are willing to help are ways to show that you are worth the package owner's investment to train you. + +In some cases the package owner is a sponsor in the packager group and can sponsor you themselves. If they are not a sponsor, they can get another existing sponsor to do so, either by contacting a sponsor personally and asking them to proxy the sponsorship or by opening a ticket in the [https://pagure.io/packager-sponsors/ packager sponsors pagure instance] stating that they are a package owner who would like you to co-maintain their package. They agree to be responsible for mentoring you in how to follow the [https://docs.fedoraproject.org/en-US/packaging-guidelines/ Fedora Packaging Guidelines] and how to use the tools Fedora provides for building and pushing packages but need someone to sponsor you since they are not sponsors themselves. A sponsor will add you to the packager group once that agreement for mentorship exists. + +=== Other paths === + +Sponsors can decide to sponsor you for any other reason as well. For example, you may be upstream for a package and want to maintain just that package in Fedora, or a sponsor may know your work and packaging history and deem you worthy of sponsorship with no further information. The sponsorship decision is left up to the sponsor. + +== Provenpackagers == + +[https://docs.fedoraproject.org/en-US/fesco/Provenpackager_policy/ Provenpackagers] are members of the '''provenpackager''' group. In addition to the rights granted to members of '''packager''', provenpackagers are able to commit changes to packages they do not own or maintain. + +== How to sponsor == + +If you are looking for information on sponsoring someone, take a look at [[how to sponsor a new contributor]] . + +[[Category:Package Maintainers]] +[[Category:Policy]] diff --git a/modules/ROOT/pages/wiki/How_to_Remove_a_Package_at_the_End_of_Life.wiki b/modules/ROOT/pages/wiki/How_to_Remove_a_Package_at_the_End_of_Life.wiki new file mode 100644 index 0000000..3e0b91f --- /dev/null +++ b/modules/ROOT/pages/wiki/How_to_Remove_a_Package_at_the_End_of_Life.wiki @@ -0,0 +1,73 @@ + +When a package reaches the end of its useful life, the following procedure will let other people -- and automated processes! -- know both not to expect any more releases, and why it was removed. The process is called retirement. + +== Procedure == +{{admon/warning|Retire only in development/EPEL branches!|Do not retire packages in other branches than Branched (until the [[Schedule|Final Freeze]]), Rawhide (master) and EPEL branches (epel7, epel8). +When you need to add package from EPEL to any RHEL release, only retire EPEL branch when package is released in that RHEL release.}} +Please execute the following steps in the order indicated. + +=== RPM === +If the package is being replaced by some other package, ensure that the Obsoletes/Provides tags are properly set by the new package, see [https://docs.fedoraproject.org/en-US/packaging-guidelines/#renaming-or-replacing-existing-packages Renaming/Replacing Guidelines]. + +=== GIT === +Run fedpkg retire DESCRIPTION in all non-stable Fedora branches and EPEL +branches, if applicable. The retiring needs to start with the oldest branch +(e.g. retire on f31 before you retire on rawhide) + + +==== Remarks ==== +* The DESCRIPTION parameter should explain why the package was retired, good messages are: +** Obsoleted by bar +** Renamed to bar +* The command will remove all files from the branch, add a file name dead.package containing the description and push the changes. +* git rm all files in the other branches '''only if''' there are special factors at work, like licensing issues, or package being removed completely from Fedora. +* If you retired master before other older branches you want to retire, just continue with the older branches. It will still work, but will block the package in more Koji tags, because tag inheritance will not be used automatically then. + +=== Comps === +Remove the package from [[How_to_use_and_edit_comps.xml_for_package_groups| comps]] if it is listed. + +=== Spins === +Remove the package from any [https://pagure.io/fedora-kickstarts spin kickstart file] +fork fedora-kickstarts and check out your clone. commit any fixes and send in a Pull Request + git clone ssh://git@pagure.io/path/to/fork/fedora-kickstarts.git + +=== Upstream Release Monitoring === +Remove the package from [[Upstream_release_monitoring]] if it is listed. + +{{admon/note|Use the Flag button|Currently, regular users can't delete a project from [[Upstream_release_monitoring]]. To delete a project, one must click on the Flag button and use the flagging form to request that the project be deleted.}} + + +=== Koji === +To keep retired packages from being pushed to the mirrors, they need to be blocked in koji. This will happen during the next compose (for rawhide, the branched release and for EPEL). If the package was not blocked automatically after two days, please file a +[https://pagure.io/releng/new_issue ticket] for release engineering and mention the package name and the branch the package needs to be blocked. + +==== Remarks ==== +* Please wait two days before opening a ticket to allow for a compose to happen and then the mirrors to be updated. +* Use one ticket for all packages you retired at once, do not open one ticket for each package if you retired several packages. +* You check whether a package is blocked in koji, e.g. for the package curry there should the a entry with [BLOCKED] for each branch the package was retired in. It is enough for a package to be retired in an older tag to be also blocked in a newer tag due to inheritance: + +
+$ koji list-pkgs  --show-blocked --tag f21 --package curry                               
+Package                 Tag                     Extra Arches     Owner          
+----------------------- ----------------------- ---------------- ---------------
+curry                   f20                                      gemi            [BLOCKED]
+
+ +== EPEL == +Note that you can use this process for EPEL as well with one difference: + +* You can remove the package from any EPEL branch whether or not it has been released. + +For example, if your package has been added to base RHEL in RHEL-6.4 then perform the steps above but use the el6 branch instead of master. + +== Unretire a Package == +See [[Orphaned_package_that_need_new_maintainers]] + +== Obsoleting Packages == +While not strictly part of the process, please consider what will happen to systems which have the now-retired packages installed. Generally, such packages will simply remain on the system as it is updated, becoming increasingly outdated. + +Please consider adding your package to [https://src.fedoraproject.org/rpms/fedora-obsolete-packages/ fedora-obsolete-packages]. + +Please follow relevant [https://docs.fedoraproject.org/en-US/packaging-guidelines/#renaming-or-replacing-existing-packages packaging guidelines] if another package will be providing similar or identical functionality to the retired package, or if it is necessary that the package be removed from end-user systems on system updates. + +[[Category:Package Maintainers]] diff --git a/modules/ROOT/pages/wiki/How_to_Sponsor_a_New_Contributor.wiki b/modules/ROOT/pages/wiki/How_to_Sponsor_a_New_Contributor.wiki new file mode 100644 index 0000000..62794e5 --- /dev/null +++ b/modules/ROOT/pages/wiki/How_to_Sponsor_a_New_Contributor.wiki @@ -0,0 +1,43 @@ +== How To Get Sponsored == + +If you are looking for more information on getting sponsored yourself, take a look at the [[How to get sponsored into the packager group]] wiki page. + +== Becoming a Fedora Package Collection Sponsor == + +The Fedora Package Collection has been setup so to encourage "learning by doing" and the development of cooperative relationships between Fedora packagers. Once packagers have acquired sufficient packaging knowledge to help others through the process, they may apply for sponsor status. As "sufficient knowledge" is unworkably vague, the following guidelines have been established. Prospective sponsors should: + +* Maintain at least three packages. +* Have done five high quality, nontrivial package reviews. +* Have been members of the packager group for at least one release cycle (generally six months) so that they have seen the process of branching for a new release. + +These are still somewhat vague to allow for flexibility but should provide a reasonable idea of how much experience is required. + +If you're a packager and feel that you are ready and would like to move up to sponsor status, simply file a ticket in the [https://fedorahosted.org/packager-sponsors packager sponsors ticket system]. These tickets are automatically sent to the sponsors list. A report will be added containing information on your reviewed and owned/comaintained packages, but feel free to provide additional information that can't easily be found such as informal reviews done or prospective packagers you would like to sponsor. + +Votes will be collected in the ticket for a week. At the end of that time, if the differential between positive and negative votes stands at +3 or greater, your request will be approved and you'll be promoted to sponsor status immediately, If not, your request will be closed. You may reapply anytime you feel you have more support. After waiting an hour or so for the new permissions to propagate through the system, you will be able to sponsor new packagers. + +== Sponsoring Someone for Fedora Package Collection == + +Sponsoring someone for access to Fedora Package Collection is relatively simple. If you are looking for someone to sponsor, take a look at the [https://admin.fedoraproject.org/accounts/home Fedora Account system] for contributors who are currently searching for a sponsor. Note that they should also have submitted a package review request for a package which they are proposing to add to Fedora on [https://bugzilla.redhat.com Red Hat Bugzilla]. In this request they should write that they need a sponsor. + +Bugzilla will send a notification mail for the new review request to the fedora-package-review mailing list. Take a look at their package and review it. If it looks reasonable and it seems that the comply with the [[Packaging:Guidelines| Packaging Guidelines]] , then they are probably a good candidate to be sponsored. + +Add any comment for changes to the review request on Bugzilla which look as though they'd be needed for compliance as well as the fact that you're volunteering to sponsor them. Once they've made those changes, you can approve the package and sponsor the user in the fedora account system. Before you approve the user, please make sure that his/her email in [https://admin.fedoraproject.org/accounts/home Fedora Account system] is the same as in [https://bugzilla.redhat.com Red Hat Bugzilla]. After that, go to https://accounts.fedoraproject.org/group/packager/, log in, then add the username in the 'add user' field located to the right of the top of the "Members" section, then press enter. + +A new packager cannot, at this time, make changes to packages he does not own or comaintain until he applies to become a [[Provenpackager_policy|provenpackager]] but you should still keep an eye on them. Generally the easiest way to do this is for them to become comaintainers of at least the initial package they review. You should be sure to review their commits to the Git repository for how they look, and consider watching their Bugzilla activity at least for a while (Preferences→Email Preferences→[https://bugzilla.redhat.com/userprefs.cgi?tab=email User Watching]). Respond with any comments that you might have and guide them, providing assistance as they need it for any tasks. A provenpackager can step in if necessary. + +So what's the downside to sponsoring someone? Your sponsoree will likely have questions about processes; one of your responsibilities as a sponsor is to help them with the answers. A sponsor isn't expected to be omniscient, though, so you can feel free to ask for others' advice and opinions if you get a really hard question. [[Package_sponsor_responsibilities|Sponsor responsibilities are detailed here]]. + +== Sponsoring Someone for provenpackagers == + +[[Provenpackager_policy|Provenpackagers]] have access to most packages. [[FESCo]] members should forward requests for provenpackagers to the sponsors mailing list where sponsors can give their advice on the provenpackager request. Provenpackagers may nominate themselves, but having a sponsor endorse the nomination or proposing the packager to become a provenpackager (the packager should agree) is certainly a good thing. + +By granting membership into the provenpackager group for a maintainer you are confirming that (at least in your mind) they meet the criteria for that group, and that you would trust them fully with any of the packages you either maintain or even just use. + +Provenpackagers are approved on at least 3 positive votes with no negative votes. In the event of negative votes, the decision will be made by FESCo at their next meeting. See the [[Provenpackager_policy|provenpackager description]] for more information. + +== Welcome Note == + +Once you have sponsored someone, we request that you send a note to fedora devel mailing list welcoming the new contributor and cc the person you have sponsored. Public recognition of any contributor would help them feel appreciated and motivate them to contribute more. It would also help establish Fedora as a community of people and friends rather than merely a technical body of work. + +[[Category:Package Maintainers]] diff --git a/modules/ROOT/pages/wiki/Join_the_Package_Collection_Maintainers.wiki b/modules/ROOT/pages/wiki/Join_the_Package_Collection_Maintainers.wiki new file mode 100644 index 0000000..b28a0c5 --- /dev/null +++ b/modules/ROOT/pages/wiki/Join_the_Package_Collection_Maintainers.wiki @@ -0,0 +1,303 @@ +{{autolang|base=yes}} + += Contributing roles = +{{admon/tip|Contributing roles|These are only suggestions for contributing roles. Only your imagination sets the limits. }} + +{|class="nobordersplz" +|- +| +[[Image:Join_OSDeveloper.png]]
+[[Join#OS_Developer|OS Developer]] +|} + += How to join the Fedora Package Collection Maintainers? = + +So, you have decided to become a package maintainer in the Fedora Project? This guide will lead you through your first package submission. It can be a completely new package, or update to an existing package. + +[[Image:fedora-submit-package.png]] + +== Preparation == + +=== Read the Guidelines === + +If you don't know how to create an RPM package, refer to the tutorial at [[How to create a GNU Hello RPM package]] or the more advanced and much more detailed [https://docs.fedoraproject.org/en-US/quick-docs/creating-rpm-packages/index.html Creating RPM packages]. + +Read the [https://docs.fedoraproject.org/en-US/packaging-guidelines/ Packaging Guidelines] and [https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/ Package Naming Guidelines]. + +You need to be thoroughly familiar with these. They govern all package submissions. If you have questions, ask on the Fedora {{fplist|packaging}} List. + +=== Create a Bugzilla Account === + +Make sure you have an account in [https://bugzilla.redhat.com/ Red Hat Bugzilla] . + +The email address that you use for your Bugzilla account should be the same email address as you use in the [[#Get_a_Fedora_Account| Fedora Account System]] for all things related to Fedora Packaging. + +{{admon/important|Do not use your @fedoraproject.org address if you already have one.|You should not use your @fedoraproject.org email address in Bugzilla, because you will not get your Bugzilla privileges once you are sponsored. If you want to use your @fedoraproject.org address, you might try to request at the [https://pagure.io/fedora-infrastructure/issues Fedora Infrastructure Ticket System] for an administrator to manually override the Bugzilla address connected with your Fedora Account.}} + +{{Anchor|GetAFedoraAccount}} + +=== Create a Fedora Account === + +Create an account in the [[Infrastructure/AccountSystem |Fedora Account System]] (this is ''not'' the same as the Bugzilla account) + +# Visit the account system home: https://accounts.fedoraproject.org/ +# Click on 'New account' and fill in the blanks. Note that the email you give should be the same as the one you gave Bugzilla. This allows the system to link privileges between the two accounts. +# After you create your account, please be sure to sign the CLA (if you click on the "My Account" link in the top right, you should see CLA: CLA Done). +# You will also need to upload a public RSA SSH key. You need to use the matching private key to access Fedora machines via SSH. You can read more about this [[Cryptography | here]]. + +=== Join the important Mailing Lists === + +You should join the fedora {{fplist|devel-announce}} mailing list. It is a low traffic announcements only list, where important development information is posted. + +You should join the fedora {{fplist|devel}} mailing list, where discussions about the development of Fedora are held. This is a high traffic mailing list. + +You should also consider joining the {{fplist|package-announce}} mailing list -- The commits mailing list gets notifications on all commits in any package in the Fedora repository. This is a very high traffic mailing list. The Fedora package database sends commit mails for packages you (co-)maintain. + +Another mailing list you might consider (at least to view the archives) is {{fplist|packaging}}. This is the mailing list of the [[Packaging/Committee | Fedora Packaging Committee]], who determine the official packaging guidelines for Fedora projects. + +=== Introduce yourself === + +Next, you should introduce yourself to the community on the {{fplist|devel}} mailing list. The primary purpose of this is to begin the process of building trust by allowing the Fedora community members to get to know you a bit more. + +We want to break anonymity and foster real-world community within the project. You are under no obligation to reveal personal secrets. The objective is to establish a level of trust between yourself and the other members of the project. But you should at least use your real name when communicating with us. Also, a brief description of who you are, your motivations and perhaps a description of the software you have submitted for review are advisable. + +
+
+Subject: Self Introduction:  
+
+Body:  Add any information you believe is applicable 
+including past experience in free and open source projects, 
+a link to the review request you have filed and 
+a brief description of yourself. You can also post 
+your GPG key information if you want to.
+
+
+ +Feel free to participate in all the discussion that goes on in any of the lists. Community discussion and feedback is always encouraged. + +=== Find software you wish to package/maintain for Fedora === + +{{admon/note||Note that there's other methods for getting sponsored into the packager group than submitting a new package. Check the [[How_to_get_sponsored_into_the_packager_group| How to get sponsored page]] for more info.}} + +The package you are submitting can be of any Free and Open Source project that is not already packaged in Fedora. Before creating your package, make sure that the software is not already in the Fedora repository, or waiting for review. + +* Search the [https://src.fedoraproject.org/ Fedora packages] for packages already in the repository. +* Search in the [http://fedoraproject.org/PackageReviewStatus/ Review Tracker] for packages under review. +* Also check the [[Orphaned package that need new maintainers | orphaned package that need new maintainers]]. +* Be aware of [[forbidden items]]. + +=== Understand your responsibilities === + +Software components included in Fedora need to be maintained actively, and bugs - especially security issues - need to be fixed in a timely manner. As a Fedora package maintainer, it is your primary [https://docs.fedoraproject.org/en-US/fesco/Package_maintainer_responsibilities/ responsibility] to ensure this. We encourage you to get [[Policy_for_encouraging_comaintainers_of_packages | co-maintainers]] and seek the help of the Fedora community via the development mailing list whenever needed. + +=== Read Other Submissions === + +Read some other package submissions to learn about packaging and gain familiarity with the process and requirements. + +One way of doing this is to join the {{fplist|package-review}} mailing list;All comments on Fedora package reviews are sent to this (read-only from your point of view) list. + +=== Configure Your Git === + +The first thing to do when you set up Fedora packaging is to configure your username and email address for Git. These are linked in each commit you do to Fedora packages. + +
+git config --global user.name "John Doe"
+git config --global user.email johndoe@example.com
+
+ +=== Install the developer client tools === + +To build Packages for the Fedora Collection or [[EPEL]] in the Fedora build system you need [[Using_the_Koji_build_system|Koji]]. + +The {{package|fedora-packager}} package provides tools to help you setup and work with fedora; it will bring in everything necessary for general packaging work. Run the following as root: + dnf install fedora-packager + +After installation set your Fedora Account System username in {{filename|~/.fedora.upn}} (do this as your normal user, not root). You can do this via: + echo "yourfasid" > ~/.fedora.upn +(replacing "''yourfasid''", of course.) + +{{admon/tip|Kerberos|You will need to have a Kerberos ticket in order to use Koji. To get a ticket, use the following command in a Terminal: "kinit yourfasid@FEDORAPROJECT.ORG". The domain is case-sensitive, so keep FEDORAPROJECT.ORG upper case.

+To configure this if using GNOME, see [[Infrastructure/Kerberos]] +}} + +You can now use "koji" to try to build your RPM packages in the Fedora build system, even on platforms or Fedora versions you don't have. Note that you can (and definitely should) test out builds ("scratch" builds) even before your package has been approved and you have been sponsored. A simple way to do a scratch build using koji is to do this at the command line: + koji build --scratch TARGET path_to_source_RPM +Where: +* TARGET is a distribution keyword such as f25 (for Fedora 25). You can run "koji list-targets" to see all targets. To build for the next release (rawhide), ''don't'' use "dist-rawhide" - use "fX" where X is one more than the latest stable or branched release. +* Note that you need to supply the ''path'' to the source RPM (which ends in .src.rpm), and '''not''' a URL. (If you only have the spec file, use rpmbuild --nodeps -bs SPECFILE to create the new source RPM). + +Your koji builds can only depend on packages that are actually in the TARGET distribution repository. Thus, you can't use koji to build for released distributions if your package depends on other new packages that [[Bodhi | Bodhi]] hasn't released yet. You ''can'' use koji to build for rawhide (the next unreleased version), even if it depends on other new packages, as long as the other packages were built for the "rawhide" as described below. If you need to build against a package that is not yet a stable released +update, you can file a ticket with rel-eng at: https://pagure.io/releng/new_issue and request that that package is +added as a buildroot override. For packages in EPEL, you have to use the component ''epel'' to get the request to the right persons. + +You can learn more about koji via: + koji --help # General help + koji --help-commands # list of koji commands + koji COMMAND --help # help on command COMMAND + +[[Using the Koji build system]] has more information about using Koji. + +== Adding a new package == + +=== Make a Package === + +* If you don't know how to create an RPM package, see the [https://docs.fedoraproject.org/en-US/quick-docs/creating-rpm-packages/index.html How to create an RPM package]. +* Make sure that your package meets the [https://docs.fedoraproject.org/en-US/packaging-guidelines/ Packaging Guidelines] and [https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/ PackageNamingGuidelines] . +* Be aware of the [https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/ Package Review Guidelines] (they will be used during the package review). +* Make sure your package builds. This is surprisingly important because a significant number of submissions don't. + +=== Upload Your Package === + +Upload your SRPM and SPEC files onto the Internet somewhere so that others can retrieve them. This can be anywhere accessible by a URL, but it is important that the files be directly accessible, not hidden behind some service that makes people wait to download things or redirects through advertising pages. + +If you want to make ad-hoc builds available for users while you are getting the package into the official repositories, consider using [https://copr.fedorainfracloud.org Copr]. It is a lightweight automated build system that can create repositories using the SRPM you upload. You can use this Copr space to point reviewers to your src.rpm and spec. + +{{Anchor|CreateYourReviewRequest}} + +=== Create Your Review Request === + +Fill out this form: https://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Fedora&format=fedora-review. + +* Before submitting your request, be sure there’s not a previous request for the same package. There is a convenient search box on the [http://fedoraproject.org/PackageReviewStatus/ package review status page]. +* Make sure that you put the '''name of the package''' (excluding version and release numbers) in the 'Review Summary' field, along with a very '''brief summary''' of what the package is. +* Put a '''description''' of your package (usually, this can be the same thing as what you put in the spec %description) in the 'Review Description' field. Include the '''URLs''' to your '''SRPM''' and '''SPEC''' files. +* Explain in the ticket that this is your first package and you need a sponsor. Also, include any information that may help prospective sponsors. If you've been active in other review work, include links. If you're the upstream maintainer, be sure to say so. +* For bonus points, include a link to a successful koji build so that everyone knows you did all of your homework. + +{{Admon/warning | Make sure that you mention in the 'Review Description' field that this is your first package, and you are seeking a sponsor. In Fedora Package Collection, all new contributors must be sponsored. Some potential sponsors will look at the [https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=FE-NEEDSPONSOR FE-NEEDSPONSOR] bug in Bugzilla to find packages to review. You can add your package to this list by editing your review request bug (which will be created once you click 'Commit' on the form) and adding FE-NEEDSPONSOR in the 'Blocks' field.}} + +The review process is described in detail on the [[Package Review Process| Package Review Process]] page. + +{{Anchor|WatchForFeedback}} + +=== Inform Upstream === + +Fedora as a project prefers to [[Staying_close_to_upstream_projects | stay close to upstream]]. Inform the developers that you are packaging the software. You can do that by sending them an email introducing yourself and pointing out the review request. This sets up the stage for future conversations. They will usually advertise the fact that their software is now part of Fedora or might want to inform you of important bugs in the existing release, future roadmaps etc. + + +=== Watch for Feedback === + +Watch the Bugzilla report for your first package. You should get notifications of changes by email. Fix any blockers that the reviewer(s) point out. + +{{Anchor|GetSponsored}} +=== Get Sponsored === + +When the package is APPROVED by the reviewer, you must separately obtain member sponsorship in order to check in and build your package. Sponsorship is not automatic and may require that you further participate in other ways in order to demonstrate your understanding of the packaging guidelines. Key to becoming sponsored is to convince an existing sponsor-level member that you understand and follow the project's guidelines and processes. + +See [[how to get sponsored into the packager group]] for more information on the process of becoming sponsored. + +Your sponsor can add you to the packager group. You should receive an email confirmation of your sponsorship. + +=== Add Package to Source Code Management (SCM) system and Set Owner === + +Before proceeding, please sync your account by login on https://src.fedoraproject.org/ using your FAS credentials. + +If you are becoming a maintainer for a new package, instead of being a co-maintainer, use [https://pagure.io/fedpkg fedpkg] to request a new git repository for your package. The sub-command is "fedpkg request-repo" which includes help text for setting up the Pagure API token the command requires. When creating your API-key choose toogle-all for the ACLs. You must specify the repository name and review bug number. For example: + fedpkg request-repo python-prometheus_client 1590452 + +The request will be reviewed and processed by an admin, usually within 24 hours. Once the ticket is processed, you will have access to commit and build the package. + +=== Check out the module === + +You ''could'' check out your module now, but before doing that, consider doing mkdir ~/fedora-scm ; cd ~/fedora-scm - that way, all your files are inside a single directory. Also, run ssh-add, so that you won't have to keep typing in your key password. + +{{Admon/tip | Running ssh-add before doing any SCM operations is a very good idea. It will save you from having to type your key password for every operation. You only have to run ssh-add once per session, it will remember it until you log out or reboot. If ssh-add reports "Could not open a connection to your authentication agent.", start a new shell under it using exec ssh-agent bash.}} + +Now you are ready to checkout your module from the SCM: +
+ fedpkg clone 
+
+ +Where should be replaced with the name of your package. + +{{Admon/caution | If this step fails, be sure your private ssh key (~/.ssh/id_rsa) mode is set to 0400. You might have to wait for up to an hour after your request for a new git module has been approved to get write access. Make sure your public key is the same as in the [[Account_System|Fedora Account System]] (FAS). Key propagation may take an hour or so after uploading into FAS.}} + +{{Admon/important| Note that fedpkg does not set the user config for your new git repo automatically. Make sure to have these set globally or locally in your new repo before you do your first commit (see [[Git_Quickref#Configure_your_global_git_settings|Configure your global git settings]]).}} +{{Admon/important| Note: If you are not a member of the fedora packager group, you will receive a "permission denied" error. Use the -a flag to clone anonymously. }} + +=== Test Your Package === + +Refer to [[Using_Mock_to_test_package_builds]] and [[Using_the_Koji_build_system#Scratch_Builds]] for more information on testing your package. Mock uses your local system while Koji command line tool uses the Fedora build system server. + +=== Import, commit, and build your package === + +Now that you've checked out your (empty) package module with fedpkg, +cd into the module's main branch: + cd +Run fedpkg to import the contents of the SRPM into the SCM: + fedpkg import PATH_TO_SRPM + + # Review Changes, press 'q' to stop; Revert with: git reset --hard HEAD + git commit -m "Initial import (#XXXXXX)." + git push + fedpkg build + +Obviously, replace PATH_TO_SRPM with the full path (not URL) to your approved SRPM, and XXXXXX with the package review bug number. + +This imports into, commits, and builds only the '''main''' ([[Releases/Rawhide|Rawhide]]) branch. + +If the push fails with this kind of message: + W access for why DENIED to YOUR_ACCOUNT + fatal: The remote end hung up unexpectedly + Could not push: Command '['git', 'push']' returned non-zero exit status 128 +Then you don't have the necessary rights to modify that package branch; +view https://src.fedoraproject.org/rpms/PACKAGE_NAME +to request those rights. + +For more information on using the Fedora package maintenance system, see the [[Package maintenance guide]]. + +=== Update Your Branches (if desired) === + +Branches are f# (formerly F-# and before that FC-#), main, etc. So ''f{{FedoraVersion}}'' is the branch for Fedora {{FedoraVersion}}. + +To switch to a branch first: + fedpkg switch-branch BRANCH (e.g. f{{FedoraVersion}}) + +Merge the initial commit from main (Rawhide), creating an identical commit in the branch: + git merge rawhide + +Push the changes to the server: + git push + +Build the package: + fedpkg build + +If there is another branch to work with repeat "To switch to a branch" and import and commit to each branch. + +{{Admon/warning | Be sure that you build for rawhide (main) branch before pushing updates for any other branches! Otherwise, those updates will get inherited into rawhide, which is almost certainly not what you want.}} +{{Admon/warning | Sync to buildsys is an hourly thing. So, sometimes you might have to wait for an hour to get access of the build server to give "fedpkg build".}} +If everything goes well, it should queue up your branch for building, the package will cleanly build, and you're done! + +If it fails to build, the build system will send you an email to report the failure and show you to the logs. Commit any needed changes to git, bump the SPEC release number, and request a new build. + +=== Submit Package as Update in Bodhi === + +The Fedora update system called [[Bodhi]] is used for pushing updates, classifying packages etc. Do not submit Rawhide (main branch) builds via Bodhi. + +You can push an update using Bodhi via the command line using this in each branch: + fedpkg update + +See the [[Package_update_HOWTO|update submission guide]] for more details. + +=== Make the package available in "comps" files === + +If appropriate for the package, make it available in "comps" files so that it can be selected during installation and included in dnf's|yum's package group operations. See [[PackageMaintainers/CompsXml|How to use and edit comps.xml for package groups]] for more info. + +=== Watch for updates === + +Fedora has the infrastructure available for monitoring new upstream releases of the software you are packaging. Refer to [[Upstream Release Monitoring]] for more details. + +== Getting Help == + +We know that this process can be as clear as mud sometimes, and we're always trying to make it better. If you run into any problems, or have any questions, please ask on the {{fplist|devel}} mailing list or in {{fpchat|#fedora-devel}} on freenode.net. + +== Getting a new package into Fedora Package Collection for existing maintainers == + +If you already maintain a package in Fedora and want to maintain another, follow the [[new package process for existing contributors]]. + +== One-off contributions == + +Changes to [https://src.fedoraproject.org/browse/projects/ existing packages] can be suggested by submitting [https://docs.pagure.org/pagure/usage/pull_requests.html pull requests]. +You must have a [[Join_the_package_collection_maintainers#Create_a_Fedora_Account|Fedora account]] to create a pull request. See [[Package_maintenance_guide#Using_fedpkg_anonymously]] for instructions and [[Infrastructure/HTTPS-commits]] for more information. + +[[Category:Package Maintainers]] [[Category:Join]] diff --git a/modules/ROOT/pages/wiki/New_Package_Process_for_Existing_Contributors.wiki b/modules/ROOT/pages/wiki/New_Package_Process_for_Existing_Contributors.wiki new file mode 100644 index 0000000..06ba71a --- /dev/null +++ b/modules/ROOT/pages/wiki/New_Package_Process_for_Existing_Contributors.wiki @@ -0,0 +1,60 @@ +{{autolang|base=yes}} +{{admon/important|Contributors only!|This document is for existing Contributors only. If you do not already have a Fedora account or if this is your ''first'' Fedora package, you ''must'' follow the process documented in [[Join_the_package_collection_maintainers|Join the package collection maintainers]].}} + +{{admon/tip | Modularity | If you want to build your package as a module (on an independent life cycle, for multiple Fedora releases out of a single source branch, or in multiple versions for one or more releases), see the [https://docs.fedoraproject.org/en-US/modularity/making-modules/adding-new-modules/ Adding new modules page] in Fedora Docs. }} + +This is a short version of the [[PackageMaintainers/Join]] document, streamlined to show how existing contributors can make new packages. + +'''Step 1:''' Read the [[Packaging:Guidelines| Packaging Guidelines]] and [[Packaging:NamingGuidelines| Package Naming Guidelines]] . Really. Be comfortable with them.
+'''Step 2:''' Make a package. +* You should make sure that it is a new package. A list of existing packages in Fedora Packages is here: https://src.fedoraproject.org/projects/rpms/* +* Some information on how to create an RPM package is in the [[PackageMaintainers/CreatingPackageHowTo| Creating Package HOWTO]] +* Make sure that your package meets the [[Packaging:Guidelines| Packaging Guidelines]] and [[Packaging:NamingGuidelines| Package Naming Guidelines]] +* Be aware of [[Forbidden_items]] and [[Packaging:ReviewGuidelines| Package Review Guidelines]] (they will be used during the package review) +'''Step 3:''' Upload your SRPM and SPEC files onto the internet somewhere.
+* If you have already got a Fedora Account then you can use your storage at http://fedorapeople.org for this. +'''Step 4:''' Make sure you have a Bugzilla account at bugzilla.redhat.com
+'''Step 5:''' Fill out this form: https://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Fedora&format=fedora-review +* Make sure you put the name of the package in the Review Summary field, along with a very brief summary of what it is +* Make sure that you put the URL paths for the SPEC file and the SRPM file in the Review Description +* Put a description of your package (usually, this can be the same thing as what you put in the spec %description) in Review Description +* The review process is described in detail here: [[Packaging:ReviewGuidelines| Package Review Guidelines]] +'''Step 6:''' Watch the Bugzilla report for your first package (you created this in step 5). Fix any blockers that the reviewer(s) point out.
+'''Step 7:''' When the package is approved by the reviewer, request a git module fedpkg request-repo PACKAGE-NAME BUGZILLA-TICKET-NUMBER and when the repo is created request branches using fedpkg request-branch --repo PACKAGE-NAME BRANCH (see [https://fedoraproject.org/wiki/Changes/fedrepo-req-to-fedpkg])
You might need to get a pagure-API-token before being able to successfully request the repo.
+ +{{admon/tip | Extra info | If you want to set the description or upstream url on the distgit repo, pass the --description or --upstreamurl flags to fedpkg request-repo.}} + +{{admon/tip | All branches | If you want to request all active Fedora branches, pass the --all-releases flag to fedpkg request-branch.}} + +* Please wait until the request is approved. +'''Step 8:''' Once the request is approved, checkout the git module fedpkg clone <packagename> (details [[Join_the_package_collection_maintainers#Check_out_the_module|here]]) +* Refer to the [[Package maintenance guide]] +* It is probably a good idea to make a "git" toplevel directory, then check-out your files inside of that. +'''Step 9:''' Import your srpm +* First kinit username@FEDORAPROJECT.ORG +* Then you can import the approved SRPM into the rawhide branch by running fedpkg import libfoo-x.x.x.src.rpm; git commit -m "Initial import (#nnnnnn)." (where nnnnnn is your Bugzilla package review bug number). +* Obviously, replace libfoo-x.x.x.src.rpm with the full path to your approved SRPM. +* You should see it upload the sources, and finish successfully. If you didn't set up ssh-agent it will ask often for your ssh-key passphrase. This is normal. +* Now run git push to get the final versions in your rawhide branch. +'''Step 10:''' You can now import the package to your branches (which you requested in Step 7) too +* The quickest way to do this is to use fedpkg switch-branch BRANCH to switch the branch (where BRANCH can be "f13" and so on). +* Now you can git merge rawhide. This will get .spec file, .gitignore and source file together with any patches and other files from the rawhide branch and create an identical commit. +* Previous step already created commit for you, now you can push the results using fedpkg push or git push. +'''Step 11:''' Request builds +* For each branch that you'd like to request a build for, switch using fedpkg switch-branch and run: fedpkg build +* If everything goes well, it should queue up your branch for building, the package will cleanly build, and you're done! +* If it fails to build, the buildsystem will send you an email to report the failure and link you to the logs. Commit any needed changes to git, bump the spec release number and request a new build. +'''Step 12:''' Close the Bugzilla ticket (assuming that the package built successfully) +* You should close it with resolution NEXTRELEASE or RAWHIDE, depending on where you built the package. The resolution field will appear after you set the status field to CLOSED. +'''Step 13:''' If this package will be built for any version of Fedora that is already released please submit it for inclusion in the 'fedora-updates' repository for those versions of Fedora. See [[Package_update_HOWTO#Later_Branched_and_stable_releases|the update submission guide]] for more details.
+'''Step 14:''' Add the package to the [[PackageMaintainers/CompsXml|comps file(s)]] if appropriate. +
+'''Step 15:''' Consider enabling [[Upstream Release Monitoring]] for the package. + +We know that this process can be as clear as mud sometimes, we're always trying to make it better. If you run into any problems, or have any questions, please ask on the fedora development list.
+ +http://lists.fedoraproject.org/pipermail/devel/ + +There is a helpful [[Package maintenance guide]] which may also be of use. + +[[Category:Package Maintainers]] diff --git a/modules/ROOT/pages/wiki/Orphaned_Packages_that_Need_New_Maintainers.wiki b/modules/ROOT/pages/wiki/Orphaned_Packages_that_Need_New_Maintainers.wiki new file mode 100644 index 0000000..39f73df --- /dev/null +++ b/modules/ROOT/pages/wiki/Orphaned_Packages_that_Need_New_Maintainers.wiki @@ -0,0 +1,63 @@ +{{autolang|base=yes}} + +== About Orphan and Retired (Deprecated) Packages == + +When Fedora maintainers do not want or are not able to maintain a package any +longer, they can orphan or [[How_to_remove_a_package_at_end_of_life|retire]] the +package. When they think that the package is still useful for Fedora, they +should orphan it. Then other maintainers that are interested in maintaining it, +can take ownership of this package. In case the package is no longer useful for +Fedora, e.g. because it was renamed, upstream does not exist anymore, then it +should be retired. But this is only possible for development releases such as Branched or Rawhide. + +Orphaned packages remain in stable releases and are the responsibility of the collective packaging community to maintain. + +{{admon/warning|Retiring packages|Orphan packages will be retired if they remain orphaned for six weeks. Packages will be retired in Fedora Rawhide and Branched (until the Beta Freeze).}} + +{{admon/warning|When to orphan and retire your packages|We encourage maintainers considering orphaning their packages to do it as early in the development cycle as possible. Shortly after the prior release is branched is a good time.}} + +== Orphaning Procedure == + +# If the package has co-maintainers, contact them to ask whether one of them wants to take over ownership of the package. This step is optional. If no co-maintainer can be found to take over the package, the package should be given to the "orphan" user.

The current list of maintainers can be found in the "Users & Groups" tab of the setting for the package repo. The URL will look something like this — https://src.fedoraproject.org/rpms/PACKAGE_NAME/settings. +# After the first step is finished, go again to the settings tab for your package's Pagure repository. Navigate down to the ''Give Project'' section and "give" the project to the new maintainer or the "orphan" user (in case no new maintainer was selected). +# For completeness, under the ''Users and Groups'' section, remove yourself from the list as well. +# Also reset your watch status if you do not want to be CC'ed on new package bugs. +# If the package was given to the "orphan" user, announce on [https://lists.fedoraproject.org/mailman/listinfo/devel devel] which package you orphaned, so that others have a chance to take over as maintainer. +# Reassign the package's tickets to the orphan user, extras-orphan@fedoraproject.org. + +== Claiming Ownership of an Orphaned Package == + +# Check why the package was orphaned by looking for the email to [https://lists.fedoraproject.org/mailman/listinfo/devel devel]. +# Announce on [https://lists.fedoraproject.org/mailman/listinfo/devel devel] which packages you want to take over. +# Log in to [https://src.fedoraproject.org/ src.fedoraproject.org]. On the page with the orphaned package, click the '''✋ Take''' button in the left column. (If the option doesn't work for you, [https://pagure.io/releng/new_issue?template=package_unorphan&title=Unorphan%20%3Cpkgname%3E submit a ticket to the Release Engineering team], stating which package you want to claim and that this option didn't work.) +# Reassign and claim all open bug reports for the package in Bugzilla. + +== Claiming Ownership of a Retired Package == +{{admon/warning|Un-Retiring long-time retired packages|Packages that are retired for Rawhide for more than 8 weeks need to be reviewed again before they can be un-retired. This is also true for EPEL-only packages.}} + +If you really want to maintain a retired package, you need to be aware that +if upstream is dead, fixing release critical bugs, etc becomes your +responsibility. This is to ensure the high quality and standards of packaging +remain for Fedora package collection. There may be additional issues with +retired packages. If possible, consult with the former maintainer for more information. +The process is a bit different from unorphaning a package + +# See if you can figure out why the package was retired including searching for information about orphaned packages on [https://lists.fedoraproject.org/mailman/listinfo/devel devel mailing list] or emailing the former maintainer. You can also check dead.package in the SCM (url like: [https://src.fedoraproject.org/rpms/system-config-network/blob/rawhide/f/dead.package https://src.fedoraproject.org/rpms/'''package_name_here'''/blob/rawhide/f/dead.package]) +# Announce on [https://lists.fedoraproject.org/mailman/listinfo/devel devel] which packages you would like to become the owner of. +# Retired Fedora packages (rawhide branch retired) require a re-review if they are retired for more than eight weeks or if there is no previous review of the package. Submit a review request (a new bugzilla ticket) and have the package approved by a reviewer as if it were new to Fedora. See [[Package Review Process|the package review process]] for more information. To unretire a EPEL branch if the package is still in Fedora, no re-review is required. +# Request unretirement by filing a [https://pagure.io/releng/new_issue?template=package_unretirement&title=Unretire%20%3Cpkgname%3E releng ticket]. Specify all branches that need to be un-retired (inlcuding "rawhide" for Rawhide, unless it is for EPEL only) and include the link to re-review. In this ticket, request that the [[ReleaseEngineering|Release Engineering team]] unblock the package for the releases that the package should be un-retired for. In this request, clearly specify which branches should be unblocked. +# Restore the contents in GIT and prepare a new build and update (if necessary). + +== Lists of Orphan and Retired Packages == + +* [https://src.fedoraproject.org/user/orphan A list of currently orphaned and/or retired packages] + +== References == +* https://fedorahosted.org/fesco/ticket/1332 +* http://meetbot.fedoraproject.org/fedora-meeting/2014-08-27/fesco.2014-08-27-17.00.html +=== EPEL === +* https://fedorahosted.org/epel/ticket/4 +* http://meetbot.fedoraproject.org/epel/2014-10-31/epel.2014-10-31-20.01.html +{{Anchor|core}} + +[[Category:Package Maintainers]] [[Category:Policy]] diff --git a/modules/ROOT/pages/wiki/Package_Maintenance_Guide.wiki b/modules/ROOT/pages/wiki/Package_Maintenance_Guide.wiki new file mode 100644 index 0000000..410ff5e --- /dev/null +++ b/modules/ROOT/pages/wiki/Package_Maintenance_Guide.wiki @@ -0,0 +1,285 @@ +{{autolang|base=yes}} + +This page provides some basic instructions for day-to-day usage of the [http://git-scm.com/ git]-based package maintenance system for Fedora. It is intended primarily for new and current Fedora package maintainers, but does briefly [[#anon|cover anonymous read-only use of the system]]. It is not a guide to RPM packaging per se. Some pre-existing knowledge of git may be useful, but is not a pre-requisite (in fact, Fedora packaging can be a relatively painless introduction to it). + +You may have been looking for, or also be interested in: + +* [[How_to_create_an_RPM_package|Learning to create packages]] +* [[Join_the_package_collection_maintainers|Becoming a package maintainer]] +* [[Package_update_HOWTO|Submitting package updates]] +* [[New_package_process_for_existing_contributors|Adding a new package to the repository]] as an existing maintainer +* [[PackageDB_admin_requests#Additional_branches_for_existing_packages|adding a new release branch]] to an existing package +* [[Packaging:Guidelines|The Packaging Guidelines]] + +== Installing ''fedpkg'' and doing initial setup == + +Start by installing {{package|fedpkg}} with {{command|dnf install fedpkg}}. This will be your primary interface to the packaging system. + +You also must have an ssh key configured in the [https://accounts.fedoraproject.org/ Fedora Accounts System] to be able to make changes to any package (including your own). fedpkg will expect the correct ssh key to be available in your keyring. + +Before uploading sources with new-sources and upload and building packages in Koji, with build for example, you have to get your Kerberos credential first with kinit, e.g. + + kinit [FAS name]@FEDORAPROJECT.ORG + +(Keep FEDORAPROJECT.ORG in capital case) + +Set your Fedora Account System username in {{filename|~/.fedora.upn}}. You can do this via {{command|echo "FAS_USERNAME" > ~/.fedora.upn}}. + +== Common fedpkg commands == + +This section lists typical fedpkg commands in a normal workflow, with short descriptions. In this workflow, we will be operating on the [[Releases/Rawhide|Rawhide]] branch of the package. + +* Check out a package: + fedpkg co + cd +{{hidden|header=Details|content=This retrieves a copy of the package sources from the server. It's known as your 'working copy'.|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}} +* Update your checked-out copy from the Fedora server: + fedpkg pull +* Retrieve the package sources: + fedpkg sources +{{hidden|header=Details|content=This pulls any sources stored in the "lookaside cache" (see below for more). Steps like {{command|fedpkg prep}} and {{command|fedpkg srpm}} will do this if necessary, but you may want a copy right away.|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}} +* Make your changes to the package +{{hidden|header=Details|content=This is not an RPM packaging guide, so we'll assume you know what you're doing here. New sources and patches go in the working copy directory for now.|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}} +* Run the 'prep' stage (extract source, apply patches etc) within the checkout directory: + fedpkg prep +{{hidden|header=Details|content=This is useful for making sure your patches apply cleanly, and inspecting the source tree if you need to do so.|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}} +* Do a local build of the current state: + fedpkg local +{{hidden|header=Details|content=This is the simplest kind of test build, but it's usually cleaner and a better test to do a Mock or Koji scratch build (see below).|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}} +* Do a mock build of the current state: + fedpkg mockbuild +{{hidden|header=Details|content=This fires off a [https://github.com/rpm-software-management/mock/wiki Mock] build, if you have Mock configured correctly. [[Using_Mock_to_test_package_builds]] can help there. |headerstyle=background:#e5e5e5|fw1=normal|ta1=left}} +* Generate a .src.rpm from the current state: + fedpkg srpm +{{hidden|header=Details|content=You can request a [[Koji]] 'scratch build' (a test build, which will not go to any repository) of the generated .src.rpm with the {{command|koji build --scratch}} command (see {{command|man koji}}).|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}} +* Do a scratch build using koji: see [https://fedoraproject.org/wiki/Using_the_Koji_build_system#Scratch_Builds Koji scratch builds] +* Check changes you have made: + fedpkg diff +{{hidden|header=Details|content=This is handy for making sure you didn't touch something by mistake, or forget to bump the release, or forget to include a changelog...|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}} +* Run some checks (rpmlint) on your package: + fedpkg lint +{{hidden|header=Details|content=If you want to whitelist some rpmlint errors and prevent them from appearing, you can create an rpmlint config file named <source_package_name>.rpmlintrc and it will get applied.|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}} +* Stage any small patches or new source files for commit: + git add (somefile) +{{hidden|header=Details|content=git does not consider all files in the working directory to be a part of the git repository by default (handy, for keeping other files around that are relevant, like the source tree). This tells git to start considering these files as part of the repository ''locally''. When you 'commit' and 'push' later, this change is communicated to the server.|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}} +* Upload new source files to the lookaside cache: + fedpkg new-sources +{{admon/warning|Alert|This will replace the current list of source files, not add to it. See ''Details'' for more details on the lookaside cache system.}} + fedpkg upload +{{hidden|header=Details|content='Pristine' upstream sources (like release tarballs) and other larger source files are stored in the [[Package_Source_Control#Lookaside_Cache|lookaside cache]] system, not committed directly to git. This provides more efficient storage and transfer of the files. The {{filename|sources}} and {{filename|.gitignore}} files in the repository keep it in sync with the lookaside cache. Any time you use {{command|fedpkg new-sources}} or {{command|fedpkg upload}}, you must remember to 'commit' changes to those files. + +{{command|new-sources}} 'starts from scratch', replacing all files currently in the lookaside cache - you'll typically use this command for many packages with just a single source tarball, each time you update to a new upstream version. {{command|upload}} just adds the given file to those already in the cache. Do remember not to leave stale sources lying around.|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}} +* Switch to a different release branch: + fedpkg switch-branch +{{hidden|header=Details|content=Each Fedora release has its own branch in each package repository so different builds can be sent to each release. See below for more details on working with branches.|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}} +* Generate git changelog from package changelog: + fedpkg clog +{{hidden|header=Details|content=This command extracts your package changelog entry to the file {{filename|clog}}, so you can use it as the git changelog if you like. Some maintainers draw a distinction between the two, some do not.|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}} +* Commit changes: + fedpkg commit (-F clog) (-p) (-c) +{{admon/note|Difference from git|This behaves by default like {{command|git commit -a}} - it stages modified files and commits all at once, though it ''does not'' add files which git is not yet tracking.}} +{{hidden|header=Details|content=This creates a sort of bundle, a 'commit', of your changes to the repository, with a unique identity and a changelog. Other maintainers - and you yourself, later - can view the history of changes to the repository with the 'commit' as the finest level of detail. It is good practice to use many relatively small commits, each for a single purpose - don't combine a version bump with a bunch of whitespace fixes and some scriptlet changes all in one commit, create separate commits for each. + +The {{command|-F clog}} parameter will use the {{filename|clog}} file from the previous step as the changelog. {{command|-p}} will push (see below) at the same time as committing. {{command|-c}} combines the {{command|clog}} and {{command|commit -F clog}} steps into one, if you like that.|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}} +* Push changes: + fedpkg push +{{hidden|header=Details|content=This sends all the new 'commits' in your local working copy to the upstream server. If you are still learning the system, now is a good time to {{command|fedpkg co}} another copy of the repository somewhere else, compare what you get to your working copy, and run a test build on it.|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}} +* Do an 'official' build of the latest pushed changes: + fedpkg build +* Submit 'official' builds from a stream branch + fedpkg build +{{hidden|header=Details|content=There is no difference in the command line to submit multiple builds from a stream branch. But you need to create a config file {{command|package.cfg}} in the repository and set option for the builds. For example config file is created in a stream branch {{command|8}} of package {{command|foo}}, which has content, + [koji] + targets = f28 epel7 +This example shows when you execute {{command|build}} command, fedpkg is able to submit builds for releases, {{command|f28}} and {{command|epel7}}. + +In practice, you are able to specify two shortcut names {{command|fedora}} and {{command|epel}} for convenience. fedpkg retrieves current active Fedora and EPEL releases automatically. Hence, if you don't want to select a subset of releases, or just simply going to build packages for active releases without knowing the concrete release name, shortcut names would be helpful. You can specify to build for {{command|rawhide}}, use name {{command|master}}. +|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}} +* In the event you are working with a Docker [[Changes/Layered_Docker_Image_Build_Service|Container Layered Image Build]] + fedpkg container-build +{{admon/important|Going into production|This is the first point at which you might possibly cause real mess for a real user, so use it with caution. If you are following the example and operating on Rawhide, your build would go live for Rawhide users some few hours after you ran this command.}} +{{admon/note|Uses pushed state|Unlike most of the above commands, this operates on the ''state you have pushed to git'', not the local state. If you have issues make sure you have pushed and committed all patches and handled the sources correctly.}} +{{hidden|header=Details|content=This triggers a 'real' (not scratch) build of your package in [[Koji]]. Depending on the release you are building for, it may go directly to the [[Repositories#stable|''stable'' state]] or it may have to run through the [[Updates Policy|update process]]. See the [[Package_update_HOWTO|package update guide]] for more details on this. The command will output a URL where you can monitor the build's progress in Koji.|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}} +* Submit a package update for the latest build (but see [[Package_update_HOWTO#Updating_inter-dependent_packages|Updating inter-dependent packages]] if you are making inter-dependent changes to more than one package): + fedpkg update +{{hidden|header=Details|content=Again, see the [[Package_update_HOWTO|package update guide]] for more details on this process. This step is not actually applicable to Rawhide, but illustrated here for completeness.|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}} + +== Typical ''fedpkg'' session == + +A typical session may look like this: +
+fedpkg clone foo
+cd foo
+fedpkg sources
+fedpkg new-sources foo-0.0.2.tar.bz2
+gedit foo.spec       # change the required things in the specfile.
+                     # rpmdev-bumpspec is useful for simple version updates
+fedpkg mockbuild     # check that the changes you made are correct
+fedpkg diff
+fedpkg lint
+fedpkg commit -p -c  # commit and push in one go
+
+ +== Working with branches == + +Each Fedora release is represented by a branch in the git repository. You can switch between them like this: + fedpkg switch-branch f{{FedoraVersionNumber}} + fedpkg switch-branch f{{FedoraVersionNumber|previous}} + fedpkg switch-branch rawhide +The ''rawhide'' branch is for [[Releases/Rawhide|Rawhide]]. You can maintain each branch entirely separately, if you like, laboriously copying changes between them (so long as you always stay within the [[Updates Policy]] requirements). However, git provides us with several handy tools for working with branches. Here's an example: +{{#tag:pre| +fedpkg clone bzrtools +# Make some changes in the rawhide branch +fedpkg new-sources bzrtools-2.2.tar.gz +gedit bzrtools.spec +fedpkg commit +fedpkg switch-branch f{{FedoraVersionNumber}} +git merge rawhide +# for push into repo +fedpkg push +}} +This will 'merge' the changes from the ''rawhide'' (Rawhide) branch to the f{{FedoraVersionNumber}} branch. git aficionados may note this is a somewhat unusual workflow, but it is appropriate to the context of package management. Remember, after pushing to and building for a stable release or a [[Releases/Branched|Branched]] release after [[Updates Policy#Bodhi enabling|Bodhi has been enabled]], you will have to [[Package_update_HOWTO|submit an update]] before any other Fedora users will see your build. + +Note that merges will only be sure to work cleanly so long as the branches have not previously diverged. That is, if you do this: +{{#tag:pre| +fedpkg clone bzrtools +# Make some changes in the rawhide branch +fedpkg commit +fedpkg switch-branch f{{FedoraVersionNumber}} +# Make some changes in the f{{FedoraVersionNumber}} branch +fedpkg commit +fedpkg switch-branch rawhide +# Make some more changes in the rawhide branch +fedpkg commit +fedpkg switch-branch f{{FedoraVersionNumber}} +git merge rawhide +}} +you may encounter a ''merge conflict''. + +Remember that git is a ''collaborative'' system, and used as such in Fedora package management. It is often the case that you must consider changes made by others in working on a package, and consider how your changes will affect others. + +=== Resolving merge conflicts === + +This is a large topic and somewhat beyond the scope of this guide, but we can give basic pointers. There are other good references in the [http://git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging git book] and at [https://help.github.com/articles/resolving-a-merge-conflict-from-the-command-line github]. + +When you git merge and a conflict occurs you can edit the files that have conflicts. Remove the conflict markers in the files and merge the changes manually. Use {{command|git diff}} or {{command|fedpkg diff}} to inspect the changes against the pre-conflict state and verify you are happy with the resolution. Then you can commit the files with {{command|fedpkg commit}} or {{command|git commit -a}}. git will know if you have resolved the conflict by checking that all the conflict markers have been removed. + +=== Using git mergetool to resolve conflicts === + +Git provides a graphical diff program to help resolve conflicts. This can be handy for visualizing what changes have occurred and dealing with them as a set. +{{#tag:pre| +git config --global merge.tool meld +fedpkg switch-branch f{{FedoraVersionNumber}} +git merge rawhide +# Conflicts occurred +git mergetool # Opens up a meld showing a three way diff of + # the merge, working tree, and the last commit +# Resolved all the conflicts in the GUI +git add CONFLICTEDFILES +git commit +}} + +== Requesting special dist tags == + +When a change to a package affects a large number of dependencies (e.g. all perl, python, ruby or ghc packages), requiring them to be rebuilt, it may be better to initially do the builds in a special repository, so that there is less disruption in Rawhide. + +If you think you have an update that falls under this case you can request a special dist tag by filing a [https://fedorahosted.org/rel-eng/newticket release engineering ticket]. Someone from [[ReleaseEngineering|release engineering]] will likely want to discuss your needs to make sure this is really an appropriate case (it's OK ask if you aren't sure) and that you get what you need. + +{{anchor|anon}} +== Using fedpkg anonymously == + +You can use fedpkg like this: + fedpkg clone --anonymous +to check out a package without requiring identification. Obviously, you will not be able to push any changes to this repository, but it is useful for non-packagers who simply want to examine a package and make changes for their own use. + +If the intention is to submit changes to a Fedora developer, the package repository can be forked and a pull request submitted. Forking is done in the [https://src.fedoraproject.org src.fedoraproject.org] web ui. You need a [https://admin.fedoraproject.org/accounts/ Fedora account] to be able to fork. After the fork has been created, typical fedpkg session might look like this: +
+fedpkg clone --anonymous forks/my-username/rpms/somepackage
+cd somepackage
+gedit somepackage.spec    # change the required things in the specfile.
+                          # rpmdev-bumpspec is useful for simple version updates
+spectool -g somepackage.spec # download the referenced sources to local machine
+                             # fedpkg new-sources cannot be performed anonymously, that is left
+                             # for the maintainer to do after the pull request has been merged
+fedpkg mockbuild          # check that the changes you made are correct
+fedpkg diff
+fedpkg lint
+git checkout -b my-branch # create a branch to use in the pull request
+fedpkg commit -p -c       # commit and push in one go
+
+Afterwards, a pull request from ''my-branch'' to the main package repository can be created in the ''src.fedoraproject.org'' web ui. + +== Tips and tricks == + +=== Local branch names === + +If you use git commands to branch and checkout directly, you can define whatever local branch names you want. If you use {{command|fedpkg switch-branch}}, it will default to creating the names used in the examples above. + +=== Current branch and state in shell prompt === + +It is often helpful to know what branch you are working on at a glance. You can add this information to your bash prompt with the information [[Git_Quickref#Display_current_branch_in_bash|here]]. + +=== Importing a .src.rpm to update === + +The {{command|fedpkg import}} command usually used to initially populate a git package repository from a .src.rpm that has been through the [[Package Review Process]] can also be used to update a normal working copy, if you have an old-school packaging process to which you are particularly attached. Just run {{command|fedpkg import file.src.rpm}} and it will upload new tarballs into lookaside cache, update a working copy of the last version found in git, and commit all changes. {{command|fedpkg import --help}} documents some other parameters it can accept. + +{{admon/warning|Caution!|This approach makes it harder to verify that your changes are safe and do not overwrite changes made to the package by others. For this reason, its use is not recommended.}} + +=== Making changes on an older branch without breaking the upgrade path === + +Here is the scenario: you've built your package successfully on the ''{{FedoraVersionNumber}}'' branch, but there is a problem keeping your package from building on ''{{FedoraVersionNumber|last}}''. + +Solution: make your changes in the branch and then add a digit to the very right of the release tag. There is no need to change the release in the other branches. This allows upgrades to work smoothly if the user upgrades to a newer release of Fedora. + +
+Name:    foo
+Version: 1.0
+Release: 1%{?dist}
+
+Name:    foo
+Version: 1.0
+Release: 1%{?dist}.1
+
+ +Then tag and build as usual. This approach was initially discussed [https://www.redhat.com/archives/fedora-extras-list/2006-May/msg00083.html in this mailing list thread]. + +=== Removing a package build pending for [[Releases/Rawhide|Rawhide]] or [[Releases/Branched|Branched]] === + +From time to time you may want to remove a package build you submitted to Rawhide or to Branched prior to the Alpha freeze (both cases where the build would usually go out to the main [[Repositories|repository]] without further gating). This could happen in a situation where a bug or issue is found in your package that will be resolved upstream in the next release, or you realize you made a significant mistake in the build that cannot easily be corrected. + +{{admon/caution|Use this carefully!|This should only be done on the same day of the build, before it is included in a compose. If your build was already included in a compose you must not untag it! Check the [https://apps.fedoraproject.org/releng-dash/ Release Engineering Dashboard] to get the starting time of the last compose.}} + +You can remove the package by using [[Koji]]: {{command|koji untag-pkg f{{FedoraVersionNumber|next}} foo-1.1.3-1.fc{{FedoraVersionNumber|next}}}} + +where {{filename|foo-1.1.3-1.fc{{FedoraVersionNumber|next}}}} is replaced with the name of your package build. See {{command|koji help}} or [[Using_the_Koji_build_system|using Koji]] for more information. + +=== ssh fingerprint === + +The recommended option is to include "VerifyHostKeyDNS yes" in your ~/.ssh/config file. This will result in using DNS to check that the key is correct. + +But you can also manually check against the list of keys at https://admin.fedoraproject.org . The strings there are what ends up in your ~/.ssh/known_hosts file. So you can accept the fingerprint when prompted and then check that the correct string for src.fedoraproject.org ended up in your ~/.ssh/known_hosts file. + +=== Problems connecting to the repository === + +The ''fedpkg'' tool clones repositories using the ssh:// protocol, so this should not be a problem normally (as long as you have your ssh key). If you cloned using the ''git'' utility itself, check the {{filename|.git/config}} file to ensure the remote repository is being accessed via an ssh:// protocol, and not git://. + +=== It builds here, why doesn't it build there? === + +Is your package building locally - even with Mock, even as a scratch build! - but not when you run {{command|fedpkg build}}? Before you get too frustrated, remember {{command|fedpkg build}} runs on the package as it exists in the upstream repository, not your local working copy. Make sure you have committed and pushed all changes and source files, and handled the lookaside cache correctly. Other issues that have been reported, are issues because of [https://bugzilla.redhat.com/show_bug.cgi?id=1179139 build/make check parallelization] and failures because of test suites that depend on operations finish on precise timing (and a busy build system may not be able to perform operations on time). + +== References == + +* https://src.fedoraproject.org/ +* [[Infrastructure/Kerberos]] +* [[Package_Renaming_Process]] +* [[PackageMaintainers/PackagingTricks]] +* [[Package_update_HOWTO]] +* [[PackageMaintainers/BuildSystemClientSetup#Install_the_Client_Tools_.28Koji.29]] +* [[PackageMaintainers/MockTricks#How_do_I_use_Mock.3F]] +* [[Using_the_Koji_build_system]] +* [[Package_Review_Process]] +* [[Fedora_Release_Life_Cycle]] +* [[PackageMaintainers/Join]] +* [[Infrastructure/VersionControl/dist-git]] + +[[Category:Package Maintainers]] diff --git a/modules/ROOT/pages/wiki/Package_Renaming_Process.wiki b/modules/ROOT/pages/wiki/Package_Renaming_Process.wiki new file mode 100644 index 0000000..3557f6f --- /dev/null +++ b/modules/ROOT/pages/wiki/Package_Renaming_Process.wiki @@ -0,0 +1,15 @@ +For a variety of reasons it may become necessary to rename a package in Fedora. The goal of this page is to outline the process that must be followed when such an event occurs. + +== Re-review required == + +When you wish to rename a package, you '''MUST''' request a re-review of your package through the [[Package Review Process|normal review process]]. In this review request, you '''MUST''' state that this is a re-review request for a package rename, and the old package name that this is replacing. + +The reviewer of the package '''MUST''' explicitly acknowledge this fact, and check the package for the proper Obsoletes and Provides (see [[Packaging:NamingGuidelines#Renaming.2Freplacing_existing_packages|the naming guidelines]] for more information.) They '''MUST''' document in the review request that they have done so. + +== After the review == + +After the review is completed, and is satisfactory (for the avoidance of doubt, the lack of a clean upgrade path for users of the package in the form of proper Provides and Obsoletes is considered a blocker to the review), request git for the package as you normally would for a new package. + +After the new package is imported into git, you can then follow the [[How to remove a package at end of life|package retirement process]] for the old package. + +[[Category:Package Maintainers]] [[Category:Guidelines hackfest]] [[Category:Policy]] diff --git a/modules/ROOT/pages/wiki/Package_Review_Process.wiki b/modules/ROOT/pages/wiki/Package_Review_Process.wiki new file mode 100644 index 0000000..78750b9 --- /dev/null +++ b/modules/ROOT/pages/wiki/Package_Review_Process.wiki @@ -0,0 +1,136 @@ +{{autolang|base=yes}} + +== Review Purpose == + +In order for a new package to be added to Fedora, the package must first undertake a formal review. The purpose of this formal review is to try to ensure that the package meets the quality control requirements for Fedora. This does not mean that the package (or the software being packaged) is perfect, but it should meet baseline minimum requirements for quality. + +Reviews are currently done for totally new packages, [[Package_Renaming_Process#Re-review_required|package renames]], old packages that were once deprecated returning to the collection, and packages merged from the old Fedora Core repository. + +Note that some new packages may be exempt from the review process. Please see [https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/#_package_review_process the list of criteria]. If an exemption is warranted, the contributor can skip directly to step 9 of the process: filing a [[PackageDB_admin_requests|request]] in the package database. Note that the request to create a repo should include the --exception flag instead of a bug number: fedpkg request-repo --exception <package-name>. + +== Review Process == + +There are two roles in the review process, that of the contributor and that of the reviewer. In this document, we'll present both perspectives. + +=== Contributor === + +A Contributor is defined as someone who wants to submit (and maintain) a new package in Fedora. To become a contributor, you must follow the detailed instructions to [[Join the package collection maintainers]]. + +As a Contributor, you should have already made a package which adheres to the [[Packaging:NamingGuidelines| Package Naming Guidelines]] and [https://docs.fedoraproject.org/en-US/packaging-guidelines/ Packaging Guidelines]. There are also some packages that cannot be included in Fedora, to check if your package applies, check if it contains any [[Forbidden items]]. + +When you're happy with your spec file, you should then submit that SRPM to a package review. +Currently, this is done by following these steps: + +* Put your spec file and SRPM somewhere on the Internet where it can be directly downloaded (just HTTP(s), no registration pages or special download methods, please). If you have no place to put your spec and SRPM, use copr: [https://copr.fedorainfracloud.org/]. +* Fill out a [https://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Fedora&format=fedora-review request for review in bugzilla]. For guidance, a [[:Image:PackageReviewProcess_review.png|screenshot of a sample bugzilla request is available for review]]. Make absolutely certain to file this bug with an account tied to your FAS email address, otherwise your followup requests will be closed as invalid. +[[Image:PackageReviewProcess_review.png|right|x400px]] +* If you do not have any package already in Fedora, this means you need a sponsor and to add FE-NEEDSPONSOR (Bugzilla id:177841) to the bugs being blocked by your review request. For more information read the [[How to get sponsored into the packager group]] wiki page. +* Wait for someone to review your package! At this point in the process, the '''fedora-review''' flag is blank, meaning that no reviewer is assigned. + {{admon/tip|Review Swaps| If nobody comments on your review request, you might want to mail to a mailing list (for example, {{fplist|devel}}) asking for a "review swap". This is an offer to do a review of someone else's package in exchange for them reviewing your package. This is usually one-for-one, or can be some other private arrangement depending on the difficulty of the respective packages. }} +* There may be comments from people that are not formally reviewing the package, they may add NotReady to the Whiteboard field, indication that the review request is not yet ready, because of some issues they report. After you have addressed them, please post the URLs to the updated SPEC and SRPM file and remove it from the Whiteboard. It is expected that you will respond to commentary, including updating your submission to address it; if you do not, your ticket will be closed. +* A reviewer takes on the task of reviewing your package. They will set the '''fedora-review''' flag to '''?''' +* The reviewer will review your package. You should fix any blockers that the reviewer identifies. Once the reviewer is happy with the package, the '''fedora-review''' flag will be set to '''+''', indicating that the package has passed review. +* If you have not yet been sponsored, request sponsorship by raising an issue at https://pagure.io/packager-sponsors/. +* When your package pass the review, you should use the fedpkg tool to request a git repository for it. Before doing that you will need a [https://pagure.io/settings/token/new pagure_api_token] configured (one with "Create a new ticket" ACL) and added into ~/.config/rpkg/fedpkg.conf + [fedpkg.pagure] + token = generated-code +For example, if your bugzilla review ticket is 12345, use: fedpkg request-repo 12345. Check that your review bug is valid: it must have the '''fedora-review''' set to '''+''', and it must be assigned to your reviewer, otherwise your repository request will be closed as invalid. +* As following, if you want to add your package into more Fedora releases and not just Rawhide, let's say Fedora {{FedoraVersionNumber|current}}, you can use the following command to request additional branches: fedpkg request-branch --repo f{{FedoraVersionNumber|current}}. You must wait for your repository to be created before filing your branch request, otherwise your branch request will be closed as invalid. +* When this is complete (tickets in [https://pagure.io/releng/fedora-scm-requests/issues Pagure] for requests above are closed as processed), checkout the package: fedpkg clone +* Now you can [[Join_the_package_collection_maintainers#Import.2C_commit.2C_and_build_your_package|import your SRPM package]]. Do a final check of spec file tags, etc. +* Request a Koji build by running fedpkg build. (You will need to set up [[Infrastructure/Kerberos|Kerberos for Fedora project]]) +* Repeat the process for other branches you may have requested above: +** Checkout given branch: fedpkg switch-branch f{{FedoraVersionNumber|current}} +** Lets Koji build the package for this branch: fedpkg build +* Request updates for Fedora release branches, if necessary, using fedpkg update or another Bodhi interface as detailed in [[Bodhi]]. +* If possible, add your package to [[Upstream_release_monitoring|Upstream Release Monitoring]]. +* To be notified if your package stops building successfully when dependencies are updated in Fedora, you can enable [[Koschei]]. +* You should make sure the review ticket is closed. You are welcome to close it once the package has been built on the requested branches, or if you built for one of the Fedora release branches you can ask Bodhi to close the ticket for you when it completes the process. If you close the ticket yourself, use '''NEXTRELEASE''' as the resolution. + +You do not need to go through the review process again for subsequent package changes, and should not reference the review ticket in subsequent updates you create in Bodhi. + +=== Reviewer === + +The Reviewer is the person who chooses to review a package. + +{{admon/note|fedora-review tool| +fedora-review is a very useful tool for handling some grunt work in the review process and it is highly recommended that you take advantage of it. dnf install fedora-review and refer to the man page for more details. Note, however that it is not a replacement for human input and you still need to understand the [https://docs.fedoraproject.org/en-US/packaging-guidelines/ Packaging Guidelines] thoroughly.}} + +{{admon/note|Comments by other people| +Other people are encouraged to comment on the review request as well. Especially people searching for sponsorship should comment other review requests to show, that they know the [https://docs.fedoraproject.org/en-US/packaging-guidelines/ Packaging Guidelines].}} + +The Reviewer can be any Fedora account holder who is a member of the [https://admin.fedoraproject.org/accounts/group/members/packager/* packager group]. (If the Contributor is not yet sponsored, the review can still proceed to completion but they will need to find a sponsor at some point.) + +* Search for a review request that needs a reviewer: http://fedoraproject.org/PackageReviewStatus/ ('''fedora-review''' flag is blank or the bug is assigned to nobody@fedoraproject.org) +* If you notice some issues that need to be solved before you want to start a formal review, add these issues in a comment and set the Whiteboard of the bug to contain NotReady. This helps other possible reviewers to notice that the review request is not yet ready for further review action. +* if you want to formally review the package, set the '''fedora-review''' flag to '''?''' and assign the bug to yourself. +{{admon/note|Stepping back from a Review|If you want to step back from the review for any reason, reset the '''fedora-review''' flag to be blank '''and''' reassign the bug to the default owner of the component, which is '''nobody@fedoraproject.org'''}} +* Review the package ... +** Go through the MUST items listed in [[Packaging:ReviewGuidelines| Review Guidelines]] . +** Go through the SHOULD items in [[Packaging:ReviewGuidelines| Review Guidelines]] . +** The [https://fedorahosted.org/FedoraReview/ FedoraReview] tool (packaged as fedora-review) can help to automate this process. +* Include the text of your review in a comment in the ticket. For easy readability, simply use a regular comment instead of an attachment. +* Take one of the following actions: +** '''ACCEPT''' - If the package is good, set the '''fedora-review''' flag to '''+''' +{{admon/question|Time to sponsor?|If the Reviewer is also acting as Sponsor for the Contributor, then this is the time to sponsor the Contributor in the [https://admin.fedoraproject.org/accounts/ account system]}} +** '''FAIL, LEGAL''' - If the package is legally risky for whatever reason (known patent or copyright infringement, trademark concerns) close the bug WONTFIX and leave an appropriate comment (i.e. we don't ship mp3, so stop submitting it). Set the '''fedora-review''' flag to '''-''', and have the review ticket block FE-Legal. +** '''FAIL, OTHER''' - If the package is just way off or unsuitable for some other reason, and there is no simple fix, then close the bug WONTFIX and leave an appropriate comment (i.e. we don't package pornography for redistribution, sorry. Or, this isn't a specfile, it's a McDonald's menu, sorry.) Set the '''fedora-review''' flag to '''-'''. +** '''NEEDSWORK''' - Anything that isn't explicitly failed should be left open while the submitter and reviewer work together to fix any potential issues. Mark the bug as NEEDINFO while waiting for the reviewer to respond to improvement requests; this makes it easier for reviewers to find open reviews which require their input. +* Once a package is flagged as '''fedora-review +''' (or '''-'''), the Reviewer's job is done although they may be called upon to assist the Contributor with the import/build/update process and to ensure that the Contributor closes the ticket out when the process is complete. + +== Definitions for fedora-review Flag Settings == +{| border="1" +|- +|fedora-review||(BLANK)||Package Needs Review +|- +|fedora-review||?||Package Under Review +|- +|fedora-review||-||Package Failed Review, dropped for legal or other issues. +|- +|fedora-review||+||Package Approved +|} + +== Special blocker tickets == +There are a few tickets which can be placed in the "Blocks" field to indicate specific ticket statuses: +{| border="1" +|- +|FE-NEEDSPONSOR||The submitter requires a sponsor; the review can be done by anyone, but a sponsor will need to come and sponsor the submittor. +|- +|FE-DEADREVIEW||The review has been closed out because the submitter has left; users looking for packages to submit may find some possibilities in these dead tickets. +|- +|FE-Legal||The package is currently awaiting review by the legal team. +|} + +== The Whiteboard == +To save time for reviewers, the page at https://fedoraproject.org/PackageReviewStatus/reviewable.html will hide certain tickets which are not reviewable. The Whiteboard field can be used to mark a ticket with various additional bits of status which will cause it to be hidden or displayed differently. + +{| border="1" +|- +|NotReady||The package is not yet ready for review. It is possible to open a review ticket, mark it as NotReady, and continue to work on it until it's ready to be seen by a reviewer. +|- +|BuildFails||The package fails to build. +|- +|AwaitingSubmitter||The package review is stalled and cannot proceed without input from the submitter. +|- +|Trivial||The package is trivial to review. See below. +|} + +The "Trivial" status is intended to indicate packages which, as an aid to new reviewers, are especially uncomplicated and easy to review. A ticket should not be marked as being trivial unless: +* The package is known to build and a link to a scratch build is included. +* The ticket explains any rpmlint output which is present. +* The spec contains nothing which is unnecessary in modern Fedora (such as BuildRoot:, a %clean section or %defattr). +* The spec is free from excessive or complicated macro usage. +* The spec uses only the least complicated scriptlets which are taken directly from the [[Packaging:Scriptlets]] page. +* The package contains no daemons. +* The package is not especially security sensitive. +* The code has undergone a thorough inspection for licensing issues. Anomalies which would be found by licensecheck should be explained. +In short, this should be reserved only for those tickets which should be easily approachable by someone doing their first package review. + +== Tracking of Package Requests == + +The [http://fedoraproject.org/PackageReviewStatus cached Package Review Tracker] provides various review-related reports and a simple way to search for reviews by package name or reporter name or others. + +== Authorship == +This document was originally authored by [[TomCallaway|Tom 'spot' Callaway]] in 2007 and has since been modified by many others. + +[[Category:Package Maintainers]] diff --git a/modules/ROOT/pages/wiki/Package_Update_HOWTO.wiki b/modules/ROOT/pages/wiki/Package_Update_HOWTO.wiki new file mode 100644 index 0000000..8b5c012 --- /dev/null +++ b/modules/ROOT/pages/wiki/Package_Update_HOWTO.wiki @@ -0,0 +1,241 @@ +{{autolang|base=yes}} + +This document shows how to submit an update for a package you maintain in Fedora. It assumes you already have a package in the Fedora repositories. It is not a guide to using the Fedora package source control system: see the [[Package maintenance guide]] for that. + +* For details of the policy on requirements for updates at various stages of the [[Fedora Release Life Cycle]], refer to the [https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ Updates Policy]. + +== Overview == + +This page is intended for new and existing package maintainers. Testers and regular users may be interested in the [[QA:Updates_Testing|updates-testing]] repository and the [[QA:Update_feedback_guidelines|update feedback guidelines]]. This page specifically covers the update submission process. + +There are two significantly different package update submission workflows in Fedora: + +* [[Releases/Rawhide|Rawhide]], and [[Releases/Branched|Branched]] up to the [https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#bodhi-enabling Bodhi enabling point] +* [[Releases/Branched|Branched]] releases after the Alpha change deadline, and stable releases + +The repository layouts differ somewhat for Rawhide, Branched and stable releases, but the update workflows split up as described above. + +== Rawhide and early Branched == + +=== Single Packages === + +The update workflow for single package builds in Rawhide and Branched before the ''Bodhi enabling point'' is simple: + +# Build the package with {{command|fedpkg build}} (see the [[Package maintenance guide]] for more details) + +This is all you need to do, a Bodhi update will be created automatically, from which potential tests will be run. + +* If the built package doesn't have tests, or if they succeed, the update will be marked as ''stable'' and your package will appear in subsequently created build roots, as well as in the next daily compose of Rawhide or Branched and will be used in any image composes built from that tree. + +* If the built package has tests which fail, this will be recorded in the update. You can now either [[#Waive_a_result|waive the failing tests]] if you're sure that the test shouldn't fail, or fix whatever is wrong with the package, build it again, which in turn will create an update, running the tests (on the now hopefully fixed package), and so forth. + +=== Multiple Packages === + +Some updates require changes in multiple related packages, e.g. if a library is upgraded to a new major version and packages using it need to be rebuilt. + +Fedora has the concept of using side-tags for these situations, which means the builds are done "on the side" and do not affect packages out of the side-tag, nor are they available for installing until the side-tag is merged. Packagers can create side-tags on their own, allowing them to build disruptive components in isolation and submit the builds in a side-tag as one update in Bodhi, to be tested and subsequently merged into the main distribution. + +==== Creating a side-tag ==== + +To create a side-tag for building packages for Rawhide, the easiest way is to be in the checked out rawhide branch of one of the packages and issue the following command: + + fedpkg request-side-tag + +Alternatively, you can specify the parent/base tag from which to create the side-tag, e.g.: + + fedpkg request-side-tag --base-tag f32-build + +{{admon/note|Parent/Base Tags| + +Side-tags for particular Fedora releases are based off its respective build tag. I.e. if you wanted to create a side-tag for Rawhide while it's ramping up for Fedora 32, the parent tag to choose would be f32-build. + +}} + +This will tell you the commands to 1) build a package in the specific side-tag and 2) wait for the respective build root to be recreated, e.g.: + + $ fedpkg request-side-tag --base-tag f32-build + Side tag 'f32-build-side-7863' (id 7863) created. + Use 'fedpkg build --target=f32-build-side-7863' to use it. + Use 'koji wait-repo f32-build-side-7863' to wait for the build repo to be generated. + $ + +The latter is important if any builds depend on previous ones in the side-tag. Use `koji wait-repo --build ` to ensure that the respective build is available in the build root for subsequent builds. + +==== Bodhi update for builds in a side-tag ==== + +When you're done building all packages you want in a side-tag, you have to submit them as an update to Bodhi before they can be made available generally to be installed and built upon. + + +In the "Create New Update" form in Bodhi, choose the "Use Side-Tag" drop-down to create an update from the latest package builds in the respective tag: + +[[File:Bodhi-builds-from-side-tag.png]] + +As with single packages, tests will be run whose result affects if the update can be moved to stable. The difference is that tests have to succeed (or be waived) for all builds in the update. If you have to update the list of builds, e.g. to fix problems found during testing, edit the update and refresh the list of builds using the 🔃 (refresh) button: + +[[File:Bodhi-builds-refresh-from-side-tag.png]] + +The web interface only works if you are the creator of the side-tag. If you are a proven packager submitting an update for a side-tag, you currently need to use the bodhi cli: + + $ bodhi updates new --from-tag --notes "whatever" --user + +{{admon/note|Adding/Removing builds to/from a side-tag| + +As a packager you can add or remove builds from your side-tag, this can be achieved using these commands: + + $ koji tag + $ koji untag + +This can be used to remove a build that made a test fail or to add a build that was originally missed. If you add or remove a build from a side-tag, you will have to refresh the corresponding update in bodhi. +}} + +Once the update moves to stable, the builds will be tagged to the main tag of the release, i.e. are available for the general public. + +== Later Branched and stable releases == + +At the [https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#bodhi-enabling Bodhi enabling point], the [[Bodhi]] update feedback system is enabled by [[ReleaseEngineering|Release Engineering]] and builds submitted with {{command|fedpkg build}} are no longer automatically sent to any official [[Repositories|repository]]. The update workflow for releases of this type is: + +{{admon/tip|Fedora account name|{{command|fedpkg}} should be able to discover your [[Account_System|Fedora account system]] user name from the {{filename|~/.fedora.cert}} file set up by {{command|fedora-packager-setup}} when you first [[Join_the_package_collection_maintainers#Install_the_client_tools_.28Koji.29_and_set_up_your_certificate|configured your system for packaging]]. If this fails for any reason, you can specify it with {{command|--user (username)}}. For the {{command|bodhi}} command line tool, you may need to specify your Fedora user name with {{command|--user (username)}} if it differs from your system user name.}} + +# Build the package with {{command|fedpkg build}} +# Submit an update for the package with {{command|fedpkg update}}, the [https://admin.fedoraproject.org/updates/ Bodhi web interface], or the [https://fedorahosted.org/bodhi/wiki/CLI Bodhi CLI tool]. This causes the package to be sent to the [[Repositories#updates-testing|''updates-testing'']] repository +# Monitor the update's status and the feedback you receive via the web interface or the emails that are sent to you, and modify it with updated or additional builds if necessary +# After the update meets the criteria in the [https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ Updates Policy] and you are satisfied it should be released as a stable update, submit the update to ''[[Repositories#stable|stable]]'' with {{command|bodhi updates request stable}} or the web interface + +{{admon/important|Updating inter-dependent packages|If a package you wish to update requires other package(s) to be rebuilt before it or they will work properly, you '''must''' submit the builds together as a multi-package update. See [[#multi|below]] for more details on this.}} + +=== Update attributes === + +At the time you submit the update, you will be asked for several attributes. The type of the update should be fairly self-explanatory: either it fixes bugs, adds new features, or is a new package. + +If you are asked whether you want to send the update to ''updates-testing'' or ''stable'', this is a no-op: all updates now go through ''updates-testing''. It does not matter what you choose. + +There are several schools of thought on filling out the update description. Some would suggest you consider the target audience: for a stable release, in particular, many Fedora users will see this text, and many of them may not be particularly familiar with your package. Consider not simply describing literally the changes in the update, but explaining as if to an outsider why your are updating the package, what benefits it will bring to them (if any), and anything they may want to note in order to have a smooth update experience. + +If you associate one or more bug reports with your update, Bodhi will post comments into Bugzilla to alert those following the bug reports that an update is available. If you mark your update as fixing the bug(s), Bodhi will move the report(s) through the '''MODIFIED''', '''ON_QA''' and '''CLOSED ERRATA''' states of the [[BugZappers/BugStatusWorkFlow|bug workflow]] as your update reaches various points in the process. Using this mechanism can be very useful both for you and for users of your package. + +You may set a ''karma'' (feedback) level at which the update will automatically be submitted to ''stable''. This is optional. If you choose to use it, please carefully consider an appropriate feedback level. For a relatively obscure package which is quite stable, 1 or 2 may be an appropriate value. For a popular, sensitive and complex package such as {{package|firefox}} or the {{package|kernel}}, the default of 3 may be insufficient and a choice of 5 or even 10 may be appropriate. + +=== Who will receive your update, when? === + +When a release is in Branched state, the ''updates-testing'' repository is enabled by default so most users will see the package, but only packages from the stable ''fedora'' repository are used in building milestone releases (Alpha, Beta and Final) and nightly images. + +Where a package goes when it is marked as ''stable'' differs between Branched and stable releases. In Branched releases, ''stable'' packages are pushed to the base ''fedora'' repository. In stable releases, ''stable'' packages are pushed to the ''updates'' repository. However, from the point of view of the packager, this is an insignificant implementation detail. For more details, see [[Repositories]]. + +When a release is in stable state, the ''updates-testing'' repository is disabled by default, but [[QA]] team members and others run with it enabled in order to provide testing and Bodhi feedback. The main user population will see your update only when it passes Bodhi, is marked as ''stable'' and reaches the ''updates'' repository. + +{{anchor|multi}} +=== Updating inter-dependent packages === + +If an update you wish to submit would cause a dependency issue of any kind (a strict package dependency error, or simply another package failing to operate correctly) if updated alone, you must not submit the package as a single-package update. You must always collect all inter-dependent or related packages together into a single multi-package update, such that no user will face problems if they install all the packages in the update together. + +For example: if you maintain a package ''libfoo'' which the package ''bar'' depends on, and you need to update ''libfoo'', you should check that ''bar'' continues to function correctly with the updated version of ''libfoo''. If it does not, you must ensure the appropriate changes are made to ''bar'', and include the updated ''bar'' in your update along with the updated ''libfoo''. + +The ''fedpkg'' tool does not handle multi-package updates. You can add multiple packages to an update using the [https://bodhi.fedoraproject.org/updates/new Bodhi web application], or the {{command|bodhi}} command line tool. You can pass as many package names as you like to the {{command|bodhi updates new}} to create a new multi-package update, or use {{command|bodhi updates edit}} to edit an existing update. + +It is possible you will run into problems with permissions when trying to add builds of packages you do not have commit privileges for to an update, or trying to add a build for a package you do have privileges for to someone else's update. If you encounter a situation like this, you should contact the [[ReleaseEngineering|release engineering]] team or a proven packager for help. + +You may need a ''buildroot override'' to complete a multi-package update successfully. For instance in the case described above, you may need to rebuild ''bar'' against the new ''libfoo'' package and submit both packages together as a multi-package update. However, in the normal course of events, you would not be able to build another package against your new ''libfoo'' build until it reached the [[Repositories#stable|''stable'']] state. To resolve this dilemma, you can request a buildroot override, which causes the ''libfoo'' build to be included in the buildroot for a short time in order to get the ''bar'' package build done. + +You can request a buildroot override with bodhi: {{command|bodhi overrides save (name-version-release) --duration 2 --notes "Useful details."}} This would submit a buildroot override with a duration of two days. Buildroot overrides are usually granted within 15-30 minutes of submission. If you submit an override request with the bodhi tool, it will suggest a command that will let you monitor when the package appears in the buildroot, so you can fire your dependent build at the appropriate time. + +You can also request buildroot overrides from the [https://bodhi.fedoraproject.org/overrides/new Bodhi web application]. + +The [[Bodhi/BuildRootOverrides|buildroot override instructions]] explain the buildroot override process in more detail. + +=== Handling feedback from automated tests === + +Fedora's automated testing systems, [[Taskotron]] and [[OpenQA]], may run automated tests on your update. Several of the [[Taskotron/Tasks]] are documented. The openQA tests are functional tests of some critical [[Workstation]] and [[Server]] features. + +In the Bodhi web interface, updates have a ''Automated Tests'' tab which displays the results of all automated tests. Tests shown with a red background failed. The tests are not all 100% accurate, but they are fairly often correct. If you see a failure, it is a very good idea to click on the result (which will take you to a detailed log) and investigate the issue. If you are unsure what the test indicates, you can contact the [[QA]] team for help. + +==== Waive a result ==== + +At present, a failure of the ''dist.rpmdeplint'', ''dist.abicheck'', or ''org.centos.prod.ci.pipeline.complete'' tests will prevent your update from being released. On the update's ''Details'' page in the Bodhi web interface, the '''Test Gating Status''' will be shown as ''N of N required tests failed''. If you are sure such a failure is a false one, you can 'waive' the result using the {{code|waiverdb-cli}} tool, from the {{package|waiverdb-cli}} package (there is [https://github.com/fedora-infra/bodhi/pull/2095 work pending] to be able to waiver more easily, directly from the Bodhi UI). + +You can submit a waiver for a failing result with {{pkg|waiverdb-cli}} specifying the {{code|subject}} and the {{code|testcase}}: + + waiverdb-cli -t YOUR_TESTCASE_HERE -s '{"item": "this-is-the-subject", "type": "also-this-is-part-of-the-subject"}' -p "fedora-26" -c "This is fine" + +Example: + + waiverdb-cli -t dist.rpmdeplint -s '{"item": "python-requests-1.2.3-1.fc26", "type": "koji_build"}' -p "fedora-26" -c "This is fine" + +You can also waive a failing result by result's id, which you can retrieve from resultsdb with curl. To do that, you'll need the {{code|testcase}} name and the {{code|nvr}}. For example: + + curl "https://taskotron.fedoraproject.org/resultsdb_api/api/v2.0/results?testcases=dist.python-versions&item=python-alembic-0.9.7-1.fc27" | jq ".data[0].id" + +This should print out the {{code|result_id}} of the failing result. You can then submit a waiver for this failing result with {{pkg|waiverdb-cli}} + + waiverdb-cli -p fedora-27 -r YOUR_ID_HERE -c "This is fine." + +Also, if you enabled automatic stable push at a karma threshold, this will be disabled if any automated test fails. If you have examined the result and you are sure it is a false one and there is no problem with the package, you may re-enable the automatic push mechanism or submit the package to ''stable'' manually once it meets the other requirements of the [https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ Updates Policy]. + +==== Waive the absence of a result ==== + +Submitting a waiver using subject/testcase allows to waive the absence of a result (eg. the test never ran for some reason, so there is no result item). + +If which testcase you should be specified it is not clear/known, it is possible to run this python script, chainging it with the corrects parameter: + + #!/usr/bin/env python + """ Ask a question of greenwave. """ + # Usage: either modify and set PRODUCT_VERSION and NVR_LIST and run, or pass version as first arg and then NVRs as further args + import pprint + import requests + import sys + PRODUCT_VERSION = 'fedora-27' if len(sys.argv) == 1 else sys.argv[1] + NVR_LIST = [] or sys.argv[2:] # Insert your NVRs here, or pass them via command line args + for nvr in NVR_LIST: + url = ( + 'https://greenwave-web-greenwave.app.os.fedoraproject.org/' + 'api/v1.0/decision') + payload = dict( + #verbose=True, + decision_context='bodhi_update_push_stable', + product_version=PRODUCT_VERSION, + subject=[{'item': nvr, 'type': 'koji_build'}], + ) + response = requests.post(url, json=payload) + print("-" * 40) + print(nvr, response, response.status_code) + data = response.json() + print(pprint.pformat(data)) + +The output will show that Greenwave is requiring a specific testcase to run, but it cannot find a result for it (neither pass nor failure). So now it is possible to submit a waiver with the specified testcase in the output and the subject already known. + +==== Troubleshooting ==== + +If you run the {{code|waiverdb-cli}} tool and it gives you the following error: + + Error: The config option "resultsdb_api_url" is required + +Edit {{code|/etc/waiverdb/client.conf}} and add the following line: + + resultsdb_api_url=https://taskotron.fedoraproject.org/resultsdb_api/api/v2.0 + +=== Branched milestone freezes === + +For a short period before each milestone release, the stable [[Repositories#fedora|''fedora'']] repository is frozen. These periods are shown as the [[Milestone freezes]] (Beta Freeze, Final Freeze) on schedules. During these periods, builds will not be marked ''stable'' and pushed from [[Repositories#updates-testing|''updates-testing'']] to ''fedora'' even after being submitted manually or automatically. In the normal course of events, they will be pushed after the milestone release is approved at a [[Go_No_Go_Meeting]]. If you believe your update deserves to break a milestone freeze, a ''freeze exception'' may be granted through the [[QA:SOP_freeze_exception_bug_process|freeze exception process]]. Accepted release blocking bugs are granted the same status through the [[QA:SOP_blocker_bug_process|blocker bug process]]. + +For more on the Fedora development process, see [[Fedora Release Life Cycle]]. + +{{admon/tip| +If you are unsure whether your build is currently considered ''stable'' for a given release, you can check with {{command|koji latest-pkg fXX}} (where XX is the release).}} + +== Security updates == + +There is an additional process that layers over the regular update process for bugs identified as security issues. If a bug is assigned to you that blocks a [[Security Tracking Bugs|security tracking bug]], you must follow that process in addition to this one. + +== New package submissions == + +If you want to build a new package, but you aren't sure which releases to send it to: + +* New packages should always be built for Rawhide +* New packages can be built for Branched and stable releases if adding them would provide value to users of those releases without significant risk of causing harm + +The submission process for new packages, after they have passed the [[Package_Review_Process]] and been [[Package_SCM_admin_requests|given an SCM repository]], is exactly the same as that for package updates. + +== Consider creating a package test plan == + +If you [[QA:SOP_test_case_creation|create test cases]] for your package, and [[QA:SOP_package_test_plan_creation|categorize them appropriately]], they will be automatically linked in Bodhi, so that testers will have some guidance for planned update testing. + +[[Category:Package Maintainers]] diff --git a/modules/ROOT/pages/wiki/Policy_for_Stalled_Package_Reviews.wiki b/modules/ROOT/pages/wiki/Policy_for_Stalled_Package_Reviews.wiki new file mode 100644 index 0000000..9823524 --- /dev/null +++ b/modules/ROOT/pages/wiki/Policy_for_Stalled_Package_Reviews.wiki @@ -0,0 +1,31 @@ + + += Policy for dealing with stalled package reviews = + +Occasionally package reviews fail to make forward progress due to lack of response from one of the parties involved in the review. This policy addresses two classes of reviews: those stalled because the review submitter is not responding, and those which have been assigned to a reviewer and are stalled because that reviewer is not responding. The idea is to move the ticket to a state where other interested parties can submit the package or take over the review. Of course there is no intent to punish anyone, and tickets can always be assigned back to the same reviewier or reopened. + +== Digest == + + + + +=== Reviewer not responding === +* When a review ticket is assigned to a reviewer who does not respond to comments for one month, a comment is added to the ticket indicating that the review is stalled and that a response is needed soon. +* If there is no response within one week, the ''fedora‑review'' flag is set to the empty value. The ticket is reassigned to nobody@fedoraproject.org (use the ''Reassign bug to owner and QA contact of selected component'' radio button for this) with the intention to move the ticket back to a state where another reviewer can work on it. +=== Submitter not responding === +* When the submitter of a review ticket has not responded to comments for one month, a comment is added to the ticket indicating that the review is stalled and that a response is needed soon. +* If there is no response within one week, the ticket is closed with resolution NOTABUG, and the ''fedora-review'' flag is set to the empty value. +* The bug may be set as blocking [https://bugzilla.redhat.com/show_bug.cgi?id=FE-DEADREVIEW FE-DEADREVIEW]. The intention is to close the bug so that it can be submitted by someone else in a separate bug, and also to make it easy to find bugs closed in this way. + +If the bug is resubmitted by someone else, it is also reasonable to change the resolution on the closed bug to DUPLICATE and mark it as a duplicate of the new bug so that reviewers of the new ticket can easily find the work that was done on the old one. + + + + +{{Anchor|afterinclude}} + +[[Category:Package Maintainers]] diff --git a/modules/ROOT/pages/wiki/Staying_Close_to_Upstream_Projects.wiki b/modules/ROOT/pages/wiki/Staying_Close_to_Upstream_Projects.wiki new file mode 100644 index 0000000..c278c14 --- /dev/null +++ b/modules/ROOT/pages/wiki/Staying_Close_to_Upstream_Projects.wiki @@ -0,0 +1,94 @@ +{{autolang|base=yes}} + +{{Admon/note |This document is maintained by [[User:Sundaram | Rahul Sundaram]]. Feel free to edit the wiki or contact the maintainer for any kind of feedback.}} + +The Fedora Project focuses, as much as possible, on not deviating from upstream in the software it includes in the repository. The following guidelines are a general set of best practices, and provide reasons why this is a good idea, tips for sending your patches upstream, and potential exceptions Fedora might make. The primary goal is to share the benefits of a common codebase for end users and developers while simultaneously reducing unnecessary maintenance efforts. + +; upstream (noun): In free and open source projects, the ''upstream'' of a program or set of programs is the project that develops those programs. Fedora is ''downstream'' of those projects. This term comes from the idea that water and the goods it carries float downstream and benefit those who are there to receive it. + +; to upstream (verb): A short-hand way of saying "push changes to the upstream project". + +== What are deviations from upstream? == + +; Patches: Patches are the most common and obvious type of change from upstream. Patches might be written by the package maintainer, cherry picked or backported from upstream or picked from other distributions. + +; Running sed or equivalent on a spec file: While this change is less obvious, it should be considered functionally equivalent to a patch for the purposes of this guide. Also a patch is preferable because running sed can sometimes change the software in unintended ways especially when the package maintainer is pushing a new upstream release as an update and such changes might not be obvious compared to a failed patch. + +; Additional sources: Desktop files, systemd unit files, etc. are sometimes added as additional sources. If you do this as a package maintainer, you need to notify upstream and ideally get them included as part of the upstream source. Maintaining them separately often involves additional maintenance from time to time. + +; Configuration options: For instance, if a particular upstream software allows both MySQL and Postgres as a database backend, other distributions might have picked Postgres and Fedora package of that upstream software might be configured to use the MySQL backend by default instead. If upstream or other distributions are favoring one of the options over the others, talk to them, find out why and rely on well tested and consistent options as much as possible. + +; Underlying libraries and other software components: Even without intentional modifications, software in Fedora can still be different from upstream or other distributions, due to precise library versions or other software components your package depends on. For instance, Firefox may expose a sqlite bug, and Fedora might be the only distribution building that precise version of Firefox against that specific version of sqlite. You should talk to upstream and find out whether there are any such known issues, and search through upstream bug trackers or other popular distribution bug trackers to figure out such problems. + +; Miscellaneous: The above list is not comprehensive. Even seemingly minor changes like the specific desktop theme or fonts can exhibit bugs in other software, or can expose a bug in the theme or font but only with some specific software. For instance, LibreOffice might have a problem displaying a list when using the Adwaita theme and Dejavu font. When analyzing issues, make sure you consider the impact of every change either in Fedora or by users themselves. + +== Why push changes upstream? == + +* '''Common Benefit And Reduced Maintenance Burden''' - When Fedora carries patches that are specific to Fedora or deviations from upstream projects, those patches are not shared by every distribution. This puts the burden of maintaining those patches on Fedora, which includes keeping those patches in a functional state by rewriting or forward-porting them for every upstream release. This effort can quickly add up to be overwhelming, while not being in the spirit of sharing the benefits (as well as the effort in maintaining) free and open source software. + +* '''Documentation''' - Upstream projects are documented formally (in the form of man/info pages and longer guides) and informally in many user forums or mailing lists as answers to user questions. Deviations from upstream projects can thus confuse end users and upstream developers when those patches cause changes in behavior that are Fedora specific and not documented properly, even where the formal documentation (such as man pages) are also patched to describe the changes. + +* '''Translations''' - Maintaining translations upstream gains the advantage of established translation communities, which are most likely more experienced with the project terms. Downstream projects benefit when using those translations. In addition, it lifts the burden of hosting, and of the need to merge often from upstream to downstream and back again. To make sure translation work continues upstream. Any string changes that were introduced by patches should be maintained by the downstream community. + +* '''Upstream Acceptance''' - Fedora is downstream of many thousands of software projects. Much of this software is packaged by maintainers who are not programmers or lack expertise in the language(s) the software is written in. In some cases the software has a large and complex codebase (such as the kernel or Libreoffice) and the package maintainers might not have the level of understanding in all areas compared to subsystem maintainers or upstream developers. For this and other reasons, Fedora needs the acceptance of upstream software developers. These developers may view any significant patches as a fork or refuse to take bug reports from Fedora users due to the differences in the codebase. Fedora as a project strives to be welcoming and cooperative with upstream developers as much as possible. We must avoid Fedora specific patches and any patches that are useful should be sent upstream to these developers via mailing lists, bug trackers, or direct email. + +* '''Quality Assurance''' - Patches that are accepted upstream are usually reviewed or tested by many people including developers and testers. This includes testing by other GNU/Linux distributions. A deviation from the common codebase used by many is a potential chance of introducing a regression that is specific to Fedora. + +* '''Security''' - A special case of the "Quality Assurance" issue is that changes that have surprising security implications are more likely to be detected by upstream (who often have deeper knowledge of the program). + +* '''Fast incremental improvements''' - Staying close to upstream versions is helpful when doing version bumps for updates that bring in new features. This prevents tedious backporting of only security and bug fixes. Deviations from upstream can significantly hamper the speed of delivering improvements from new versions to end users. However, regressions are to be avoided, and potential improvements and new features must be carefully assessed against the risk of harming the users experience. Refer to our [[Updates_Policy]] for more details. + +* '''ABI or API Deviations''' - Patches that introduce a new application binary interface (ABI) or application program interface (API) must be especially avoided, even if the ABI/API changes are planned to land upstream. When these patches get upstream (if ever), upstream developers might introduce changes in the ABI/API during the code review process before merging the code. This could break other software in the repository that makes use of the Fedora-patched ABI/API. + +* '''Direct End User Feedback''' - When users run into problems with any software that is in Fedora, they can report the problems directly upstream. By not deviating from upstream, it remains a central location for all bug reports on that software, leaving Fedora package maintainers to concentrate on good packaging instead of acting in between users and upstream issues. + +== Tips On Upstreaming Patches == + +* Talk to upstream: Maintaining a regular flow of communication with the upstream project is helpful in understanding the upstream developers well, and encourages them to be more responsive to your requests. It also helps in understanding technical issues, such as how they prefer patches to be submitted. + +* Make the patches generic enough to be maintained by upstream developers. Explain the need for your patches, that is, what bugs they fix or what features they add. Any references to bugzilla reports or user requests can be quite useful for the developers who receive your patches. + +* Don't consider any changes too small to be sent upstream. Even minor changes like fixing a permission problem in a file or excluding an empty file can and should be reported upstream even if upstream does not necessarily act on all of them quickly. + +* Divide patches into small and independent chunks that remain functional, so they can be understood, reviewed, and accepted or rejected individually. + +* If the patch introduces new strings or changes existing ones, make the changes as generic as possible. + +* Fix your coding style to match the upstream project's guidelines. This might seem trivial but many upstream projects insist on following their guidelines so that their codebase looks internally self consistent and is more maintainable. + +* Where possible, encourage upstream point-releases that fix bugs and security issues only, to avoid the possibility of regressions. + +* Test your changes as throughly as you can before you send them upstream. Broken patches leave a long-lasting bad impression. + +* Be patient and cooperative. If feedback is offered, discuss changes, answer questions, and provide revisions that fix any problems. Don't flame or argue unnecessarily with upstream developers. The overall goal is persuade upstream developers to get your patches committed upstream and not to demonstrate "who is better." Don't forget the human element in these conversations. If necessary, we will have to carry some patches downstream to enforce our policies even if upstream does not agree with us at that point. + +== Some Examples Of Exceptions == + +* '''Severe Security Issues Or Major Bug Fixes''' - For any major issues such as security holes or data loss problems, waiting on a new release from upstream for a fix can be too much of a delay. In these instances, it may be better to backport those fixes from upstream or fix the issue by writing your own patch and do an update in Fedora. If you are writing a new patch, send it upstream so that Fedora shares the benefits and avoid deviations in new releases that follow. Be careful when expeding the patching however. A security patch that is not comprehensive can leave unexpected security holes still open or a patch to fix a major problem can worsen the problem. Get your patches peer reviewed as much as possible. Due to differences in release schedules between upstream projects and Fedora releases, maintainers would have to keep in mind feature and development freezes in Fedora and fix problems accordingly. + +* ''' Non-free or patent encumbered software''' - If upstream projects include software that is non-free or has known patent issues, such software does not meet the Fedora [[Packaging:LicensingGuidelines| licensing guidelines]] and Fedora will not include them. In many instances, such code is optional in the form of plugins that Fedora simply does not need to include in its software repository. In other cases, it might be possible to work with upstream on making it optional or patch specific portions. + +* '''Unmaintained Or Unresponsive Upstream Projects''' - In cases where upstream projects are either unmaintained or unresponsive, it might be acceptable to patch the software. If upstream is unmaintained, you might want to consider sharing patches with other distributions or taking over maintenance if you have the time, skills, and interest. Be wary of maintaining software with no upstream since all the burden of maintaining the codebase as well as packaging issues are with you. If upstream is unresponsive and many distributions are deviating significantly, it might be a opportunity for a cross distribution fork (Similar to XFree86 and Xorg). + +* '''Patches Heading Upstream''' - Any patches that are known to be headed upstream ''might'' be patched temporarily in Fedora if the patches provide important bug fixes or in rare cases, features to users. If this is done, maintenance effort of the patches should be low impact for the small amount of time until upstream merges the patches and does a new release. + +* '''Distribution Integration''' - There are features that are critical or very good to have for Fedora as a distribution but not been significant enough for various upstream projects to accept related enhancements just yet. Use your discretion carefully when choosing to integrate any such patches since there is a trade off between upstream acceptance and Fedora integration and associated costs/benefits. + +* '''Bundling of Libraries''' - Refer to the packaging guidelines related to bundling [[Packaging:No_Bundled_Libraries|here]] for details. Fixes related to bundling should of course be sent upstream if possible. + +== References == + +* http://fedoraproject.org/wiki/Objectives +* https://fedoraproject.org/wiki/Packaging/Guidelines#All_patches_should_have_an_upstream_bug_link_or_comment +* http://fedoraproject.org/wiki/PackageMaintainers/TrackingUpstream +* http://fedoraproject.org/wiki/PackageMaintainers/TrackingDownstream +* https://www.redhat.com/archives/fedora-devel-announce/2007-September/msg00019.html - No more separate kernel module packages. +* http://kernelslacker.livejournal.com/85039.html Dave Jones, Fedora kernel co-maintainer on Fedora kernel patches +* http://fedoraproject.org/wiki/Extras/GetKernelModulesUpstream +* http://kernelnewbies.org/UpstreamMerge +* http://www.kroah.com/linux/talks/ols_2002_kernel_codingstyle_talk/html/ +* http://umeet.uninet.edu/umeet2002/talk/2002-12-11/linux1.txt.html +* http://kernelnewbies.org/New_Kernel_Hacking_HOWTO/Kernel_Programming_Style_Guidelines + + +[[Category:Package Maintainers]] diff --git a/modules/ROOT/pages/wiki/Upstream_Release_Monitoring.wiki b/modules/ROOT/pages/wiki/Upstream_Release_Monitoring.wiki new file mode 100644 index 0000000..3170e66 --- /dev/null +++ b/modules/ROOT/pages/wiki/Upstream_Release_Monitoring.wiki @@ -0,0 +1,87 @@ +{{autolang|base=yes}} + += Upstream Release Monitoring = + +== TLDR; Get Packages Monitored == + +Get bug reports for a project's releases in Fedora's Bugzilla with three steps: + +# Add the project to [https://release-monitoring.org anitya]. +# Map the project to a Fedora package in [https://release-monitoring.org anitya]. +# Tweak the monitoring setting for your packages at https://src.fedoraproject.org/rpms/ + +== Bugzilla bugs by the-new-hotness == + +* [https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=MODIFIED&bug_status=ON_DEV&bug_status=ON_QA&bug_status=VERIFIED&bug_status=RELEASE_PENDING&bug_status=POST&classification=Fedora&columnlist=product%2Ccomponent%2Cassigned_to%2Cbug_status%2Cresolution%2Cshort_desc%2Cchangeddate%2Copendate&email1=upstream-release-monitoring%40fedoraproject.org&emailreporter1=1&emailtype1=substring&list_id=1733771&order=changeddate%20DESC%2Cbug_id%20DESC&query_based_on=&query_format=advanced OPEN bugs] + +* [https://bugzilla.redhat.com/buglist.cgi?bug_status=CLOSED&classification=Fedora&email1=upstream-release-monitoring%40fedoraproject.org&emailreporter1=1&emailtype1=substring&order=changeddate%20DESC%2Cbug_id%20DESC&query_based_on=&query_format=advanced CLOSED bugs] + +== Details == + +One of the core foundation of Fedora is "First" which implies having the latest +versions of software (in rawhide and sometimes in released branches), but as a +package maintainer it can be tedious to keep up with the releases from multiple +projects. + +Fedora thus offers a service to help with this. This service is divided into +three components: + +* Anitya +* monitoring settings at src.fedoraproject.org +* the-new-hotness + +{{Admon/note|Previous Service|This service used to be managed by a tool called [https://fedorapeople.org/cgit/till/public_git/cnucnu.git/ cnucnu] which scraped a wiki page for what upstreams to monitor. You can find the old list of monitored packages in the history of this page.}} + +=== Anitya === + +Available at [https://release-monitoring.org https://release-monitoring.org] it +provides a web service where anyone can register a project and will broadcast a +[http://fedmsg.com fedmsg] message when it finds a new release (checks are run +by cron twice a day). + +This service is not specific to Fedora but we are using it as a way to learn +about new releases. Edit entries there to your heart's content. + +Bugs, features request and patches should go to: https://github.com/fedora-infra/anitya/issues + +=== Monitoring settings at src.fedoraproject.org === + +Fedora package maintainers can use the bottom left column at the package's page at [https://src.fedoraproject.org/ src.fedoraproject.org] to have it monitored by the-new-hotness (see below). + +=== The-New-Hotness === + +[https://github.com/fedora-infra/the-new-hotness/ The-new-hotness] is an application that listens to the fedmsg bus and acts upon +receiving messages from [https://release-monitoring.org release-monitoring.org]. + +When it receives a message indicating that a project has a new release, if that +project is mapped to a Fedora package, it will check in pkgdb2 if the Fedora +package is marked to be monitored. + +If the package is marked to be monitored, the-new-hotness will open a ticket +on [https://bugzilla.redhat.com Bugzilla] mentioning the +availability of the new release. It will then clone the git repository, bump +the version and reset the release, download the new sources (if it can) and +attempt a scratch build in koji. + +The result of the scratch build is then added to the open bugzilla ticket. + +Subsequent successful koji builds are added to the ticket as well. + + +Note: In some cases the scratch build will always fail +(for example if the Source0 in the spec file cannot be adjusted automatically), if +you wish to avoid receiving the notification that the scratch-build failed, you can +set the monitoring flag in pkgdb2 to ''nobuild'' (or ''Bugs only''). Then the bugzilla ticket will be +created upon finding a new version, but no scratch build will be made. + +== Related Projects == +* [http://dehs.alioth.debian.org/ Debian External Health Status] ([http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717834 offline] since August 2013) +* [http://people.redhat.com/caolanm/latestpackages/ Custom script for packages from Caolán McNamara] +* [http://github.com/tannewt/open-source-watershed OSWatershed] - Monitors several distributions at once +* [https://ppisar.fedorapeople.org/cpandistributionsinfedora.xhtml Perl package monitoring] +* [http://rpms.famillecollet.com/rpmphp/ Reports from Remi] PECL, pear and R extensions upstream comparison and stable repo with rawhide comparison for all packages +* [http://distrowatch.com/table.php?distribution=fedora DistroWatch.com: Fedora] +* [http://youri.zarb.org/ Youri] [http://check.mageia.org/ in action] [http://svnweb.mageia.org/adm/puppet/modules/youri-check/ puppet modules] A generic framework +* [https://github.com/jness/ossvt ossvt] Developed for [https://launchpad.net/ius IUS] +* [https://fedorapeople.org/cgit/till/public_git/cnucnu.git/ the tool previously used to provides this service for Fedora] +* [http://repology.org/metapackages/outdated-in-repo/fedora_rawhide/ Repology] cross distro version comparision diff --git a/modules/ROOT/pages/wiki/Using_Mock_to_Test_Package_Builds.wiki b/modules/ROOT/pages/wiki/Using_Mock_to_Test_Package_Builds.wiki new file mode 100644 index 0000000..93c1b42 --- /dev/null +++ b/modules/ROOT/pages/wiki/Using_Mock_to_Test_Package_Builds.wiki @@ -0,0 +1,307 @@ +{{needs love}} +{{Admon/warning | Following chapters are no longer applicable for recent Fedora releases. | Mock now uses [[dnf|DNF]] instead of YUM, therefore some information is outdated}} +This page is a collection of bits people have found useful when working with mock. +A more up-to-date version of this information is in the [https://github.com/rpm-software-management/mock/wiki "user documentation" section of the project pages]. + +== What is Mock? == +Mock takes a srpm and builds it in a chroot. This ensures that your [[Packaging:Guidelines#BuildRequires_2|BuildRequires]] lines are correct, that there are no missing dependencies, and that it builds cleanly. +The [https://github.com/rpm-software-management/mock/wiki Mock project page][https://github.com/rpm-software-management/mock/wiki]Mock project page has more information on Mock. + +== How do I set up Mock? == + +First, install the mock package, which is available from Fedora Package Collection. + +=== Default configuration === + +When using mock, you can use the "-r" option to select a particular test configuration. +If there's one configuration that system users will normally use, you can set that as the +default: + # cd /etc/mock + # ln -s --force SOMECONFIG.cfg default.cfg + +(An example of SOMECONFIG.cfg is "fedora-14-x86_64.cfg"; see the /etc/mock directory for the existing mock configurations.) + +=== Setting up local mirror === + +If you want to set up a local mirror, refer [[Docs/Drafts/MockSetupUsingLocalMirror]] + +=== Proxy Configurations === + +If you're behind a proxy, add the proxy info to the desired cfg file in /etc/mock in the same format that you would add it to your yum.conf. +See '''man yum.conf''' for details on how to do it. + +== How do I use Mock? == + +Mock accepts a number of commands. Mock accepts commands in old-style format (e.g., "rebuild" or "init" without a leading "--"), but these are deprecated; use commands with a leading "--" instead. + +=== Using Mock outside your git sandbox === + +Add your user name to the mock group + +sudo usermod -a -G mock myusername + +Create your srpm using 'rpmbuild -bs'. Then change to the directory where your srpm was created. + +Now you can start mock with + +mock -r --rebuild package-1.2-3.src.rpm + +where is the name of a configuration from /etc/mock/ (do not include the .cfg extension). Passing -r is not necessary if you have set a default config file via a symlink as shown above. --rebuild is the default option. So the following would work equally well + +mock package-1.2-3.src.rpm + +The --verbose option is useful if you want more output to be shown for debugging purposes. + +If using mock version older than 0.8.8 or on a system with python 2.4, and building i386 packages on x86_64, prepend setarch i386 to the mock command line: + +setarch i386 mock -r --rebuild package-1.2-3.src.rpm + +Newer versions of mock no longer need the setarch command, although it does not hurt anything if it is there. + +=== Using Mock inside your git sandbox === + +You only need to type 'fedpkg mockbuild' to start a mock build. The used architecture depends +on the directory where you start the mock build. + +== Building packages that depend on packages not in a repository == + +If you're building some package P that depends on another package Q, and Q is not in a repository, +you can still use mock. Here's one way to do that. + +First, initialize the mock repository: + mock -r MOCK_CONFIG --init + +Note: If you get the error "Error: There are no enabled repos." then this is because (like me) you're on current Fedora and the fake O/S inside the chroot is attempting downloads using yum. In that case you have to put the "--dnf" to force it to use DNF. + mock -r MOCK_CONFIG --dnf --init + +(An example of MOCK_CONFIG is "fedora-14-x86_64"; see the /etc/mock directory for the existing mock configurations.) + +Install the packages you need to build the program (named in BuildRequires) from the yum repositories and/or local RPMs. In practice, you may need to do a number of these (for the different package dependencies); you can list multiple packages on the same line: + mock -r MOCK_CONFIG --install PACKAGE_NAME_OR_PATH_TO_RPM + +Current versions of mock should permit you to now build from the source RPM. If that does not work then the "--copyin" method below should be used. The --no-clean option is necessary since by default the chroot is cleaned prior to building. + mock -r MOCK_CONFIG --no-clean /PATH/TO/SRPM + +Copy in the source RPM into /tmp (we'll copy in and do a build inside the shell, to work around the checks that detect that the packages aren't in the repository). Do not copy into /tmp directory, because it gets cleared before other mock command: + mock -r MOCK_CONFIG --copyin /PATH/TO/SRPM /var/tmp + +Shell into the mock environment and perform the build: + mock -r MOCK_CONFIG --shell + cd + rpmbuild --rebuild /var/tmp/SRPM_NAME + + + + +== Speeding up == + +
    +
  • /etc/mock/site-defaults.cfg +
      +
    • Disable the package state plugin: 
      config_opts['plugin_conf']['package_state_enable'] = False
      • +
    • Parallelize builds: 
      config_opts['macros']['%_smp_mflags'] = "-j17"
      • +
    • Improve ccache hits between package version builds (may break -debuginfos!): + 
      config_opts['files']['etc/profile.d/zz-local.sh'] = """
+unset CCACHE_HASHDIR
+"""
      • +
    • Compress ccache: 
      config_opts['plugin_conf']['ccache_opts']['compress'] = True
      • +
    • Use lzo compression for root cache: + 
      config_opts['plugin_conf']['root_cache_opts']['compress_program'] = "lzop"
+config_opts['plugin_conf']['root_cache_opts']['extension'] = ".lzo"
      • +
    +
    • +
  • Per-repo config files +
      +
    • Parallelize (de)compression within rpmbuild: + 
      config_opts['chroot_setup_cmd'] = 'install @buildsys-build /usr/bin/pigz /usr/bin/lbzip2'
+config_opts['macros']['%__gzip'] = '/usr/bin/pigz'
+config_opts['macros']['%__bzip2'] = '/usr/bin/lbzip2'
      • +
    +
    • +
+ +== Using [http://clang-analyzer.llvm.org/scan-build.html scan-build] for unmodified packages == + +* Add /usr/bin/scan-build to per-chroot config files' chroot_setup_cmd for which you want to use it, for example: +
config_opts['chroot_setup_cmd'] = 'install @buildsys-build /usr/bin/scan-build'
+ +* Set up a shell alias and use it instead of plain mock (everything on one line): +
alias mock-scan-build="mock --define '__scan_build /usr/bin/scan-build' --define '_configure %__scan_build ./configure' --define '__cmake %__scan_build %{_bindir}/cmake' --define '__make %__scan_build %{_bindir}/make' --define '___build_template #!%{___build_shell}\\"$'\n'"alias make=\"%__make\" cmake=\"%__cmake\"\\"$'\n'"%{___build_pre}\\"$'\n'"%{nil}'"
+ +* See generated reports in the chroot's /tmp + +== Caching in mock 0.8.x and later == + +Mock 0.8.x introduces three different types of caches: 1) root cache, 2) yum cache, and 3) ccache. These caches greatly speed up mock. + +Look in /etc/mock/defaults.cfg for documentation on configuring each of these caches. You can configure the directory where they are stored, the maximum age of the caches, and (for ccache only) the max disk usage for the cache. + +=== Root cache === + +Starting with mock 0.5, mock can automatically cache the standard buildroot for each environment in a local tar file (/var/cache/mock/$CONFIG/root_cache/*). It then unpacks this tar file to populate the buildroot, rather than downloading the buildroot RPMs fresh each time. After unpacking the buildroot from the root cache, mock does a yum update to make sure that the buildroot is up-to-date prior to installing additional BuildRequires for a package build. + +The root cache is enabled by default in mock 0.8.x and later. To disable, see the documentation in /etc/mock/defaults.cfg. The root cache can be disabled globally or per-chroot. The root caches are automatically deleted and recreated every 15 days to prevent them from being too stale. + +Keep in mind that the root cache can affect reproducibility of your build, especially in environments where the set of base RPMs is updated often (eg. rawhide). Disable the root cache in environments where build reproducibility is of utmost importance. + +=== yum cache === + +By default, yum stores downloaded RPMs in a directory under /var/cache/yum. The yum cache feature bind mounts the chroot /var/cache/yum to a common directory outside the chroot environment (such as /var/cache/mock/$CONFIG/yum_cache/) where it can be saved and re-used by subsequent builds. This ensures that yum does not need to download each RPM fresh over the network for every build. This feature is enabled by default. + +=== ccache === + +The ccache tool is a utility that wraps calls to compilers such as 'gcc' and caches the output. When called to compile the same program a second time (with the same cmdline args, gcc-version, and header files), ccache will instead pull the cached version rather than running the compiler afresh. + +== Using Squid to Speed Up Mock package downloads == +The cached buildroots trick above is much faster than using squid alone, but you can also use squid in addition to the cached buildroots, particularly if you are at the slow end of an Internet connection. + +The root cache will contain the standard buildroot packages, but as it gets older, the yum update after unpacking it may have to update several packages. In addition, some packages aren't in the standard buildroot, but are often needed (e.g. pkgconfig). These can be faster served from a squid cache than from downloading them from the Internet for each package build. + +Install the squid package which is available from Fedora Package Collection. + +Some items worth changing in /etc/squid/squid.conf: +* Maximum Object Size. Normally, this is 4MB. However, some of the base packages like glibc can be larger than 16MB, and if you're building say Eclipse plugins, that's 60MB. So make it large. + +maximum_object_size 409600 KB + +* Cache Replacement Policy. Normally, lru is fine. But in our case, we want to keep the largest objects around longer, and just download the smaller objects if we can. + +cache_replacement_policy heap LFUDA + +* Cache Size. Normal size is 100MB. This isn't going to cut it. This needs to be at least 1GB, more if you regularly build for multiple Fedora releases and multiple architectures. + +cache_dir ufs /var/spool/squid 1000 16 256 + +Then start squid, and configure it to start on startup. + +To make the build user automatically use the squid cache, type: + +echo export http_proxy=\"http://localhost:3128\" >> /home/build/.bash_profile + +If you only want to use squid for particular mock configurations (perhaps you have local mirrors of some distributions and don't need squid for those), +you can, instead of setting the http_proxy environment variable, set up the proxy configuration in the yum.conf part of each mock configuration file: + +
config_opts['yum.conf']  = """
+[main] 
+...
+proxy=http://localhost:3128/
+
+...
+"""
+ +=== Edit /etc/mock/*.cfg to not use mirror lists === + +'''Don't use the mirrorservice.org mirror; they [https://www.redhat.com/archives/fedora-extras-list/2006-September/msg00022.html prevent downstream caching] via the HTTP header "Cache-Control: no-store". ''' + +If you're using squid, you don't want mock+squid to use a random mirror for downloading packages. Change the config files in /etc/mock/*.cfg to use a single fast-for-you mirror in a baseurl entry, and don't use mirrorlists. You can use [https://gist.github.com/4478541 this script] for that. + +== Using tmpfs to avoid disk access == +'''It's not clear that tmpfs is a huge win anymore, now that autocache works and is a standard feature.''' + +When having enough RAM (1.5-2 GB), using a tmpfs can speedup the 'prep' phase significantly. With 1.5GB RAM on a Celeron 2.8 GHz, populating the buildroot will take 2-5s (seconds) on subsequent builds. + +You can either mount /var/lib/mock as a tmpfs, or you can mount each of the build directories under /var/lib/mock as separate tmpfs file systems. The latter lets you use the autocache above and keeps the autocache files on disk, rather than in the tmpfs. If you erase and recreate the autocaches often, keeping them in tmpfs makes sense. If you don't recreate them often, then you should use per-build-directory tmpfs mounts instead. + + +== Using mock under SELinux == + +Using SELinux in conjuction with chroot-ed environments such as mock presents a number of problems, +such as needing to replicate all default file contexts with the chroot directory prefix, which is an +administrative nightmare. The approach used by mock is very simple, though it only works with the targeted policy: +preload a dummy libselinux that makes all child processes think that SELinux is disabled. +With mock itself running as an ''unconfined'' process, this generally works well. + +=== Problems with SELinux memory protection === + +However, from FC5 onwards, the SELinux unconfined_t domain is no longer fully unconfined by SELinux; +[http://people.redhat.com/drepper/selinux-mem.html memory protection] is implemented to protect most user processes against +a variety of possible exploits. +This presents at least two sets of problems when using mock in FC5: +# When [[Legacy/Mock| building packages for legacy distributions]] , the build process can involve loading old shared libraries that do not have separate sections for, say, executable code and writable data. This leads to execmod denials when a process running in the unconfined_t domain tries to load such a library, unless the library is labelled textrel_shlib_t. +# When building packages using ''mono'' (the same might apply to ''java''), the mono process would normally run in its own less-constrained domain (mono_t); when running under mock, mono runs in the unconfined_t domain, which can result in execstack and execheap denials. +Whilst it is possible to turn off these checks using SELinux booleans, this is not a desirable thing to do for all processes. +Another solution would be to ensure that all files were labelled correctly in the chroot and that SELinux domain transitions ocurred when needed. However, this is not possible because processes running under mock are told by the dummy libselinux that SELinux is disabled. + +=== SELinux policy module for mock === + +The following solution to these issues creates an SELinux policy for mock that has two aspects: +# It runs mock in its own domain (mock_t) that is as unconstrained as any process that needs to run under it needs to be, which so far means that it allows execheap and execmod, just like the mono_t domain does. +# It labels all files installed under /var/lib/mock (where mock sets up its chroot environments) with the special context type mock_var_lib_t, for which execmod is allowed for processes in the mock_t domain. + +This solution relaxes SELinux protection sufficiently for mock to be able to work, without compromising the protection afforded to the normal ''unconfined'' domain. + +To install the policy module: +* Create a directory to store local policy files, such as /root/selinux.local, and change to that directory +* Download [[Image:PackageMaintainers_MockTricks_mock.if]], [[Image:PackageMaintainers_MockTricks_mock.fc]], and [[Image:PackageMaintainers_MockTricks_mock.te]] to this directory +* Build and install the policy module as follows: +
# make -f /usr/share/selinux/devel/Makefile
+Compliling targeted mock module
+/usr/bin/checkmodule:  loading policy configuration from tmp/mock.tmp
+/usr/bin/checkmodule:  policy configuration loaded
+/usr/bin/checkmodule:  writing binary representation (version 5) to tmp/mock.mod
+Creating targeted mock.pp policy package
+rm tmp/mock.mod.fc tmp/mock.mod
+{{Admon/warning | The selinux-policy-devel and checkpolicy packages are required}} + +If the policy module is loaded before the mock package is installed, /var/lib/mock will be labelled as mock_var_lib_t and /usr/bin/mock will be labelled as mock_exec_t at installation time. Otherwise, it's necessary to use restorecon to fix the file contexts: +
# restorecon -R /var/lib/mock /usr/bin/mock
+ +{{Admon/note |This policy would probably work for mach as well, just by adding these two lines to mock.fc: +
+/usr/bin/mach       -- gen_context(system_u:object_r:mock_exec_t,s0)
+/var/lib/mach(/.*)?    gen_context(system_u:object_r:mock_var_lib_t,s0)
+}} + +== Using mock as a chroot sandbox tool == + +Mock can be used to create chroots for testing things, not just building packages. Here is a quick howto: + +* Create a config file that points to the repo(s) of your choice, where your test packages are + mock -r --init + mock -r --install + mock -r --shell + +Why use mock to shell, why not chroot directly? Using mock to "shell" will allow mock to create the mountpoints you'll probably need inside the chroot. If you want to manage your mounts manually, do so by all means. + +== Testing graphical applications inside mock == + +To test graphical applications or tcl/tk bindings inside mock you have to enable other hosts using xhost (or at least the one you need): +
+xhost + 
+
+ +and then set the DISPLAY environment variable inside the chroot: + +
+export DISPLAY=:0.0
+
+ +== Disable domain name resolution == + +Sometimes you build you package locally, but it fails as soon as you build it in Koji, since it cannot resolve domain names and connect to remote services. This is because DNS is not configured in mock for Koji. You can achieve the same functionality locally, by adding + +
+config_opts['use_host_resolv'] = False
+
+ +into your mock config. You can add this option into site-defaults.cfg to enable it by default for every mock configuration. + + + +[[Category:Package Maintainers]] diff --git a/modules/ROOT/pages/wiki/Using_the_Koji_Build_System.wiki b/modules/ROOT/pages/wiki/Using_the_Koji_Build_System.wiki new file mode 100644 index 0000000..f09f9c7 --- /dev/null +++ b/modules/ROOT/pages/wiki/Using_the_Koji_Build_System.wiki @@ -0,0 +1,316 @@ +{{autolang|base=yes}} += Using Koji in Fedora = + +The [[Koji| Koji Build System]] is Fedora's RPM buildsystem. Packagers use the koji client to request package builds and get information about the buildsystem. Koji runs on top of Mock to build RPM packages for specific architectures and ensure that they build correctly. + +There is also a [[Zh/使用Koji编译打包系统|simplified Chinese edition]]. + +== Installing Koji == + +==== Installing the Koji CLI ==== + +To use Koji (and be a Fedora contributor) install the fedora-packager package: + +
+dnf install fedora-packager
+
+ +fedora-packager provides useful scripts to help maintain and setup your koji environment. Additionally, it includes dependencies on the Koji CLI, so it is installed when you install fedora-packager. The command is called koji and is included in the main koji package. By default, the koji tool authenticates to the central server using Kerberos. You must have a valid authentication token to use many features. However, many of the read-only commands work without authentication. + +If you need help setting up authentication or becoming a Fedora packager use this guide: [[Join_the_package_collection_maintainers]]
+ +==== Koji Setup ==== + +Before using Koji to build packages, you must have the fedora-packager package installed: + +
+dnf install fedora-packager
+
+ +You must also have a valid kerberos ticket. Assuming you are using Koji to build for Fedora, use your [[Account System|FAS]] username and FEDORAPROJECT.ORG as the realm. Kerberos requires the 'realm'. which here also looks like a 'domain' name, to be in all capital letters. + +
+KRB5_TRACE=/dev/stdout kinit your_fas_username@FEDORAPROJECT.ORG
+
+ +Store your FAS username (all lower case) in ~/.fedora.upn (This is not actually needed for Kerberos but for other tools that used the Fedora client certificate to determine the FAS username.) + +For more information, see [[Infrastructure/Kerberos|Kerberos setup]]. + +==== Koji Config ==== +The global-local client configuration file for koji is /etc/koji.conf. You should not need to change this from the defaults for building Fedora packages. These allow you to use the primary build system as well as secondary arch build systems. + +You can use the koji command directly, or use fedpkg, a script that interacts with the RPM Packaging system and other subsystems, like git and koji itself. + +== Building with fedpkg targets == + +When building with fedpkg within a git repository, every push is automatically tagged via git. All you have to do to build the package is to run: + +
+fedpkg build
+
+ +This triggers a build request for the branch. Easy! + +It is also possible to target a specific koji tag: + +
+fedpkg build --target TARGET
+
+ +For example, if building on rawhide against a special tag created by rel-eng for updating API for many packages, such as dist-f14-python, use the following: + +
+fedpkg build --target 'dist-f14-python'
+
+ +==== Chained builds ==== +{{Admon/warning | chain-builds only work when building on the devel/ branch (aka rawhide). To chain-build packages to update a released OS version, [https://fedoraproject.org/wiki/Bodhi/BuildRootOverrides set up an override using bodhi] requesting packages to be included in the proper buildroot.}} +Sometimes you want to make sure that one build has succeeded before +launching the next one, for example when you want to rebuild +a package against a dependency that has just been rebuilt. In that case, +use a chain build with: + + fedpkg chain-build libwidget libgizmo + +The current package is added to the end of the CHAIN list. Colons (:) can be used in the CHAIN parameter to define groups of packages. Packages in any single group will be built in parallel and all packages in a group must build successfully and populate the repository before the next group will begin building. For example: + + fedpkg chain-build libwidget libaselib : libgizmo : + +causes libwidget and libaselib to be built in parallel, followed by libgizmo, and then the package in your current directory. If no groups are defined, packages will be built sequentially. + +If a build fails, following builds are canceled, but the builds that already succeeded are pushed to the repository. + +== Scratch Builds == + +Sometimes it is useful to be able to build a package against the buildroot without actually including it in the release. This is called a scratch build. + +The following section covers using koji directly, as well as the fedpkg tool, to do scratch builds. + +To create a scratch build from changes you haven't committed, do the following: + +
+rpmbuild -bs foo.spec
+koji build --scratch rawhide foo.srpm
+
+ +From the latest git commit: + +
+koji build --scratch rawhide 'git url'
+
+ +Warning: Scratch builds will ''not'' work correctly if your .spec file does something different depending on the value of %fedora, %fc9, and so on. Macro values like these are set by the ''builder'', not by koji, so the value of %fedora will be for whatever created the source RPM, and ''not'' what it's being built on. Non-scratch builds get around this by first re-building the source RPM. + +If you have committed the changes to git and you are in the current branch, you can do a scratch build with fedpkg tool, which wraps the koji command line tool with the appropriate options: + +
+fedpkg scratch-build
+
+ +To run a scratch build for a specific architecture: + +
+fedpkg scratch-build --arches 
+
+ + can be a comma separated list of several architectures. + +Finally, it is possible to combine the scratch-build command with a specific koji tag in the form: + +
+fedpkg scratch-build --target TARGET
+
+ +fedpkg scratch-build --help or koji build --help for more information. + +== Build Failures == + +If your package fails to build, you get an error, for example: + +
+420066 buildArch kernel-2.6.18-1.2739.10.9.el5.jjf.215394.2.src.rpm,
+ia64): open (build-1.example.com) -> FAILED: BuildrootError:
+error building package (arch ia64), mock exited with status 10
+
+ +Investigate why the build failed by looking at the log files. If there is a build.log, start there. Otherwise, look at init.log. + +Each job you successfully start gets a unique task ID, which is listed in its output. + +Logs can be found in the web interface, in the Task pages for the failed task. Alternatively, use koji watch-log, along with the task ID, to view the logs. See the help output for more details. + +== Advanced use of Koji == + +We've tried to make Koji self-documenting wherever possible. The command line tool prints a list of valid commands, and each command supports --help. For example: + +
+$ koji help
+
+Koji commands are:
+build                Build a package from source
+cancel-task          Cancel a task
+help                 List available commands
+latest-build         Print the latest rpms for a tag
+latest-pkg           Print the latest builds for a tag
+[...] 
+
+ +
+$ koji build --help
+
+usage: koji build [options]  tag URL
+(Specify the --help global option for a list of other help options)
+
+options:
+-h, --help            show this help message and exit
+--skip-tag            Do not attempt to tag package
+--scratch             Perform a scratch build
+--nowait              Don't wait on the build
+[...] 
+
+ +==== Using koji to generate a mock config to replicate a buildroot ==== + +koji can be used to replicate a build root for local debugging. + +
+koji mock-config --help
+Usage: koji mock-config [options] name
+(Specify the --help global option for a list of other help options)
+
+Options:
+  -h, --help            show this help message and exit
+  --arch=ARCH           Specify the arch
+  --tag=TAG             Create a mock config for a tag
+  --task=TASK           Duplicate the mock config of a previous task
+  --buildroot=BUILDROOT
+                        Duplicate the mock config for the specified buildroot
+                        id
+  --mockdir=DIR         Specify mockdir
+  --topdir=DIR          Specify topdir
+  --topurl=URL          url under which Koji files are accessible
+  --distribution=DISTRIBUTION
+                        Change the distribution macro
+  -o FILE               Output to a file
+
+For example to get the latest buildroot for dist-f12-build run: +
+koji mock-config --tag dist-f12-build --arch=x86_64 --topurl=http://kojipkgs.fedoraproject.org/ dist-f12
+
+ +You must pass --topurl=http://kojipkgs.fedoraproject.org/ to any mock-config command to get a working mock-config from Fedora's koji. + +==== Using Koji to control tasks ==== + +List tasks: +
+koji list-tasks
+
+ +List only tasks requested by you: +
+koji list-tasks --mine
+
+ +requeue an already-processed task: general syntax is: koji resubmit [options] taskID + +
+koji resubmit 3
+
+ +==== Building a Package with the command-line tool ==== + +Instead of using the fedpkg target, you can also directly +use the command_line tool, koji. + +To build a package, the syntax is: + +
+$ koji build  
+
+ +For example: +{{Admon/warning | Replace dist-f14 with the tag you wish to build against, e.g. dist-rawhide}} + +
+$ koji build dist-f14 'git url'
+
+ +The koji build command creates a build task in Koji. By default, the tool will wait and print status updates until the build completes. You can override this with the --nowait option. + +NOTE: For fedora koji, the git url MUST be based on pkgs.fedoraproject.org. Other arbitrary git repos cannot be used for builds. + +== Koji tags and packages organization == + +==== Terminology ==== +In Koji, it is sometimes necessary to distinguish between a package in general, a specific build of a package, and the various rpm files created by a build. When precision is needed, these terms should be interpreted as follows: + +* Package: The name of a source rpm. This refers to the package in general and not any particular build or subpackage. For example: kernel, glibc, etc. +* Build: A particular build of a package. This refers to the entire build: all arches and subpackages. For example: kernel-2.6.9-34.EL, glibc-2.3.4-2.19. +* RPM: A particular rpm. A specific arch and subpackage of a build. For example: kernel-2.6.9-34.EL.x86_64, kernel-devel-2.6.9-34.EL.s390, glibc-2.3.4-2.19.i686, glibc-common-2.3.4-2.19.ia64 + +==== Tags and targets ==== + +Koji organizes packages using tags. In Koji a tag is roughly a collection of packages: + +* Tags support inheritance +* Each tag has its own list of valid packages (inheritable) +* Package ownership can be set per-tag (inheritable) +* When you build you specify a target rather than a tag + +A build target specifies where a package should be built and how it should be tagged afterward. This allows target names to remain fixed as tags change through releases. + +==== Koji commands for tags ==== + + +===== Targets ===== +You can get a full list of build targets with the following command: + +
+$ koji list-targets
+
+ +You can see just a single target with the --name option: + +
+$ koji list-targets --name f30
+Name                           Buildroot                      Destination                   
+---------------------------------------------------------------------------------------------
+f30                            f30-build                      f30-pending                   
+
+ +This tells you a build for target f30 will use a buildroot with packages from the f30-build tag and tag the resulting packages as f30-pending. + +Watch out: You probably do not want to build against rawhide. If Fedora N is the latest one out, to build to the next one, choose f{N+1}. + +===== Tags ===== + +You can get a list of tags with the following command: +
+$ koji list-tags
+
+ +===== Packages ===== + +As mentioned above, each tag has its own list of packages that may be placed in the tag. To see that list for a tag, use the list-pkgs command: + +
+$ koji list-pkgs --tag dist-f14
+
+
+ +The first column is the name of the package, the second tells you which tag the package entry has been inherited from, and the third tells you the owner of the package. + +===== Latest Builds ===== + +To see the latest builds for a tag, use the latest-pkg command: + +
+$ koji latest-pkg --all dist-f14
+
+
+ +The output gives you not only the latest builds, but which tag they have been inherited from and who built them. + +[[Category:Package Maintainers]] diff --git a/modules/ROOT/partials/attributes.adoc b/modules/ROOT/partials/attributes.adoc new file mode 100644 index 0000000..f5420a7 --- /dev/null +++ b/modules/ROOT/partials/attributes.adoc @@ -0,0 +1 @@ +:year: 2021 diff --git a/nginx.conf b/nginx.conf new file mode 100644 index 0000000..f7093b3 --- /dev/null +++ b/nginx.conf @@ -0,0 +1,14 @@ +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; + } +} diff --git a/pelicanconf.py b/pelicanconf.py deleted file mode 100644 index e90ec75..0000000 --- a/pelicanconf.py +++ /dev/null @@ -1,46 +0,0 @@ -# -*- coding: utf-8 -*- # -from __future__ import unicode_literals - -AUTHOR = u'The Fedora Project' -SITENAME = u'Fedora Documentation' -SITEURL = 'https://docs.pagure.org/docs-fedora/' - -PATH = 'content' -ARTICLE_EXCLUDES = ['en-US/old'] -TIMEZONE = 'Europe/Paris' - -DEFAULT_LANG = u'en' - -THEME = 'theme' - -# Feed generation is usually not desired when developing -FEED_ALL_ATOM = None -CATEGORY_FEED_ATOM = None -TRANSLATION_FEED_ATOM = None -AUTHOR_FEED_ATOM = None -AUTHOR_FEED_RSS = None - -# Blogroll -LINKS = (('Pelican', 'http://getpelican.com/'), - ('Python.org', 'http://python.org/'), - ('Jinja2', 'http://jinja.pocoo.org/'), - ('You can modify those links in your config file', '#'),) - -# Social widget -SOCIAL = (('You can add links in your config file', '#'), - ('Another social link', '#'),) - -DEFAULT_PAGINATION = False - -PLUGIN_PATHS = ['plugins'] -PLUGINS = ['asciidoc_reader', 'filetime_from_git', 'tipue_search', 'related_posts'] - -STATIC_PATHS = ['images'] - -DIRECT_TEMPLATES = (('index', 'tags', 'categories', 'authors', 'archives', 'search', 'all_articles')) - -PAGINATED_DIRECT_TEMPLATES = ['index', 'all_articles'] - -# Uncomment following line if you want document-relative URLs when developing -RELATIVE_URLS = True - diff --git a/plugins/asciidoc_reader/README.rst b/plugins/asciidoc_reader/README.rst deleted file mode 100644 index a14bd2d..0000000 --- a/plugins/asciidoc_reader/README.rst +++ /dev/null @@ -1,49 +0,0 @@ -AsciiDoc Reader -############### - -This plugin allows you to use `AsciiDoc `_ -to write your posts. File extension should be ``.asc``, ``.adoc``, -or ``.asciidoc``. - -Dependency ----------- - -There are two command line utilities commonly used to render AsciiDoc: -``asciidoc`` and ``asciidoctor``. One of the two will need to be installed and -on the PATH. - -**Note**: The ``asciidoctor`` utility is recommended since the original -``asciidoc`` is no longer maintained. - -Settings --------- - -======================================== ======================================================= -Setting name (followed by default value) What does it do? -======================================== ======================================================= -``ASCIIDOC_CMD = asciidoc`` Selects which utility to use for rendering. Will - autodetect utility if not provided. -``ASCIIDOC_OPTIONS = []`` A list of options to pass to AsciiDoc. See the `manpage - `_. -======================================== ======================================================= - -Example file header -------------------- - -Following the `example `_ in the main pelican documentation: - -.. code-block:: none - - = My super title - - :date: 2010-10-03 10:20 - :modified: 2010-10-04 18:40 - :tags: thats, awesome - :category: yeah - :slug: my-super-post - :authors: Alexis Metaireau, Conan Doyle - :summary: Short version for index and feeds - - == title level 2 - - and so on... diff --git a/plugins/asciidoc_reader/__init__.py b/plugins/asciidoc_reader/__init__.py deleted file mode 100644 index 5752357..0000000 --- a/plugins/asciidoc_reader/__init__.py +++ /dev/null @@ -1 +0,0 @@ -from .asciidoc_reader import * diff --git a/plugins/asciidoc_reader/asciidoc_reader.py b/plugins/asciidoc_reader/asciidoc_reader.py deleted file mode 100644 index 8aedbab..0000000 --- a/plugins/asciidoc_reader/asciidoc_reader.py +++ /dev/null @@ -1,89 +0,0 @@ -# -*- coding: utf-8 -*- -""" -AsciiDoc Reader -=============== - -This plugin allows you to use AsciiDoc to write your posts. -File extension should be ``.asc``, ``.adoc``, or ``asciidoc``. -""" - -from pelican.readers import BaseReader -from pelican import signals -import os -import re -import subprocess - -def call(cmd): - """Calls a CLI command and returns the stdout as string.""" - return subprocess.Popen(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, shell=True).communicate()[0].decode('utf-8') - -def default(): - """Attempt to find the default AsciiDoc utility.""" - for cmd in ALLOWED_CMDS: - if len(call(cmd + " --help")): - return cmd - -ALLOWED_CMDS = ["asciidoc", "asciidoctor"] - -ENABLED = None != default() - -class AsciiDocReader(BaseReader): - """Reader for AsciiDoc files.""" - - enabled = ENABLED - file_extensions = ['asc', 'adoc', 'asciidoc'] - default_options = ['--no-header-footer'] - - def read(self, source_path): - """Parse content and metadata of AsciiDoc files.""" - cmd = self._get_cmd() - content = "" - if cmd: - optlist = self.settings.get('ASCIIDOC_OPTIONS', []) + self.default_options - options = " ".join(optlist) - content = call("%s %s -o - %s" % (cmd, options, source_path)) - metadata = self._read_metadata(source_path) - return content, metadata - - def _get_cmd(self): - """Returns the AsciiDoc utility command to use for rendering or None if - one cannot be found.""" - if self.settings.get('ASCIIDOC_CMD') in ALLOWED_CMDS: - return self.settings.get('ASCIIDOC_CMD') - return default() - - def _read_metadata(self, source_path): - """Parses the AsciiDoc file at the given `source_path` and returns found - metadata.""" - metadata = {} - with open(source_path) as fi: - prev = "" - for line in fi.readlines(): - # Parse for doc title. - if 'title' not in metadata.keys(): - title = "" - if line.startswith("= "): - title = line[2:].strip() - elif line.count("=") == len(prev.strip()): - title = prev.strip() - if title: - metadata['title'] = self.process_metadata('title', title) - - # Parse for other metadata. - regexp = re.compile(r"^:[A-z]+:\s*[A-z0-9]") - if regexp.search(line): - toks = line.split(":", 2) - key = toks[1].strip().lower() - val = toks[2].strip() - if key == 'tags' or key == 'fedoraversions': - val = val.split(',') - metadata[key] = self.process_metadata(key, val) - prev = line - return metadata - -def add_reader(readers): - for ext in AsciiDocReader.file_extensions: - readers.reader_classes[ext] = AsciiDocReader - -def register(): - signals.readers_init.connect(add_reader) diff --git a/plugins/asciidoc_reader/test_asciidoc_reader.py b/plugins/asciidoc_reader/test_asciidoc_reader.py deleted file mode 100644 index 46a4dac..0000000 --- a/plugins/asciidoc_reader/test_asciidoc_reader.py +++ /dev/null @@ -1,70 +0,0 @@ -# -*- coding: utf-8 -*- -from __future__ import unicode_literals - -import datetime -import os - -from pelican.readers import Readers -from pelican.tests.support import unittest, get_settings - -from .asciidoc_reader import ENABLED - -CUR_DIR = os.path.dirname(__file__) -CONTENT_PATH = os.path.join(CUR_DIR, 'test_data') - -@unittest.skipUnless(ENABLED, "asciidoc isn't installed") -class AsciiDocReaderTest(unittest.TestCase): - def read_file(self, path, **kwargs): - # Isolate from future API changes to readers.read_file - r = Readers(settings=get_settings(**kwargs)) - return r.read_file(base_path=CONTENT_PATH, path=path) - - def test_article_with_asc_extension(self): - # Ensure the asc extension is being processed by the correct reader - page = self.read_file( - path='article_with_asc_extension.asc') - expected = ('
' - '

' - 'Used for pelican test

' - '
' - '
' - '

The quick brown fox jumped over ' - 'the lazy dog’s back.

' - '
') - actual = "".join(page.content.splitlines()) - expected = "".join(expected.splitlines()) - self.assertEqual(actual, expected) - expected = { - 'category': 'Blog', - 'author': 'Author O. Article', - 'title': 'Test AsciiDoc File Header', - 'date': datetime.datetime(2011, 9, 15, 9, 5), - 'tags': ['Linux', 'Python', 'Pelican'], - } - for key, value in expected.items(): - self.assertEqual(value, page.metadata[key], ( - 'Metadata attribute \'%s\' does not match expected value.\n' - 'Expected: %s\n' - 'Actual: %s') % (key, value, page.metadata[key])) - - def test_article_with_asc_options(self): - # test to ensure the ASCIIDOC_OPTIONS is being used - page = self.read_file(path='article_with_asc_options.asc', - ASCIIDOC_OPTIONS=["-a revision=1.0.42"]) - expected = ('
' - '

' - 'Used for pelican test

' - '
' - '
' - '

version 1.0.42

' - '
' - '

The quick brown fox jumped over ' - 'the lazy dog’s back.

' - '
') - actual = "".join(page.content.splitlines()) - expected = "".join(expected.splitlines()) - self.assertEqual(actual, expected) - - -if __name__ == '__main__': - unittest.main() diff --git a/plugins/asciidoc_reader/test_data/article_with_asc_extension.asc b/plugins/asciidoc_reader/test_data/article_with_asc_extension.asc deleted file mode 100644 index 3204d8f..0000000 --- a/plugins/asciidoc_reader/test_data/article_with_asc_extension.asc +++ /dev/null @@ -1,11 +0,0 @@ -Test AsciiDoc File Header -========================= -:Author: Author O. Article -:Email: -:Date: 2011-09-15 09:05 -:Category: Blog -:Tags: Linux, Python, Pelican - -== Used for pelican test - -The quick brown fox jumped over the lazy dog's back. diff --git a/plugins/asciidoc_reader/test_data/article_with_asc_options.asc b/plugins/asciidoc_reader/test_data/article_with_asc_options.asc deleted file mode 100644 index 620abba..0000000 --- a/plugins/asciidoc_reader/test_data/article_with_asc_options.asc +++ /dev/null @@ -1,7 +0,0 @@ -= Test AsciiDoc File Header - -== Used for pelican test - -version {revision} - -The quick brown fox jumped over the lazy dog's back. diff --git a/plugins/category_meta/README.md b/plugins/category_meta/README.md deleted file mode 100644 index 02f909c..0000000 --- a/plugins/category_meta/README.md +++ /dev/null @@ -1,22 +0,0 @@ -Category Metadata ------------------ - -A plugin to read metadata for each category from an index file in that -category's directory. - -For this plugin to work properly, your articles should not have a -Category: tag in their metadata; instead, they should be stored in -(subdirectories of) per-category directories. Each per-category -directory must have a file named 'index.ext' at its top level, where -.ext is any extension that will be picked up by an article reader. -The metadata of that article becomes the metadata for the category, -copied over verbatim, with three special cases: - - * The category's name is set to the article's title. - * The category's slug is set to the name of the parent directory - of the index.ext file. - * The _text_ of the article is stored as category.description. - -You can use this, for example, to control the slug used for each -category independently of its name, or to add a description at the top -of each category page. diff --git a/plugins/category_meta/__init__.py b/plugins/category_meta/__init__.py deleted file mode 100644 index aa50e46..0000000 --- a/plugins/category_meta/__init__.py +++ /dev/null @@ -1 +0,0 @@ -from .category_meta import * diff --git a/plugins/category_meta/category_meta.py b/plugins/category_meta/category_meta.py deleted file mode 100644 index d3dc35a..0000000 --- a/plugins/category_meta/category_meta.py +++ /dev/null @@ -1,130 +0,0 @@ -'''Copyright 2014, 2015 Zack Weinberg - -Category Metadata ------------------ - -A plugin to read metadata for each category from an index file in that -category's directory. - -For this plugin to work properly, your articles should not have a -Category: tag in their metadata; instead, they should be stored in -(subdirectories of) per-category directories. Each per-category -directory must have a file named 'index.ext' at its top level, where -.ext is any extension that will be picked up by an article reader. -The metadata of that article becomes the metadata for the category, -copied over verbatim, with three special cases: - - * The category's name is set to the article's title. - * The category's slug is set to the name of the parent directory - of the index.ext file. - * The _text_ of the article is stored as category.description. -''' - -from pelican import signals -import os -import re - -import logging -logger = logging.getLogger(__name__) - -### CORE BUG: https://github.com/getpelican/pelican/issues/1547 -### Content.url_format does not honor category.slug (or author.slug). -### The sanest way to work around this is to dynamically redefine each -### article's class to a subclass of itself with the bug fixed. -### -### Core was fixed in rev 822fb134e041c6938c253dd4db71813c4d0dc74a, -### which is not yet in any release, so we dynamically detect whether -### the installed version of Pelican still has the bug. - -patched_subclasses = {} -def make_patched_subclass(klass): - if klass.__name__ not in patched_subclasses: - class PatchedContent(klass): - @property - def url_format(self): - metadata = super(PatchedContent, self).url_format - if hasattr(self, 'author'): - metadata['author'] = self.author.slug - if hasattr(self, 'category'): - metadata['category'] = self.category.slug - - return metadata - # Code in core uses Content class names as keys for things. - PatchedContent.__name__ = klass.__name__ - patched_subclasses[klass.__name__] = PatchedContent - return patched_subclasses[klass.__name__] - -def patch_urlformat(cont): - # Test whether this content object needs to be patched. - md = cont.url_format - if ((hasattr(cont, 'author') and cont.author.slug != md['author']) or - (hasattr(cont, 'category') and cont.category.slug != md['category'])): - logger.debug("Detected bug 1547, applying workaround.") - cont.__class__ = make_patched_subclass(cont.__class__) - -### END OF BUG WORKAROUND - -def make_category(article, slug): - # Reuse the article's existing category object. - category = article.category - - # Setting a category's name resets its slug, so do that first. - category.name = article.title - category.slug = slug - category.summary = article.summary - - # Description from article text. - # XXX Relative URLs in the article content may not be handled correctly. - setattr(category, 'description', article.content) - - # Metadata, to the extent that this makes sense. - for k, v in article.metadata.items(): - if k not in ('path', 'slug', 'category', 'name', 'title', - 'description', 'reader'): - setattr(category, k, v) - - logger.debug("Category: %s -> %s", category.slug, category.name) - return category - -def pretaxonomy_hook(generator): - """This hook is invoked before the generator's .categories property is - filled in. Each article has already been assigned a category - object, but these objects are _not_ unique per category and so are - not safe to tack metadata onto (as is). - - The category metadata we're looking for is represented as an - Article object, one per directory, whose filename is 'index.ext'. - """ - - category_objects = {} - real_articles = [] - - for article in generator.articles: - dirname, fname = os.path.split(article.source_path) - fname, _ = os.path.splitext(fname) - if fname == 'index': - category_objects[dirname] = \ - make_category(article, os.path.basename(dirname)) - else: - real_articles.append(article) - - category_assignment = \ - re.compile("^(" + - "|".join(re.escape(prefix) - for prefix in category_objects.keys()) + - ")/") - - for article in real_articles: - m = category_assignment.match(article.source_path) - if not m or m.group(1) not in category_objects: - logger.error("No category assignment for %s (%s)", - article, article.source_path) - continue - - article.category = category_objects[m.group(1)] - patch_urlformat(article) - - generator.articles = real_articles - -def register(): - signals.article_generator_pretaxonomy.connect(pretaxonomy_hook) diff --git a/plugins/filetime_from_git/README.rst b/plugins/filetime_from_git/README.rst deleted file mode 100644 index 9290cb2..0000000 --- a/plugins/filetime_from_git/README.rst +++ /dev/null @@ -1,60 +0,0 @@ -Use Git commit to determine page date -====================================== -If the blog content is managed by git repo, this plugin will set articles' -and pages' ``metadata['date']`` according to git commit. This plugin depends -on python package ``gitpython``, install:: - - pip install gitpython - -The date is determined via the following logic: - -* if a file is not tracked by Git, or a file is staged but never committed - - metadata['date'] = filesystem time - - metadata['modified'] = filesystem time -* if a file is tracked, but no changes in staging area or working directory - - metadata['date'] = first commit time - - metadata['modified'] = last commit time -* if a file is tracked, and has changes in stage area or working directory - - metadata['date'] = first commit time - - metadata['modified'] = filesystem time - -When this module is enabled, ``date`` and ``modified`` will be determined -by Git status; no need to manually set in article/page metadata. And -operations like copy and move will not affect the generated results. - -If you don't want a given article or page to use the Git time, set the -metadata to ``gittime: off`` to disable it. - -Other options -------------- - -### GIT_HISTORY_FOLLOWS_RENAME (default True) -You can also set GIT_HISTORY_FOLLOWS_RENAME to True in your pelican config to -make the plugin follow file renames i.e. ensure the creation date matches -the original file creation date, not the date is was renamed. - -### GIT_GENERATE_PERMALINK (default False) -Use in combination with permalink plugin to generate permalinks using the original -commit sha - -### GIT_SHA_METADATA (default True) -Adds sha of current and oldest commit to metadata - -### GIT_FILETIME_FROM_GIT (default True) -Enable filetime from git behaviour - -Content specific options ------------------------- -Adding metadata `gittime` = False will prevent the plugin trying to setting filetime for this -content. - -Adding metadata `git_permalink` = False will prevent the plugin from adding permalink for this -content. - -FAQ ---- - -### Q. I get a GitCommandError: 'git rev-list ...' when I run the plugin. What's up? -Be sure to use the correct gitpython module for your distros git binary. -Using the GIT_HISTORY_FOLLOWS_RENAME option to True may also make your problem go away as it uses -a different method to find commits. diff --git a/plugins/filetime_from_git/__init__.py b/plugins/filetime_from_git/__init__.py deleted file mode 100644 index b7281c8..0000000 --- a/plugins/filetime_from_git/__init__.py +++ /dev/null @@ -1 +0,0 @@ -from .registration import * diff --git a/plugins/filetime_from_git/actions.py b/plugins/filetime_from_git/actions.py deleted file mode 100755 index c9ac0a8..0000000 --- a/plugins/filetime_from_git/actions.py +++ /dev/null @@ -1,108 +0,0 @@ -# -*- coding: utf-8 -*- -import base64 -import hashlib -import os -import logging -from pelican.utils import strftime -from .utils import string_to_bool -from .utils import datetime_from_timestamp -from .registration import content_git_object_init - - -logger = logging.getLogger(__name__) - - -@content_git_object_init.connect -def filetime_from_git(content, git_content): - ''' - Update modification and creation times from git - ''' - if not content.settings['GIT_FILETIME_FROM_GIT']: - # Disabled for everything - return - - if not string_to_bool(content.metadata.get('gittime', 'yes')): - # Disable for this content - return - - path = content.source_path - fs_creation_time = datetime_from_timestamp(os.stat(path).st_ctime, content) - fs_modified_time = datetime_from_timestamp(os.stat(path).st_mtime, content) - - # 1. file is not managed by git - # date: fs time - # 2. file is staged, but has no commits - # date: fs time - # 3. file is managed, and clean - # date: first commit time, update: last commit time or None - # 4. file is managed, but dirty - # date: first commit time, update: fs time - if git_content.is_managed_by_git(): - if git_content.is_committed(): - content.date = git_content.get_oldest_commit_date() - - if git_content.is_modified(): - content.modified = fs_modified_time - else: - content.modified = git_content.get_newest_commit_date() - else: - # File isn't committed - content.date = fs_creation_time - else: - # file is not managed by git - content.date = fs_creation_time - - # Clean up content attributes - if not hasattr(content, 'modified'): - content.modified = content.date - - if hasattr(content, 'date'): - content.locale_date = strftime(content.date, content.date_format) - - if hasattr(content, 'modified'): - content.locale_modified = strftime( - content.modified, content.date_format) - - -@content_git_object_init.connect -def git_sha_metadata(content, git_content): - ''' - Add sha metadata to content - ''' - if not content.settings['GIT_SHA_METADATA']: - return - - if not git_content.is_committed(): - return - - content.metadata['gitsha_newest'] = str(git_content.get_newest_commit()) - content.metadata['gitsha_oldest'] = str(git_content.get_oldest_commit()) - - -@content_git_object_init.connect -def git_permalink(content, git_content): - ''' - Add git based permalink id to content metadata - ''' - if not content.settings['GIT_GENERATE_PERMALINK']: - return - - if not string_to_bool(content.metadata.get('git_permalink', 'yes')): - # Disable for this content - return - - if not git_content.is_committed(): - return - - permalink_hash = hashlib.sha1() - permalink_hash.update(str(git_content.get_oldest_commit())) - permalink_hash.update(str(git_content.get_oldest_filename())) - git_permalink_id = base64.urlsafe_b64encode(permalink_hash.digest()) - permalink_id_metadata_key = content.settings['PERMALINK_ID_METADATA_KEY'] - - if permalink_id_metadata_key in content.metadata: - content.metadata[permalink_id_metadata_key] = ( - ','.join(( - content.metadata[permalink_id_metadata_key], git_permalink_id))) - else: - content.metadata[permalink_id_metadata_key] = git_permalink_id diff --git a/plugins/filetime_from_git/content_adapter.py b/plugins/filetime_from_git/content_adapter.py deleted file mode 100644 index 1584d17..0000000 --- a/plugins/filetime_from_git/content_adapter.py +++ /dev/null @@ -1,99 +0,0 @@ -# -*- coding: utf-8 -*- -""" -Wraps a content object to provide some git information -""" -import logging -from pelican.utils import memoized -from .git_wrapper import git_wrapper - -DEV_LOGGER = logging.getLogger(__name__) - - -class GitContentAdapter(object): - """ - Wraps a content object to provide some git information - """ - def __init__(self, content): - self.content = content - self.git = git_wrapper('.') - self.tz_name = content.settings.get('TIMEZONE', None) - self.follow = content.settings['GIT_HISTORY_FOLLOWS_RENAME'] - - @memoized - def is_committed(self): - ''' - Is committed - ''' - return len(self.get_commits()) > 0 - - @memoized - def is_modified(self): - ''' - Has content been modified since last commit - ''' - return self.git.is_file_modified(self.content.source_path) - - @memoized - def is_managed_by_git(self): - ''' - Is content stored in a file managed by git - ''' - return self.git.is_file_managed_by_git(self.content.source_path) - - @memoized - def get_commits(self): - ''' - Get all commits involving this filename - :returns: List of commits newest to oldest - ''' - if not self.is_managed_by_git(): - return [] - return self.git.get_commits(self.content.source_path, self.follow) - - @memoized - def get_oldest_commit(self): - ''' - Get oldest commit involving this file - - :returns: Oldest commit - ''' - return self.git.get_commits(self.content.source_path, self.follow)[-1] - - @memoized - def get_newest_commit(self): - ''' - Get oldest commit involving this file - - :returns: Newest commit - ''' - return self.git.get_commits(self.content.source_path, follow=False)[0] - - @memoized - def get_oldest_filename(self): - ''' - Get the original filename of this content. Implies follow - ''' - commit_and_name_iter = self.git.get_commits_and_names_iter( - self.content.source_path) - _commit, name = commit_and_name_iter.next() - return name - - @memoized - def get_oldest_commit_date(self): - ''' - Get datetime of oldest commit involving this file - - :returns: Datetime of oldest commit - ''' - oldest_commit = self.get_oldest_commit() - return self.git.get_commit_date(oldest_commit, self.tz_name) - - @memoized - def get_newest_commit_date(self): - ''' - Get datetime of newest commit involving this file - - :returns: Datetime of newest commit - ''' - newest_commit = self.get_newest_commit() - return self.git.get_commit_date(newest_commit, self.tz_name) diff --git a/plugins/filetime_from_git/git_wrapper.py b/plugins/filetime_from_git/git_wrapper.py deleted file mode 100644 index 238e65e..0000000 --- a/plugins/filetime_from_git/git_wrapper.py +++ /dev/null @@ -1,162 +0,0 @@ -# -*- coding: utf-8 -*- -""" -Wrap python git interface for compatibility with older/newer version -""" -try: - from itertools import zip_longest -except ImportError: - from six.moves import zip_longest -import logging -import os -from time import mktime -from datetime import datetime -from pelican.utils import set_date_tzinfo -from git import Git, Repo - -DEV_LOGGER = logging.getLogger(__name__) - - -def grouper(iterable, n, fillvalue=None): - ''' - Collect data into fixed-length chunks or blocks - ''' - # grouper('ABCDEFG', 3, 'x') --> ABC DEF Gxx - args = [iter(iterable)] * n - return zip_longest(fillvalue=fillvalue, *args) - - -class _GitWrapperCommon(object): - ''' - Wrap git module to provide a more stable interface across versions - ''' - def __init__(self, repo_path): - self.git = Git() - self.repo = Repo(os.path.abspath('.')) - - def is_file_managed_by_git(self, path): - ''' - :param path: Path to check - :returns: True if path is managed by git - ''' - status, _stdout, _stderr = self.git.execute( - ['git', 'ls-files', path, '--error-unmatch'], - with_extended_output=True, - with_exceptions=False) - return status == 0 - - def is_file_modified(self, path): - ''' - Does a file have local changes not yet committed - - :returns: True if file has local changes - ''' - status, _stdout, _stderr = self.git.execute( - ['git', 'diff', '--quiet', 'HEAD', path], - with_extended_output=True, - with_exceptions=False) - return status != 0 - - def get_commits_following(self, path): - ''' - Get all commits including path following the file through - renames - - :param path: Path which we will find commits for - :returns: Sequence of commit objects. Newest to oldest - ''' - return [ - commit for commit, _ in self.get_commits_and_names_iter( - path)] - - def get_commits_and_names_iter(self, path): - ''' - Get all commits including a given path following renames - ''' - log_result = self.git.log( - '--pretty=%H', - '--follow', - '--name-only', - '--', - path).splitlines() - - for commit_sha, _, filename in grouper(log_result, 3): - yield self.repo.commit(commit_sha), filename - - def get_commits(self, path, follow=False): - ''' - Get all commits including path - - :param path: Path which we will find commits for - :param bool follow: If True we will follow path through renames - - :returns: Sequence of commit objects. Newest to oldest - ''' - if follow: - return self.get_commits_following(path) - else: - return self._get_commits(path) - - -class _GitWrapperLegacy(_GitWrapperCommon): - def _get_commits(self, path): - ''' - Get all commits including path without following renames - - :param path: Path which we will find commits for - - :returns: Sequence of commit objects. Newest to oldest - ''' - return self.repo.commits(path=path) - - @staticmethod - def get_commit_date(commit, tz_name): - ''' - Get datetime of commit comitted_date - ''' - return set_date_tzinfo( - datetime.fromtimestamp(mktime(commit.committed_date)), - tz_name=tz_name) - - -class _GitWrapper(_GitWrapperCommon): - def _get_commits(self, path): - ''' - Get all commits including path without following renames - - :param path: Path which we will find commits for - - :returns: Sequence of commit objects. Newest to oldest - - .. NOTE :: - If this fails it could be that your gitpython version is out of sync with the git - binary on your distro. Make sure you use the correct gitpython version. - - Alternatively enabling GIT_FILETIME_FOLLOW may also make your problem go away. - ''' - return list(self.repo.iter_commits(paths=path)) - - @staticmethod - def get_commit_date(commit, tz_name): - ''' - Get datetime of commit comitted_date - ''' - return set_date_tzinfo( - datetime.fromtimestamp(commit.committed_date), - tz_name=tz_name) - - -_wrapper_cache = {} - - -def git_wrapper(path): - ''' - Get appropriate wrapper factory and cache instance for path - ''' - path = os.path.abspath(path) - if path not in _wrapper_cache: - if hasattr(Repo, 'commits'): - _wrapper_cache[path] = _GitWrapperLegacy(path) - else: - _wrapper_cache[path] = _GitWrapper(path) - - return _wrapper_cache[path] diff --git a/plugins/filetime_from_git/registration.py b/plugins/filetime_from_git/registration.py deleted file mode 100644 index e91d254..0000000 --- a/plugins/filetime_from_git/registration.py +++ /dev/null @@ -1,30 +0,0 @@ -# -*- coding: utf-8 -*- -""" -Handle registration and setup for plugin -""" -import logging -from blinker import signal -from .content_adapter import GitContentAdapter -from pelican import signals - -DEV_LOGGER = logging.getLogger(__name__) - -content_git_object_init = signal('content_git_object_init') - -def send_content_git_object_init(content): - content_git_object_init.send(content, git_content=GitContentAdapter(content)) - - -def setup_option_defaults(pelican_inst): - pelican_inst.settings.setdefault('GIT_FILETIME_FROM_GIT', True) - pelican_inst.settings.setdefault('GIT_HISTORY_FOLLOWS_RENAME', True) - pelican_inst.settings.setdefault('GIT_SHA_METADATA', True) - pelican_inst.settings.setdefault('GIT_GENERATE_PERMALINK', False) - - -def register(): - signals.content_object_init.connect(send_content_git_object_init) - signals.initialized.connect(setup_option_defaults) - - # Import actions - from . import actions diff --git a/plugins/filetime_from_git/utils.py b/plugins/filetime_from_git/utils.py deleted file mode 100644 index d5bd52f..0000000 --- a/plugins/filetime_from_git/utils.py +++ /dev/null @@ -1,39 +0,0 @@ -# -*- coding: utf-8 -*- -""" -Utility functions -""" -from datetime import datetime -import logging -from pelican.utils import set_date_tzinfo - -DEV_LOGGER = logging.getLogger(__name__) - - -STRING_BOOLS = { - 'yes': True, - 'no': False, - 'true': True, - 'false': False, - '0': False, - '1': True, - 'on': True, - 'off': False, -} - - -def string_to_bool(string): - ''' - Convert a string to a bool based - ''' - return STRING_BOOLS[string.strip().lower()] - - -def datetime_from_timestamp(timestamp, content): - """ - Helper function to add timezone information to datetime, - so that datetime is comparable to other datetime objects in recent versions - that now also have timezone information. - """ - return set_date_tzinfo( - datetime.fromtimestamp(timestamp), - tz_name=content.settings.get('TIMEZONE', None)) diff --git a/plugins/related_posts/Readme.rst b/plugins/related_posts/Readme.rst deleted file mode 100644 index f0456fc..0000000 --- a/plugins/related_posts/Readme.rst +++ /dev/null @@ -1,34 +0,0 @@ -Related posts -------------- - -This plugin adds the ``related_posts`` variable to the article's context. -By default, up to 5 articles are listed. You can customize this value by -defining ``RELATED_POSTS_MAX`` in your settings file:: - - RELATED_POSTS_MAX = 10 - -You can then use the ``article.related_posts`` variable in your templates. -For example:: - - {% if article.related_posts %} - - {% endif %} - - -Your related posts should share a common tag. You can also use ``related_posts:`` in your post's meta data. -The 'related_posts:' meta data works together with your existing slugs:: - - related_posts: slug1, slug2, slug3, ... slugN - -``N`` represents the ``RELATED_POSTS_MAX``. - -Additionally, you can specify:: - - RELATED_POSTS_SKIP_SAME_CATEGORY = True - -in your settings file. With this setting, ``article.related_posts`` will -contain only related posts from categories other than the original article's. diff --git a/plugins/related_posts/__init__.py b/plugins/related_posts/__init__.py deleted file mode 100644 index 057540e..0000000 --- a/plugins/related_posts/__init__.py +++ /dev/null @@ -1 +0,0 @@ -from .related_posts import * diff --git a/plugins/related_posts/related_posts.py b/plugins/related_posts/related_posts.py deleted file mode 100644 index fbb2426..0000000 --- a/plugins/related_posts/related_posts.py +++ /dev/null @@ -1,56 +0,0 @@ -""" -Related posts plugin for Pelican -================================ - -Adds related_posts variable to article's context -""" - -from pelican import signals -from collections import Counter -from itertools import chain - - -def add_related_posts(generator): - # get the max number of entries from settings - # or fall back to default (5) - numentries = generator.settings.get('RELATED_POSTS_MAX', 5) - # Skip all posts in the same category as the article - skipcategory = generator.settings.get('RELATED_POSTS_SKIP_SAME_CATEGORY', False) - for article in chain(generator.articles, generator.drafts): - # set priority in case of forced related posts - if hasattr(article,'related_posts'): - # split slugs - related_posts = article.related_posts.split(',') - posts = [] - # get related articles - for slug in related_posts: - i = 0 - slug = slug.strip() - for a in generator.articles: - if i >= numentries: # break in case there are max related psots - break - if a.slug == slug: - posts.append(a) - i += 1 - - article.related_posts = posts - else: - # no tag, no relation - if not hasattr(article, 'tags'): - continue - - # score = number of common tags - related = chain(*(generator.tags[tag] for tag in article.tags)) - if skipcategory: - related = (other for other in related - if other.category != article.category) - scores = Counter(related) - - # remove itself - scores.pop(article, None) - - article.related_posts = [other for other, count - in scores.most_common(numentries)] - -def register(): - signals.article_generator_finalized.connect(add_related_posts) diff --git a/plugins/tipue_search/README.md b/plugins/tipue_search/README.md deleted file mode 100644 index 1a2d615..0000000 --- a/plugins/tipue_search/README.md +++ /dev/null @@ -1,67 +0,0 @@ -Tipue Search -============ - -A Pelican plugin to serialize generated HTML to JSON that can be used by jQuery plugin - Tipue Search. - -Copyright (c) Talha Mansoor - -Author | Talha Mansoor -----------------|----- -Author Email | talha131@gmail.com -Author Homepage | http://onCrashReboot.com -Github Account | https://github.com/talha131 - -Why do you need it? -=================== - -Static sites do not offer search feature out of the box. [Tipue Search](http://www.tipue.com/search/) -is a jQuery plugin that search the static site without using any third party service, like DuckDuckGo or Google. - -Tipue Search offers 4 search modes. Its [JSON search mode](http://www.tipue.com/search/docs/json/) is the best search mode -especially for large sites. - -Tipue's JSON search mode requires the textual content of site in JSON format. - -Requirements -============ - -Tipue Search requires BeautifulSoup. - -```bash -pip install beautifulsoup4 -``` - -How Tipue Search works -========================= - -Tipue Search serializes the generated HTML into JSON. Format of JSON is as follows - -```python -{ - "pages": [ - { - "text": "Lorem ipsum dolor sit amet, consectetur adipiscing elit. Integer nec odio. Praesent libero. Sed cursus ante dapibus diam. Sed nisi. Nulla quis sem at nibh elementum imperdiet. Duis sagittis ipsum. Praesent mauris. Fusce nec tellus sed augue semper porta. Mauris massa. Vestibulum lacinia arcu eget nulla. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos himenaeos. Curabitur sodales ligula in libero.", - "tags": "Example Category", - "url" : "http://oncrashreboot.com/plugin-example.html", - "title": "Everything you want to know about Lorem Ipsum" - }, - { - "text": "Sed dignissim lacinia nunc. Curabitur tortor. Pellentesque nibh. Aenean quam. In scelerisque sem at dolor. Maecenas mattis. Sed convallis tristique sem. Proin ut ligula vel nunc egestas porttitor. Morbi lectus risus, iaculis vel, suscipit quis, luctus non, massa. Fusce ac turpis quis ligula lacinia aliquet. Mauris ipsum. Nulla metus metus, ullamcorper vel, tincidunt sed, euismod in, nibh.", - "tags": "Example Category", - "url" : "http://oncrashreboot.com/plugin-example-2.html", - "title": "Review of the book Lorem Ipsum" - } - ] -} -``` - -JSON is written to file `tipuesearch_content.json` which is created in the root of `output` directory. - -How to use -========== - -To utilize JSON Search mode, your theme needs to have Tipue Search properly configured in it. [Official documentation](http://www.tipue.com/search/docs/#json) has the required details. - -Pelican [Elegant Theme](https://github.com/talha131/pelican-elegant) and [Plumage -theme](https://github.com/kdeldycke/plumage) have Tipue Search configured. You can view their -code to understand the configuration. diff --git a/plugins/tipue_search/__init__.py b/plugins/tipue_search/__init__.py deleted file mode 100644 index ebd6c06..0000000 --- a/plugins/tipue_search/__init__.py +++ /dev/null @@ -1 +0,0 @@ -from .tipue_search import * diff --git a/plugins/tipue_search/tipue_search.py b/plugins/tipue_search/tipue_search.py deleted file mode 100644 index a54e9da..0000000 --- a/plugins/tipue_search/tipue_search.py +++ /dev/null @@ -1,114 +0,0 @@ -# -*- coding: utf-8 -*- -""" -Tipue Search -============ - -A Pelican plugin to serialize generated HTML to JSON -that can be used by jQuery plugin - Tipue Search. - -Copyright (c) Talha Mansoor -""" - -from __future__ import unicode_literals - -import os.path -import json -from bs4 import BeautifulSoup -from codecs import open -try: - from urlparse import urljoin -except ImportError: - from urllib.parse import urljoin - -from pelican import signals - - -class Tipue_Search_JSON_Generator(object): - - def __init__(self, context, settings, path, theme, output_path, *null): - - self.output_path = output_path - self.context = context - self.siteurl = settings.get('SITEURL') - self.tpages = settings.get('TEMPLATE_PAGES') - self.output_path = output_path - self.json_nodes = [] - - - def create_json_node(self, page): - - if getattr(page, 'status', 'published') != 'published': - return - - soup_title = BeautifulSoup(page.title.replace(' ', ' '), 'html.parser') - page_title = soup_title.get_text(' ', strip=True).replace('“', '"').replace('”', '"').replace('’', "'").replace('^', '^') - - soup_text = BeautifulSoup(page.content, 'html.parser') - page_text = soup_text.get_text(' ', strip=True).replace('“', '"').replace('”', '"').replace('’', "'").replace('¶', ' ').replace('^', '^') - page_text = ' '.join(page_text.split()) - - if getattr(page, 'category', 'None') == 'None': - page_category = '' - else: - page_category = page.category.name - - page_url = self.siteurl + '/' + page.url - - node = {'title': page_title, - 'text': page_text, - 'tags': page_category, - 'url': page_url} - - self.json_nodes.append(node) - - - def create_tpage_node(self, srclink): - - srcfile = open(os.path.join(self.output_path, self.tpages[srclink]), encoding='utf-8') - soup = BeautifulSoup(srcfile, 'html.parser') - page_text = soup.get_text() - - # What happens if there is not a title. - if soup.title is not None: - page_title = soup.title.string - else: - page_title = '' - - # Should set default category? - page_category = '' - - page_url = urljoin(self.siteurl, self.tpages[srclink]) - - node = {'title': page_title, - 'text': page_text, - 'tags': page_category, - 'url': page_url} - - self.json_nodes.append(node) - - - def generate_output(self, writer): - path = os.path.join(self.output_path, 'tipuesearch_content.json') - - pages = self.context['pages'] + self.context['articles'] - - for article in self.context['articles']: - pages += article.translations - - for srclink in self.tpages: - self.create_tpage_node(srclink) - - for page in pages: - self.create_json_node(page) - root_node = {'pages': self.json_nodes} - - with open(path, 'w', encoding='utf-8') as fd: - json.dump(root_node, fd, separators=(',', ':'), ensure_ascii=False) - - -def get_generators(generators): - return Tipue_Search_JSON_Generator - - -def register(): - signals.get_generators.connect(get_generators) diff --git a/preview.sh b/preview.sh new file mode 100755 index 0000000..4270107 --- /dev/null +++ b/preview.sh @@ -0,0 +1,18 @@ +#!/bin/sh + +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 "" + cd ./public + python3 -m http.server 8080 +fi diff --git a/publishconf.py b/publishconf.py deleted file mode 100644 index 85ff8ef..0000000 --- a/publishconf.py +++ /dev/null @@ -1,24 +0,0 @@ -#!/usr/bin/env python -# -*- coding: utf-8 -*- # -from __future__ import unicode_literals - -# This file is only used if you use `make publish` or -# explicitly specify it as your config file. - -import os -import sys -sys.path.append(os.curdir) -from pelicanconf import * - -SITEURL = '' -RELATIVE_URLS = False - -FEED_ALL_ATOM = 'feeds/all.atom.xml' -CATEGORY_FEED_ATOM = 'feeds/%s.atom.xml' - -DELETE_OUTPUT_DIRECTORY = True - -# Following items are often useful when publishing - -#DISQUS_SITENAME = "" -#GOOGLE_ANALYTICS = "" diff --git a/site.yml b/site.yml new file mode 100644 index 0000000..2dc4185 --- /dev/null +++ b/site.yml @@ -0,0 +1,20 @@ +site: + title: Local Preview + start_page: package-maintainers::index +content: + sources: + - url: . + branches: HEAD +ui: + bundle: + url: https://asamalik.fedorapeople.org/ui-bundle.zip + snapshot: true + default_layout: with_menu +output: + clean: true + dir: ./public + destinations: + - provider: archive +runtime: + pull: true + cache_dir: ./cache diff --git a/theme/static/asciibinder.css b/theme/static/asciibinder.css deleted file mode 100644 index f5a220c..0000000 --- a/theme/static/asciibinder.css +++ /dev/null @@ -1,590 +0,0 @@ -@import url(https://maxcdn.bootstrapcdn.com/font-awesome/4.1.0/css/font-awesome.min.css); -/* ------------------------------------------------------------ -Image: "Spin" https://www.flickr.com/photos/eflon/3655695161/ -Author: eflon https://www.flickr.com/photos/eflon/ -License: https://creativecommons.org/licenses/by/2.0/ ----------------------------------------------------------------*/ -.attribution { - text-align: center; - position: relative; - bottom: -20px; -} -.attribution .btn { - color: #808080; - color: rgba(175,175,175, .65); - font-size: 11px; -} -.attribution .btn:hover { - text-decoration: none; - color: #aaa; -} -.popover-content { - font-size: 12px; - line-height: 1.3; - font-weight: normal; -} - -@media screen and (max-width: 980px) { - body { - margin-bottom: 200px; - } - footer { - text-align: center; - } - footer .text-right { - text-align: center !important; - } - #footer_social .first { - margin-left: 0; - } - #footer_social > a { - top: 24px; - } -} - -.fa-inverse:hover { - color: #ccc; -} - -.collapse a.active { - background-color: #DEEAF4; - color: #000; - position: relative; -} - -.collapse a.active:hover { - text-decoration: none; -} - -.collapse a.active:before { - background-color: #A0C3E5; - content: ""; - display: inline-block; - height: 100%; - left: 0; - position: absolute; - top: 0; - width: 3px; -} - -.main h2, .main .h2 { - border-top: 0px; - padding-top: 10px; - font-size: 28px; -} - -.page-header .img-responsive { - display: inline; -} - -.docs-content h1, -.docs-content h2, -.docs-content h3, -.docs-content h4, -.docs-content h5, -.docs-content h6 - { - font-weight: bold; - color: #444; -} - -.docs-content h1{ - font-size: 1.5rem -} -.docs-content h2{ - font-size: 1.3rem -} -.docs-content h3{ - font-size: 1.1rem -} -.docs-content h4, -.docs-content h5, -.docs-content h6{ - font-size: 1rem; -} - -.docs-content .page-header h1 { - line-height: 1.5rem; - padding-bottom: 0.2em; - margin-bottom: 0.7em; - border-bottom: 1px solid #ccc; - -} - - -nav .breadcrumb{ - background: none; - font-size:0.8em; - padding-left:10px; - padding-bottom:0px; -} - -.nav > li > a.hover{ - background-color: none; -} - -.breadcrumb-item + .breadcrumb-item::before{ - content: '\f054'; - font-family: FontAwesome; - font-size: 0.8em; -} - -h1, h2, h3, h4, h5, h6, .h1, .h2, .h3, .h4, .h5, .h6 { - position: relative; -} - -h2 > a.anchor, h3 > a.anchor, h4 > a.anchor, h5 > a.anchor, h6 > a.anchor { - display: block; - font-weight: normal; - margin-left: -1.5ex; - position: absolute; - text-align: center; - text-decoration: none !important; - visibility: hidden; - width: 1.5ex; - z-index: 1001; -} - -h2 > a.anchor:before, h3 > a.anchor:before, h4 > a.anchor:before, h5 > a.anchor:before, h6 > a.anchor:before { - content: "\f0c1"; - display: block; - font-family: FontAwesome; - font-size: 0.7em; - -webkit-font-smoothing: antialiased; - -moz-osx-font-smoothing: grayscale; - padding-top: 0.2em; -} - -h4 > a.anchor:before, h5 > a.anchor:before, h6 > a.anchor:before { - font-size: 1em; -} - -h2:hover > a.anchor, -h2 > a.anchor:hover, -h3:hover > a.anchor, -h3 > a.anchor:hover, -h4:hover > a.anchor, -h4 > a.anchor:hover, -h5:hover > a.anchor, -h5 > a.anchor:hover, -h6:hover > a.anchor, -h6 > a.anchor:hover { - visibility: visible; -} - -.main { - border-left: 1px solid #e7e7e7; - margin-left: -1px; - padding-left: 25px; -} - - -@media (min-width: 768px) { - .main { - padding-left: 30px; - } -} - -.masthead, .footer{ - position: relative; - z-index: 1; -} - -.footer a{ - color:#aaa -} - -.footer{ - font-size:0.8em; -} - -.footer h3{ - font-size:1.3em; - font-weight: bold; - text-transform: uppercase; -} - -/* - * Sidebar - */ - - .docs-sidebar{ - background: #eee; - box-shadow: -3000px 0 0 3000px #eee; - } - -.nav-header { - font-size: 16px; -} - -.nav-header ul { - font-size: 14px; - padding-left:1em; -} - -.nav-header ul li a { - display: block; - padding: 3px 0px 4px 7px; - font-size: 13px; - font-weight: normal; -} - -.nav-sidebar .fa { - text-align: center; - top: -1px; - width: 14px; -} - -.docs-sidebar li a { - color: #555; -} - -.nav-sidebar li a:hover { - color: #000; -} - -.nav-sidebar ul li ul.nav-tertiary li a { - padding-left: 50px; -} - -.nav-sidebar > li > a { - padding: 7px 0; -} - -.nav-sidebar > li > a:focus, .nav-sidebar > li > a:hover { - background: transparent; -} - -.sidebar { - font-weight: 300; - display: none; - padding-top: 13px; -} - -@media screen and (max-width: 767px) { - .sidebar { - padding-left: 30px; - padding-right: 0; - } -} - -@media screen and (min-width: 768px) { - .sidebar { - border-right: 1px solid #e7e7e7; - display: block; - } -} - - /* Remnants of Asciidoctor default stylesheet - remove styles as needed */ - -#map_canvas img, #map_canvas embed, #map_canvas object, .map_canvas img, .map_canvas embed, .map_canvas object { max-width: none !important; } -.left { float: left !important; } -.right { float: right !important; } -.text-left { text-align: left !important; } -.text-right { text-align: right !important; } -.text-center { text-align: center !important; } -.text-justify { text-align: justify !important; } -.hide { display: none; } -.subheader, #content #toctitle, .admonitionblock td.content > .title, .audioblock > .title, .exampleblock > .title, .imageblock > .title, .listingblock > .title, .literalblock > .title, .stemblock > .title, .openblock > .title, .paragraph > .title, .quoteblock > .title, table.tableblock > .title, .verseblock > .title, .videoblock > .title, .dlist > .title, .olist > .title, .ulist > .title, .qlist > .title, .hdlist > .title { line-height: 1.4; color: #7a2518; font-weight: 300; margin-top: 0.2em; margin-bottom: 0.5em; } -abbr, acronym { text-transform: uppercase; font-size: 90%; color: #333333; border-bottom: 1px dotted #dddddd; cursor: help; } -abbr { text-transform: none; } -blockquote { margin: 0 0 1.25em; padding: 0.5625em 1.25em 0 1.1875em; border-left: 3px solid #487c58; } -blockquote cite { display: block; font-size: inherit; color: #454545; } -blockquote cite:before { content: "\2014 \0020"; } -blockquote cite a, blockquote cite a:visited { color: #454545; } -blockquote, blockquote p { line-height: 1.6; color: #6e6e6e; } -@media only screen and (min-width: 768px) { - #toctitle, .sidebarblock > .content > .title { line-height: 1.4; } - #toctitle, .sidebarblock > .content > .title { font-size: 1.6875em; } -} -table { background: white; margin-bottom: 1.25em; border: solid 1px #dddddd; } -table thead, table tfoot { background: whitesmoke; font-weight: bold; } -table thead tr th, table thead tr td, table tfoot tr th, table tfoot tr td { padding: 0.5em 0.625em 0.625em; font-size: inherit; color: #333333; text-align: left; } -table tr th, table tr td { padding: 0.5625em 0.625em; font-size: inherit; color: #333333; } -table tr.even, table tr.alt, table tr:nth-of-type(even) { background: #f9f9f9; } -table thead tr th, table tfoot tr th, table tbody tr td, table tr td, table tfoot tr td { display: table-cell; line-height: 1.6; } -.clearfix:before, .clearfix:after, .float-group:before, .float-group:after { content: " "; display: table; } -.clearfix:after, .float-group:after { clear: both; } -*:not(pre) > code { font-size: inherit; padding: 0; white-space: nowrap; background-color: inherit; border: 0 solid #dddddd; -webkit-border-radius: 4px; border-radius: 4px; text-shadow: none; line-height: 1; } -.keyseq { color: #666666; } -kbd:not(.keyseq) { display: inline-block; color: #333333; font-size: 0.75em; line-height: 1.4; background-color: #f7f7f7; border: 1px solid #ccc; -webkit-border-radius: 3px; border-radius: 3px; -webkit-box-shadow: 0 1px 0 rgba(0, 0, 0, 0.2), 0 0 0 2px white inset; box-shadow: 0 1px 0 rgba(0, 0, 0, 0.2), 0 0 0 2px white inset; margin: -0.15em 0.15em 0 0.15em; padding: 0.2em 0.6em 0.2em 0.5em; vertical-align: middle; white-space: nowrap; } -.keyseq kbd:first-child { margin-left: 0; } -.keyseq kbd:last-child { margin-right: 0; } -.menuseq, .menu { color: #1a1a1a; } -b.button:before, b.button:after { position: relative; top: -1px; font-weight: normal; } -b.button:before { content: "["; padding: 0 3px 0 2px; } -b.button:after { content: "]"; padding: 0 2px 0 3px; } -p a > code:hover { color: #561309; } -#header, #content, #footnotes, #footer { width: 100%; margin-left: auto; margin-right: auto; margin-top: 0; margin-bottom: 0; max-width: 62.5em; *zoom: 1; position: relative; padding-left: 0.9375em; padding-right: 0.9375em; } -#header:before, #header:after, #content:before, #content:after, #footnotes:before, #footnotes:after, #footer:before, #footer:after { content: " "; display: table; } -#header:after, #content:after, #footnotes:after, #footer:after { clear: both; } -#content:before { content: none; } -#header { margin-bottom: 2.5em; } -#header > h1 { color: black; font-weight: 300; border-bottom: 1px solid #d8d8d8; margin-bottom: -28px; padding-bottom: 32px; } -#header span { color: #6e6e6e; } -#header #revnumber { text-transform: capitalize; } -#header br { display: none; } -#header br + span { padding-left: 3px; } -#header br + span:before { content: "\2013 \0020"; } -#header br + span.author { padding-left: 0; } -#header br + span.author:before { content: ", "; } -#toc { border-bottom: 3px double #e5e5e5; padding-top: 1em; padding-bottom: 1.25em; } -#toc > ul { margin-left: 0.25em; } -#toc ul.sectlevel0 > li > a { font-style: italic; } -#toc ul.sectlevel0 ul.sectlevel1 { margin-left: 0; margin-top: 0.5em; margin-bottom: 0.5em; } -#toc ul { font-family: "Open Sans", "DejaVu Sans", "Sans", sans-serif; list-style-type: none; } -#toc a { text-decoration: none; } -#toc a:active { text-decoration: underline; } -#toctitle { color: #7a2518; } -@media only screen and (min-width: 768px) { body.toc2 { padding-left: 15em; padding-right: 0; } - #toc.toc2 { background-color: #fafaf9; position: fixed; width: 15em; left: 0; top: 0; border-right: 1px solid #e5e5e5; border-bottom: 0; z-index: 1000; padding: 1.25em 1em; height: 100%; overflow: auto; } - #toc.toc2 #toctitle { margin-top: 0; font-size: 1.2em; } - #toc.toc2 > ul { font-size: .90em; margin-bottom: 0; } - #toc.toc2 ul ul { margin-left: 0; padding-left: 1em; } - #toc.toc2 ul.sectlevel0 ul.sectlevel1 { padding-left: 0; margin-top: 0.5em; margin-bottom: 0.5em; } - body.toc2.toc-right { padding-left: 0; padding-right: 15em; } - body.toc2.toc-right #toc.toc2 { border-right: 0; border-left: 1px solid #e5e5e5; left: auto; right: 0; } } -@media only screen and (min-width: 1280px) { body.toc2 { padding-left: 20em; padding-right: 0; } - #toc.toc2 { width: 20em; } - #toc.toc2 #toctitle { font-size: 1.375em; } - #toc.toc2 > ul { font-size: 0.95em; } - #toc.toc2 ul ul { padding-left: 1.25em; } - body.toc2.toc-right { padding-left: 0; padding-right: 20em; } } -#content #toc { border-style: solid; border-width: 1px; border-color: #e3e3dd; margin-bottom: 1.25em; padding: 1.25em; background: #fafaf9; border-width: 0; -webkit-border-radius: 4px; border-radius: 4px; } -#content #toc > :first-child { margin-top: 0; } -#content #toc > :last-child { margin-bottom: 0; } -#content #toctitle { font-size: 1.375em; } -#footer { max-width: 100%; background-color: #333333; padding: 1.25em; } -#footer-text { color: #cccccc; line-height: 1.44; } -.audioblock, .imageblock, .literalblock, .listingblock, .stemblock, .verseblock, .videoblock { margin-bottom: 2.5em; } -.admonitionblock td.content > .title, .audioblock > .title, .exampleblock > .title, .imageblock > .title, .listingblock > .title, .literalblock > .title, .stemblock > .title, .openblock > .title, .paragraph > .title, .quoteblock > .title, table.tableblock > .title, .verseblock > .title, .videoblock > .title, .dlist > .title, .olist > .title, .ulist > .title, .qlist > .title, .hdlist > .title { text-rendering: optimizeLegibility; text-align: left; font-family: "Noto Serif", "DejaVu Serif", "Serif", serif; font-weight: normal; font-style: italic; } -table.tableblock > caption.title { white-space: nowrap; overflow: visible; max-width: 0; } -table.tableblock #preamble > .sectionbody > .paragraph:first-of-type p { font-size: inherit; } -.admonitionblock > table { border: 0; background: none; width: 100%; } -.admonitionblock > table td.icon { text-align: center; width: 80px; } -.admonitionblock > table td.icon img { max-width: none; } -.admonitionblock > table td.icon .title { font-weight: 300; text-transform: uppercase; } -.admonitionblock > table td.content { padding-left: 0; padding-right: 1.25em; color: #6e6e6e; } -.admonitionblock > table td.content > :last-child > :last-child { margin-bottom: 0; } -.exampleblock > .content { border-style: solid; border-width: 1px; border-color: #e6e6e6; margin-bottom: 1.25em; padding: 1.25em; background: white; -webkit-border-radius: 4px; border-radius: 4px; } -.exampleblock > .content > :first-child { margin-top: 0; } -.exampleblock > .content > :last-child { margin-bottom: 0; } -.exampleblock > .content h1, .exampleblock > .content h2, .exampleblock > .content h3, .exampleblock > .content #toctitle, .sidebarblock.exampleblock > .content > .title, .exampleblock > .content h4, .exampleblock > .content h5, .exampleblock > .content h6, .exampleblock > .content p { color: #333333; } -.exampleblock > .content h1, .exampleblock > .content h2, .exampleblock > .content h3, .exampleblock > .content #toctitle, .sidebarblock.exampleblock > .content > .title, .exampleblock > .content h4, .exampleblock > .content h5, .exampleblock > .content h6 { line-height: 1; margin-bottom: 0.625em; } -.exampleblock > .content h1.subheader, .exampleblock > .content h2.subheader, .exampleblock > .content h3.subheader, .exampleblock > .content .subheader#toctitle, .sidebarblock.exampleblock > .content > .subheader.title, .exampleblock > .content h4.subheader, .exampleblock > .content h5.subheader, .exampleblock > .content h6.subheader { line-height: 1.4; } -.exampleblock.result > .content { -webkit-box-shadow: 0 1px 8px #e3e3dd; box-shadow: 0 1px 8px #e3e3dd; } -.sidebarblock { border-style: solid; border-width: 1px; border-color: #e3e3dd; margin-top: -1.0em; margin-bottom: 1.6em; margin-left: 1em; padding: .5em; background: #F1F3F5; -webkit-border-radius: 4px; border-radius: 4px; overflow-x: auto; float: right; width: 40%; } -.sidebarblock > :first-child { margin-top: 0; } -.sidebarblock > :last-child { margin-bottom: 0; } -.sidebarblock h1, .sidebarblock h2, .sidebarblock h3, .sidebarblock #toctitle, .sidebarblock > .content > .title, .sidebarblock h4, .sidebarblock h5, .sidebarblock h6, .sidebarblock p { color: #333333; } -.sidebarblock h1, .sidebarblock h2, .sidebarblock h3, .sidebarblock #toctitle, .sidebarblock > .content > .title, .sidebarblock h4, .sidebarblock h5, .sidebarblock h6 { line-height: 1; margin-bottom: 0.625em; } -.sidebarblock h1.subheader, .sidebarblock h2.subheader, .sidebarblock h3.subheader, .sidebarblock .subheader#toctitle, .sidebarblock > .content > .subheader.title, .sidebarblock h4.subheader, .sidebarblock h5.subheader, .sidebarblock h6.subheader { line-height: 1.4; } -.sidebarblock > .content > .title { color: inherit; font-size: 28px; font-weight: 500; margin-top: 0; line-height: 1.6; } -.width50 { width: 50% ! important} -.exampleblock > .content > :last-child > :last-child, .exampleblock > .content .olist > ol > li:last-child > :last-child, .exampleblock > .content .ulist > ul > li:last-child > :last-child, .exampleblock > .content .qlist > ol > li:last-child > :last-child, .sidebarblock > .content > :last-child > :last-child, .sidebarblock > .content .olist > ol > li:last-child > :last-child, .sidebarblock > .content .ulist > ul > li:last-child > :last-child, .sidebarblock > .content .qlist > ol > li:last-child > :last-child { margin-bottom: 0; } -.literalblock pre, .literalblock pre[class], .listingblock pre, .listingblock pre[class] { border: 0px; background-color: #F0F3F5; -webkit-border-radius: 5px; border-radius: 5px; padding: 1.5em 2.5em; word-wrap: break-word; } -.literalblock pre.nowrap, .literalblock pre[class].nowrap, .listingblock pre.nowrap, .listingblock pre[class].nowrap { overflow-x: auto; white-space: pre; word-wrap: normal; } -.literalblock pre > code, .literalblock pre[class] > code, .listingblock pre > code, .listingblock pre[class] > code { display: block; } -.listingblock > .content { position: relative; } -.listingblock:hover code[class*=" language-"]:before { text-transform: uppercase; font-size: 0.9em; color: #999; position: absolute; top: 0.375em; right: 0.375em; } -.listingblock:hover code.asciidoc:before { content: "asciidoc"; } -.listingblock:hover code.clojure:before { content: "clojure"; } -.listingblock:hover code.css:before { content: "css"; } -.listingblock:hover code.go:before { content: "go"; } -.listingblock:hover code.groovy:before { content: "groovy"; } -.listingblock:hover code.html:before { content: "html"; } -.listingblock:hover code.java:before { content: "java"; } -.listingblock:hover code.javascript:before { content: "javascript"; } -.listingblock:hover code.python:before { content: "python"; } -.listingblock:hover code.ruby:before { content: "ruby"; } -.listingblock:hover code.sass:before { content: "sass"; } -.listingblock:hover code.scss:before { content: "scss"; } -.listingblock:hover code.xml:before { content: "xml"; } -.listingblock:hover code.yaml:before { content: "yaml"; } -.listingblock.terminal pre .command:before { content: attr(data-prompt); padding-right: 0.5em; color: #999; } -.listingblock.terminal pre .command:not([data-prompt]):before { content: '$'; } -table.pyhltable { border: 0; margin-bottom: 0; } -table.pyhltable td { vertical-align: top; padding-top: 0; padding-bottom: 0; } -table.pyhltable td.code { padding-left: .75em; padding-right: 0; } -.highlight.pygments .lineno, table.pyhltable td:not(.code) { color: #999; padding-left: 0; padding-right: .5em; border-right: 1px solid #d8d8d8; } -.highlight.pygments .lineno { display: inline-block; margin-right: .25em; } -table.pyhltable .linenodiv { background-color: transparent !important; padding-right: 0 !important; } -.quoteblock { margin: 0 0 1.25em 0; padding: 0.5625em 1.25em 0 1.1875em; border-left: 3px solid #487c58; } -.quoteblock blockquote { margin: 0 0 1.25em 0; padding: 0 0 0.625em 0; border: 0; } -.quoteblock blockquote > .paragraph:last-child p { margin-bottom: 0; } -.quoteblock .attribution { margin-top: -0.625em; padding-bottom: 0.625em; font-size: inherit; color: #454545; line-height: 1.6; } -.quoteblock .attribution br { display: none; } -.quoteblock .attribution cite { display: block; } -table.tableblock { max-width: 100%; } -table.tableblock td .paragraph:last-child p > p:last-child, table.tableblock th > p:last-child, table.tableblock td > p:last-child { margin-bottom: 0; } -table.spread { width: 100%; } -table.tableblock, th.tableblock, td.tableblock { border: 0 solid #dddddd; } -table.grid-all th.tableblock, table.grid-all td.tableblock { border-width: 0 1px 1px 0; } -table.grid-all tfoot > tr > th.tableblock, table.grid-all tfoot > tr > td.tableblock { border-width: 1px 1px 0 0; } -table.grid-cols th.tableblock, table.grid-cols td.tableblock { border-width: 0 1px 0 0; } -table.grid-all * > tr > .tableblock:last-child, table.grid-cols * > tr > .tableblock:last-child { border-right-width: 0; } -table.grid-rows th.tableblock, table.grid-rows td.tableblock { border-width: 0 0 1px 0; } -table.grid-all tbody > tr:last-child > th.tableblock, table.grid-all tbody > tr:last-child > td.tableblock, table.grid-all thead:last-child > tr > th.tableblock, table.grid-rows tbody > tr:last-child > th.tableblock, table.grid-rows tbody > tr:last-child > td.tableblock, table.grid-rows thead:last-child > tr > th.tableblock { border-bottom-width: 0; } -table.grid-rows tfoot > tr > th.tableblock, table.grid-rows tfoot > tr > td.tableblock { border-width: 1px 0 0 0; } -table.frame-all { border-width: 1px; } -table.frame-sides { border-width: 0 1px; } -table.frame-topbot { border-width: 1px 0; } -th.halign-left, td.halign-left { text-align: left; } -th.halign-right, td.halign-right { text-align: right; } -th.halign-center, td.halign-center { text-align: center; } -th.valign-top, td.valign-top { vertical-align: top; } -th.valign-bottom, td.valign-bottom { vertical-align: bottom; } -th.valign-middle, td.valign-middle { vertical-align: middle; } -table thead th, table tfoot th { font-weight: bold; } -tbody tr th { display: table-cell; line-height: 1.6; background: whitesmoke; } -tbody tr th, tbody tr th p, tfoot tr th, tfoot tr th p { color: #333333; font-weight: bold; } -td > div.verse { white-space: pre; } -ul.unstyled, ol.unnumbered, ul.checklist, ul.none { list-style-type: none; } -ul.unstyled, ol.unnumbered, ul.checklist { margin-left: 0.625em; } -ul.checklist li > p:first-child > .fa-check-square-o:first-child, ul.checklist li > p:first-child > input[type="checkbox"]:first-child { margin-right: 0.25em; } -ul.checklist li > p:first-child > input[type="checkbox"]:first-child { position: relative; top: 1px; } -ul.inline { margin: 0 auto 0.625em auto; margin-left: -1.375em; margin-right: 0; padding: 0; list-style: none; overflow: hidden; } -ul.inline > li { list-style: none; float: left; margin-left: 1.375em; display: block; } -ul.inline > li > * { display: block; } -.unstyled dl dt { font-weight: normal; font-style: normal; } -ol.arabic { list-style-type: decimal; } -ol.decimal { list-style-type: decimal-leading-zero; } -ol.loweralpha { list-style-type: lower-alpha; } -ol.upperalpha { list-style-type: upper-alpha; } -ol.lowerroman { list-style-type: lower-roman; } -ol.upperroman { list-style-type: upper-roman; } -ol.lowergreek { list-style-type: lower-greek; } -.hdlist > table, .colist > table { border: 0; background: none; } -.hdlist > table > tbody > tr, .colist > table > tbody > tr { background: none; } -td.hdlist1 { padding-right: .75em; font-weight: bold; } -td.hdlist1, td.hdlist2 { vertical-align: top; } -.literalblock + .colist, .listingblock + .colist { margin-top: -0.5em; } -.colist > table tr > td:first-of-type { padding: 0 .75em; line-height: 1; } -.colist > table tr > td:last-of-type { padding: 0.25em 0; } -.qanda > ol > li > p > em:only-child { color: #1d4b8f; } -.thumb, .th { line-height: 0; display: inline-block; border: solid 4px white; -webkit-box-shadow: 0 0 0 1px #dddddd; box-shadow: 0 0 0 1px #dddddd; } -.imageblock.left, .imageblock[style*="float: left"] { margin: 0.25em 0.625em 1.25em 0; } -.imageblock.right, .imageblock[style*="float: right"] { margin: 0.25em 0 1.25em 0.625em; } -.imageblock > .title { margin-bottom: 0; } -.imageblock.thumb, .imageblock.th { border-width: 6px; } -.imageblock.thumb > .title, .imageblock.th > .title { padding: 0 0.125em; } -.image.left, .image.right { margin-top: 0.25em; margin-bottom: 0.25em; display: inline-block; line-height: 0; } -.image.left { margin-right: 0.625em; } -.image.right { margin-left: 0.625em; } -a.image { text-decoration: none; } -span.footnote, span.footnoteref { vertical-align: super; font-size: 0.875em; } -span.footnote a, span.footnoteref a { text-decoration: none; } -span.footnote a:active, span.footnoteref a:active { text-decoration: underline; } -#footnotes { padding-top: 0.75em; padding-bottom: 0.75em; margin-bottom: 0.625em; } -#footnotes hr { width: 20%; min-width: 6.25em; margin: -.25em 0 .75em 0; border-width: 1px 0 0 0; } -#footnotes .footnote { padding: 0 0.375em; line-height: 1.3; font-size: 0.875em; margin-left: 1.2em; text-indent: -1.2em; margin-bottom: .2em; } -#footnotes .footnote a:first-of-type { font-weight: bold; text-decoration: none; } -#footnotes .footnote:last-of-type { margin-bottom: 0; } -#content #footnotes { margin-top: -0.625em; margin-bottom: 0; padding: 0.75em 0; } -.gist .file-data > table { border: none; background: #fff; width: 100%; margin-bottom: 0; } -.gist .file-data > table td.line-data { width: 99%; } -div.unbreakable { page-break-inside: avoid; } -.replaceable { font-style: italic; font-color: inherit; font-family: inherit; } -.parameter { font-style: italic; font-family: monospace; } -.userinput { font-weight: bold; font-family: monospace; } -.envar { font-weight: bold; font-family: monospace; font-size: 90%; } -.sysitem { font-weight: bold; font-size: 90%; } -.package { font-weight: bold; font-size: 90%; } -.filename { font-weight: bold; font-style: italic; font-size: 90%; } -.big { font-size: larger; } -.small { font-size: smaller; } -.underline { text-decoration: underline; } -.overline { text-decoration: overline; } -.line-through { text-decoration: line-through; } -.aqua { color: #00bfbf; } -.aqua-background { background-color: #00fafa; } -.black { color: black; } -.black-background { background-color: black; } -.blue { color: #0000bf; } -.blue-background { background-color: #0000fa; } -.fuchsia { color: #bf00bf; } -.fuchsia-background { background-color: #fa00fa; } -.gray { color: #606060; } -.gray-background { background-color: #7d7d7d; } -.green { color: #006000; } -.green-background { background-color: #007d00; } -.lime { color: #00bf00; } -.lime-background { background-color: #00fa00; } -.maroon { color: #600000; } -.maroon-background { background-color: #7d0000; } -.navy { color: #000060; } -.navy-background { background-color: #00007d; } -.olive { color: #606000; } -.olive-background { background-color: #7d7d00; } -.purple { color: #600060; } -.purple-background { background-color: #7d007d; } -.red { color: #bf0000; } -.red-background { background-color: #fa0000; } -.silver { color: #909090; } -.silver-background { background-color: #bcbcbc; } -.teal { color: #006060; } -.teal-background { background-color: #007d7d; } -.white { color: #bfbfbf; } -.white-background { background-color: #fafafa; } -.yellow { color: #bfbf00; } -.yellow-background { background-color: #fafa00; } -span.icon > .fa { cursor: default; } -.admonitionblock td.icon [class^="fa icon-"] { font-size: 2.5em; cursor: default; } -.admonitionblock td.icon .icon-note:before { content: "\f05a"; color: #4E9FDD; } -.admonitionblock td.icon .icon-tip:before { content: "\f0eb"; color: #2C8596; } -.admonitionblock td.icon .icon-warning:before { content: "\f071"; color: #ec7a08; } -.admonitionblock td.icon .icon-caution:before { content: "\f06d"; color: #ec7a08; } -.admonitionblock td.icon .icon-important:before { content: "\f06a"; color: #c00; } -.conum[data-value] { display: inline-block; color: white !important; background-color: #333333; -webkit-border-radius: 100px; border-radius: 100px; text-align: center; width: 20px; height: 20px; font-size: 12px; line-height: 20px; font-family: "Open Sans", "Sans", sans-serif; font-style: normal; font-weight: bold; text-indent: -1px; } -.conum[data-value] * { color: white !important; } -.conum[data-value] + b { display: none; } -.conum[data-value]:after { content: attr(data-value); } -pre .conum[data-value] { position: relative; top: -2px; } -b.conum * { color: inherit !important; } -.conum:not([data-value]):empty { display: none; } -.print-only { display: none !important; } -@media print { @page { margin: 1.25cm 0.75cm; } - * { -webkit-box-shadow: none !important; box-shadow: none !important; text-shadow: none !important; } - a, a:visited { color: inherit !important; text-decoration: underline !important; } - a[href^="http:"]:after, a[href^="https:"]:after { content: " (" attr(href) ")"; } - a[href^="#"], a[href^="#"]:visited, a[href^="mailto:"], a[href^="mailto:"]:visited { text-decoration: none !important; } - abbr[title]:after { content: " (" attr(title) ")"; } - pre, blockquote { page-break-inside: avoid; } - code { color: #191919; } - thead { display: table-header-group; } - tr, img { page-break-inside: avoid; } - img { max-width: 100% !important; } - p { orphans: 3; widows: 3; } - h2, h3, #toctitle, .sidebarblock > .content > .title, #toctitle, .sidebarblock > .content > .title { page-break-after: avoid; } - #toc, .sidebarblock { background: none !important; } - #toc { border-bottom: 1px solid #d8d8d8 !important; padding-bottom: 0 !important; } - .sect1 { padding-bottom: 0 !important; } - .sect1 + .sect1 { border: none !important; } - body.book #header { text-align: center; } - body.book #header > h1 { border: none !important; margin: 2.5em 0 1em 0; padding: 0; } - body.book #header span { line-height: 1.6; } - body.book #header br { display: block; } - body.book #header br + span { padding-left: 0; } - body.book #header br + span:before { content: none !important; } - body.book #toc { border: none !important; text-align: left !important; padding: 0 !important; } - #footer { background: none !important; } - #footer-text { color: #333333 !important; } - .hide-on-print { display: none !important; } - .print-only { display: block !important; } - .hide-for-print { display: none !important; } - .show-for-print { display: inherit !important; } } - -.corner-ribbon{ - width: 16em; - background: #3c6eb4 ; - position: absolute; - top: 3em; - right: -4em; - text-align: center; - line-height: 5ex; - color: #dedede; - transform: rotate(45deg); - -webkit-transform: rotate(45deg); - z-index: 999; -} -.corner-ribbon a { color: #FFFFFF; } diff --git a/theme/static/docs-fedora-logo.png b/theme/static/docs-fedora-logo.png deleted file mode 100644 index 5e6ff6f..0000000 Binary files a/theme/static/docs-fedora-logo.png and /dev/null differ diff --git a/theme/static/docs-fedora-logo.svg b/theme/static/docs-fedora-logo.svg deleted file mode 100644 index 5570116..0000000 --- a/theme/static/docs-fedora-logo.svg +++ /dev/null @@ -1,133 +0,0 @@ - - - - - - - - - - image/svg+xml - - - - - - - - - DOCUMENTATION - - - - - - - - - - - - - - - - diff --git a/theme/static/docs-fedora.css b/theme/static/docs-fedora.css deleted file mode 100644 index 62eb15b..0000000 --- a/theme/static/docs-fedora.css +++ /dev/null @@ -1,115 +0,0 @@ -.tipue_search_content_title{ - margin-top:1em; -} - - -.tipue_search_content_url{ - display:none; -} - -.tipue_search_content_text{ - font-size:0.8em; -} - -.tipue_search_content_bold{ - font-weight:bold; - background-color: #4fcafa -} - -.entry-content img {max-width:100%;} -.entry-content h1 {font-size:1.3em; font-weight: bold;} - -.bodycontent-sidebar{ - background: linear-gradient(90deg, #FFF 50%, #EEE 50%); -} - -.bodycontent, .left-pane{ - min-height:500px; -} - -.badge-sidebar{ - width:100%; - font-size:1em; - margin-top:0.3em; - text-align:left; -} - -.badge-tagfilter{ - font-size:0.9em; - margin:0.1em; -} - -.badge-default{ - color: #666; -} - -.badge{ -padding: 0.5em; -} -.sidebar{ - font-size:0.8em; -} - -.header-sidebar{ - font-weight:bold; - color:#555; -} - -.notblue, .entry-title a{ - color:inherit; -} - -.entry-title{ - font-weight:bold; -} - -.tagsort-active{ - background-color: #5cb85c; - color: white; -} - -.tagsort-tag{ - cursor:pointer; -} - -.footer a{ - color:#aaa - } - - .footer{ - font-size:0.8em; - } - - .footer h3{ - font-size:1.3em; - font-weight: bold; - text-transform: uppercase; - } - - nav .breadcrumb{ - background: none; - font-size:0.8em; - padding-left:10px; - padding-bottom:0px; - } - - .nav > li > a.hover{ - background-color: none; - } - - .breadcrumb-item + .breadcrumb-item::before{ - content: '\f054'; - font-family: FontAwesome; - font-size: 0.8em; - color: #868e96; - } - - .qd-toc li{ - line-height:1em; - padding-top: 0.6em; - } - - .qd-toc li a{ - color:#444; - font-weight: 400; - } \ No newline at end of file diff --git a/theme/static/docs_logo.png b/theme/static/docs_logo.png deleted file mode 100644 index 90421ec..0000000 Binary files a/theme/static/docs_logo.png and /dev/null differ diff --git a/theme/static/fedora-bootstrap.css b/theme/static/fedora-bootstrap.css deleted file mode 100644 index 9022466..0000000 --- a/theme/static/fedora-bootstrap.css +++ /dev/null @@ -1,6340 +0,0 @@ -/*fedora-bootstrap v1.0.3 -- https://pagure.io/fedora-bootstrap */ -/*! - * Bootstrap v4.0.0-alpha.6 (https://getbootstrap.com) - * Copyright 2011-2017 The Bootstrap Authors - * Copyright 2011-2017 Twitter, Inc. - * Licensed under MIT (https://github.com/twbs/bootstrap/blob/master/LICENSE) - */ -/*! normalize.css v5.0.0 | MIT License | github.com/necolas/normalize.css */ -html { - font-family: sans-serif; - line-height: 1.15; - -ms-text-size-adjust: 100%; - -webkit-text-size-adjust: 100%; } - -body { - margin: 0; } - -article, -aside, -footer, -header, -nav, -section { - display: block; } - -h1 { - font-size: 2em; - margin: 0.67em 0; } - -figcaption, -figure, -main { - display: block; } - -figure { - margin: 1em 40px; } - -hr { - box-sizing: content-box; - height: 0; - overflow: visible; } - -pre { - font-family: monospace, monospace; - font-size: 1em; } - -a { - background-color: transparent; - -webkit-text-decoration-skip: objects; } - -a:active, -a:hover { - outline-width: 0; } - -abbr[title] { - border-bottom: none; - text-decoration: underline; - text-decoration: underline dotted; } - -b, -strong { - font-weight: inherit; } - -b, -strong { - font-weight: bolder; } - -code, -kbd, -samp { - font-family: monospace, monospace; - font-size: 1em; } - -dfn { - font-style: italic; } - -mark { - background-color: #ff0; - color: #000; } - -small { - font-size: 80%; } - -sub, -sup { - font-size: 75%; - line-height: 0; - position: relative; - vertical-align: baseline; } - -sub { - bottom: -0.25em; } - -sup { - top: -0.5em; } - -audio, -video { - display: inline-block; } - -audio:not([controls]) { - display: none; - height: 0; } - -img { - border-style: none; } - -svg:not(:root) { - overflow: hidden; } - -button, -input, -optgroup, -select, -textarea { - font-family: sans-serif; - font-size: 100%; - line-height: 1.15; - margin: 0; } - -button, -input { - overflow: visible; } - -button, -select { - text-transform: none; } - -button, -html [type="button"], -[type="reset"], -[type="submit"] { - -webkit-appearance: button; } - -button::-moz-focus-inner, -[type="button"]::-moz-focus-inner, -[type="reset"]::-moz-focus-inner, -[type="submit"]::-moz-focus-inner { - border-style: none; - padding: 0; } - -button:-moz-focusring, -[type="button"]:-moz-focusring, -[type="reset"]:-moz-focusring, -[type="submit"]:-moz-focusring { - outline: 1px dotted ButtonText; } - -fieldset { - border: 1px solid #c0c0c0; - margin: 0 2px; - padding: 0.35em 0.625em 0.75em; } - -legend { - box-sizing: border-box; - color: inherit; - display: table; - max-width: 100%; - padding: 0; - white-space: normal; } - -progress { - display: inline-block; - vertical-align: baseline; } - -textarea { - overflow: auto; } - -[type="checkbox"], -[type="radio"] { - box-sizing: border-box; - padding: 0; } - -[type="number"]::-webkit-inner-spin-button, -[type="number"]::-webkit-outer-spin-button { - height: auto; } - -[type="search"] { - -webkit-appearance: textfield; - outline-offset: -2px; } - -[type="search"]::-webkit-search-cancel-button, -[type="search"]::-webkit-search-decoration { - -webkit-appearance: none; } - -::-webkit-file-upload-button { - -webkit-appearance: button; - font: inherit; } - -details, -menu { - display: block; } - -summary { - display: list-item; } - -canvas { - display: inline-block; } - -template { - display: none; } - -[hidden] { - display: none; } - -@media print { - *, - *::before, - *::after, - p::first-letter, - div::first-letter, - blockquote::first-letter, - li::first-letter, - p::first-line, - div::first-line, - blockquote::first-line, - li::first-line { - text-shadow: none !important; - box-shadow: none !important; } - a, - a:visited { - text-decoration: underline; } - abbr[title]::after { - content: " (" attr(title) ")"; } - pre { - white-space: pre-wrap !important; } - pre, - blockquote { - border: 1px solid #999; - page-break-inside: avoid; } - thead { - display: table-header-group; } - tr, - img { - page-break-inside: avoid; } - p, - h2, - h3 { - orphans: 3; - widows: 3; } - h2, - h3 { - page-break-after: avoid; } - .navbar { - display: none; } - .badge { - border: 1px solid #000; } - .table { - border-collapse: collapse !important; } - .table td, - .table th { - background-color: #fff !important; } - .table-bordered th, - .table-bordered td { - border: 1px solid #ddd !important; } } - -html { - box-sizing: border-box; } - -*, -*::before, -*::after { - box-sizing: inherit; } - -@-ms-viewport { - width: device-width; } - -html { - -ms-overflow-style: scrollbar; - -webkit-tap-highlight-color: transparent; } - -body { - font-family: "Open Sans"; - font-size: 1rem; - font-weight: normal; - line-height: 1.5; - color: #373a3c; - background-color: #fff; } - -[tabindex="-1"]:focus { - outline: none !important; } - -h1, h2, h3, h4, h5, h6 { - margin-top: 0; - margin-bottom: .5rem; } - -p { - margin-top: 0; - margin-bottom: 1rem; } - -abbr[title], -abbr[data-original-title] { - cursor: help; } - -address { - margin-bottom: 1rem; - font-style: normal; - line-height: inherit; } - -ol, -ul, -dl { - margin-top: 0; - margin-bottom: 1rem; } - -ol ol, -ul ul, -ol ul, -ul ol { - margin-bottom: 0; } - -dt { - font-weight: bold; } - -dd { - margin-bottom: .5rem; - margin-left: 0; } - -blockquote { - margin: 0 0 1rem; } - -a { - color: #0275d8; - text-decoration: none; } - a:focus, a:hover { - color: #014c8c; - text-decoration: underline; } - -a:not([href]):not([tabindex]) { - color: inherit; - text-decoration: none; } - a:not([href]):not([tabindex]):focus, a:not([href]):not([tabindex]):hover { - color: inherit; - text-decoration: none; } - a:not([href]):not([tabindex]):focus { - outline: 0; } - -pre { - margin-top: 0; - margin-bottom: 1rem; - overflow: auto; } - -figure { - margin: 0 0 1rem; } - -img { - vertical-align: middle; } - -[role="button"] { - cursor: pointer; } - -a, -area, -button, -[role="button"], -input, -label, -select, -summary, -textarea { - touch-action: manipulation; } - -table { - border-collapse: collapse; - background-color: transparent; } - -caption { - padding-top: 0.75rem; - padding-bottom: 0.75rem; - color: #d5d5d5; - text-align: left; - caption-side: bottom; } - -th { - text-align: left; } - -label { - display: inline-block; - margin-bottom: .5rem; } - -button:focus { - outline: 1px dotted; - outline: 5px auto -webkit-focus-ring-color; } - -input, -button, -select, -textarea { - line-height: inherit; } - -input[type="radio"]:disabled, -input[type="checkbox"]:disabled { - cursor: not-allowed; } - -input[type="date"], -input[type="time"], -input[type="datetime-local"], -input[type="month"] { - -webkit-appearance: listbox; } - -textarea { - resize: vertical; } - -fieldset { - min-width: 0; - padding: 0; - margin: 0; - border: 0; } - -legend { - display: block; - width: 100%; - padding: 0; - margin-bottom: .5rem; - font-size: 1.5rem; - line-height: inherit; } - -input[type="search"] { - -webkit-appearance: none; } - -output { - display: inline-block; } - -[hidden] { - display: none !important; } - -h1, h2, h3, h4, h5, h6, -.h1, .h2, .h3, .h4, .h5, .h6 { - margin-bottom: 0.5rem; - font-family: inherit; - font-weight: 500; - line-height: 1.1; - color: inherit; } - -h1, .h1 { - font-size: 2rem; } - -h2, .h2 { - font-size: 1.75rem; } - -h3, .h3 { - font-size: 1.5rem; } - -h4, .h4 { - font-size: 1.25rem; } - -h5, .h5 { - font-size: 1rem; } - -h6, .h6 { - font-size: 1rem; } - -.lead { - font-size: 1.25rem; - font-weight: 300; } - -.display-1 { - font-size: 6rem; - font-weight: 300; - line-height: 1.1; } - -.display-2 { - font-size: 5.5rem; - font-weight: 300; - line-height: 1.1; } - -.display-3 { - font-size: 4.5rem; - font-weight: 300; - line-height: 1.1; } - -.display-4 { - font-size: 3.5rem; - font-weight: 300; - line-height: 1.1; } - -hr { - margin-top: 1rem; - margin-bottom: 1rem; - border: 0; - border-top: 1px solid rgba(0, 0, 0, 0.1); } - -small, -.small { - font-size: 80%; - font-weight: normal; } - -mark, -.mark { - padding: 0.2em; - background-color: #fcf8e3; } - -.list-unstyled { - padding-left: 0; - list-style: none; } - -.list-inline { - padding-left: 0; - list-style: none; } - -.list-inline-item { - display: inline-block; } - .list-inline-item:not(:last-child) { - margin-right: 5px; } - -.initialism { - font-size: 90%; - text-transform: uppercase; } - -.blockquote { - padding: 0.5rem 1rem; - margin-bottom: 1rem; - font-size: 1.25rem; - border-left: 0.25rem solid #eceeef; } - -.blockquote-footer { - display: block; - font-size: 80%; - color: #d5d5d5; } - .blockquote-footer::before { - content: "\2014 \A0"; } - -.blockquote-reverse { - padding-right: 1rem; - padding-left: 0; - text-align: right; - border-right: 0.25rem solid #eceeef; - border-left: 0; } - -.blockquote-reverse .blockquote-footer::before { - content: ""; } - -.blockquote-reverse .blockquote-footer::after { - content: "\A0 \2014"; } - -.img-fluid { - max-width: 100%; - height: auto; } - -.img-thumbnail { - padding: 0.25rem; - background-color: #fff; - border: 1px solid #ddd; - border-radius: 0.25rem; - transition: all 0.2s ease-in-out; - max-width: 100%; - height: auto; } - -.figure { - display: inline-block; } - -.figure-img { - margin-bottom: 0.5rem; - line-height: 1; } - -.figure-caption { - font-size: 90%; - color: #d5d5d5; } - -code, -kbd, -pre, -samp { - font-family: "Hack", monospace; } - -code { - padding: 0.2rem 0.4rem; - font-size: 90%; - color: #bd4147; - background-color: #f3f3f3; - border-radius: 0.25rem; } - a > code { - padding: 0; - color: inherit; - background-color: inherit; } - -kbd { - padding: 0.2rem 0.4rem; - font-size: 90%; - color: #fff; - background-color: #373a3c; - border-radius: 0.2rem; } - kbd kbd { - padding: 0; - font-size: 100%; - font-weight: bold; } - -pre { - display: block; - margin-top: 0; - margin-bottom: 1rem; - font-size: 90%; - color: #586e75; } - pre code { - padding: 0; - font-size: inherit; - color: inherit; - background-color: transparent; - border-radius: 0; } - -.pre-scrollable { - max-height: 340px; - overflow-y: scroll; } - -.container { - position: relative; - margin-left: auto; - margin-right: auto; - padding-right: 15px; - padding-left: 15px; } - @media (min-width: 576px) { - .container { - padding-right: 15px; - padding-left: 15px; } } - @media (min-width: 768px) { - .container { - padding-right: 15px; - padding-left: 15px; } } - @media (min-width: 992px) { - .container { - padding-right: 15px; - padding-left: 15px; } } - @media (min-width: 1200px) { - .container { - padding-right: 15px; - padding-left: 15px; } } - @media (min-width: 576px) { - .container { - width: 540px; - max-width: 100%; } } - @media (min-width: 768px) { - .container { - width: 720px; - max-width: 100%; } } - @media (min-width: 992px) { - .container { - width: 960px; - max-width: 100%; } } - @media (min-width: 1200px) { - .container { - width: 1140px; - max-width: 100%; } } - -.container-fluid { - position: relative; - margin-left: auto; - margin-right: auto; - padding-right: 15px; - padding-left: 15px; } - @media (min-width: 576px) { - .container-fluid { - padding-right: 15px; - padding-left: 15px; } } - @media (min-width: 768px) { - .container-fluid { - padding-right: 15px; - padding-left: 15px; } } - @media (min-width: 992px) { - .container-fluid { - padding-right: 15px; - padding-left: 15px; } } - @media (min-width: 1200px) { - .container-fluid { - padding-right: 15px; - padding-left: 15px; } } - -.row { - display: flex; - flex-wrap: wrap; - margin-right: -15px; - margin-left: -15px; } - @media (min-width: 576px) { - .row { - margin-right: -15px; - margin-left: -15px; } } - @media (min-width: 768px) { - .row { - margin-right: -15px; - margin-left: -15px; } } - @media (min-width: 992px) { - .row { - margin-right: -15px; - margin-left: -15px; } } - @media (min-width: 1200px) { - .row { - margin-right: -15px; - margin-left: -15px; } } - -.no-gutters { - margin-right: 0; - margin-left: 0; } - .no-gutters > .col, - .no-gutters > [class*="col-"] { - padding-right: 0; - padding-left: 0; } - -.col-1, .col-2, .col-3, .col-4, .col-5, .col-6, .col-7, .col-8, .col-9, .col-10, .col-11, .col-12, .col, .col-sm-1, .col-sm-2, .col-sm-3, .col-sm-4, .col-sm-5, .col-sm-6, .col-sm-7, .col-sm-8, .col-sm-9, .col-sm-10, .col-sm-11, .col-sm-12, .col-sm, .col-md-1, .col-md-2, .col-md-3, .col-md-4, .col-md-5, .col-md-6, .col-md-7, .col-md-8, .col-md-9, .col-md-10, .col-md-11, .col-md-12, .col-md, .col-lg-1, .col-lg-2, .col-lg-3, .col-lg-4, .col-lg-5, .col-lg-6, .col-lg-7, .col-lg-8, .col-lg-9, .col-lg-10, .col-lg-11, .col-lg-12, .col-lg, .col-xl-1, .col-xl-2, .col-xl-3, .col-xl-4, .col-xl-5, .col-xl-6, .col-xl-7, .col-xl-8, .col-xl-9, .col-xl-10, .col-xl-11, .col-xl-12, .col-xl { - position: relative; - width: 100%; - min-height: 1px; - padding-right: 15px; - padding-left: 15px; } - @media (min-width: 576px) { - .col-1, .col-2, .col-3, .col-4, .col-5, .col-6, .col-7, .col-8, .col-9, .col-10, .col-11, .col-12, .col, .col-sm-1, .col-sm-2, .col-sm-3, .col-sm-4, .col-sm-5, .col-sm-6, .col-sm-7, .col-sm-8, .col-sm-9, .col-sm-10, .col-sm-11, .col-sm-12, .col-sm, .col-md-1, .col-md-2, .col-md-3, .col-md-4, .col-md-5, .col-md-6, .col-md-7, .col-md-8, .col-md-9, .col-md-10, .col-md-11, .col-md-12, .col-md, .col-lg-1, .col-lg-2, .col-lg-3, .col-lg-4, .col-lg-5, .col-lg-6, .col-lg-7, .col-lg-8, .col-lg-9, .col-lg-10, .col-lg-11, .col-lg-12, .col-lg, .col-xl-1, .col-xl-2, .col-xl-3, .col-xl-4, .col-xl-5, .col-xl-6, .col-xl-7, .col-xl-8, .col-xl-9, .col-xl-10, .col-xl-11, .col-xl-12, .col-xl { - padding-right: 15px; - padding-left: 15px; } } - @media (min-width: 768px) { - .col-1, .col-2, .col-3, .col-4, .col-5, .col-6, .col-7, .col-8, .col-9, .col-10, .col-11, .col-12, .col, .col-sm-1, .col-sm-2, .col-sm-3, .col-sm-4, .col-sm-5, .col-sm-6, .col-sm-7, .col-sm-8, .col-sm-9, .col-sm-10, .col-sm-11, .col-sm-12, .col-sm, .col-md-1, .col-md-2, .col-md-3, .col-md-4, .col-md-5, .col-md-6, .col-md-7, .col-md-8, .col-md-9, .col-md-10, .col-md-11, .col-md-12, .col-md, .col-lg-1, .col-lg-2, .col-lg-3, .col-lg-4, .col-lg-5, .col-lg-6, .col-lg-7, .col-lg-8, .col-lg-9, .col-lg-10, .col-lg-11, .col-lg-12, .col-lg, .col-xl-1, .col-xl-2, .col-xl-3, .col-xl-4, .col-xl-5, .col-xl-6, .col-xl-7, .col-xl-8, .col-xl-9, .col-xl-10, .col-xl-11, .col-xl-12, .col-xl { - padding-right: 15px; - padding-left: 15px; } } - @media (min-width: 992px) { - .col-1, .col-2, .col-3, .col-4, .col-5, .col-6, .col-7, .col-8, .col-9, .col-10, .col-11, .col-12, .col, .col-sm-1, .col-sm-2, .col-sm-3, .col-sm-4, .col-sm-5, .col-sm-6, .col-sm-7, .col-sm-8, .col-sm-9, .col-sm-10, .col-sm-11, .col-sm-12, .col-sm, .col-md-1, .col-md-2, .col-md-3, .col-md-4, .col-md-5, .col-md-6, .col-md-7, .col-md-8, .col-md-9, .col-md-10, .col-md-11, .col-md-12, .col-md, .col-lg-1, .col-lg-2, .col-lg-3, .col-lg-4, .col-lg-5, .col-lg-6, .col-lg-7, .col-lg-8, .col-lg-9, .col-lg-10, .col-lg-11, .col-lg-12, .col-lg, .col-xl-1, .col-xl-2, .col-xl-3, .col-xl-4, .col-xl-5, .col-xl-6, .col-xl-7, .col-xl-8, .col-xl-9, .col-xl-10, .col-xl-11, .col-xl-12, .col-xl { - padding-right: 15px; - padding-left: 15px; } } - @media (min-width: 1200px) { - .col-1, .col-2, .col-3, .col-4, .col-5, .col-6, .col-7, .col-8, .col-9, .col-10, .col-11, .col-12, .col, .col-sm-1, .col-sm-2, .col-sm-3, .col-sm-4, .col-sm-5, .col-sm-6, .col-sm-7, .col-sm-8, .col-sm-9, .col-sm-10, .col-sm-11, .col-sm-12, .col-sm, .col-md-1, .col-md-2, .col-md-3, .col-md-4, .col-md-5, .col-md-6, .col-md-7, .col-md-8, .col-md-9, .col-md-10, .col-md-11, .col-md-12, .col-md, .col-lg-1, .col-lg-2, .col-lg-3, .col-lg-4, .col-lg-5, .col-lg-6, .col-lg-7, .col-lg-8, .col-lg-9, .col-lg-10, .col-lg-11, .col-lg-12, .col-lg, .col-xl-1, .col-xl-2, .col-xl-3, .col-xl-4, .col-xl-5, .col-xl-6, .col-xl-7, .col-xl-8, .col-xl-9, .col-xl-10, .col-xl-11, .col-xl-12, .col-xl { - padding-right: 15px; - padding-left: 15px; } } - -.col { - flex-basis: 0; - flex-grow: 1; - max-width: 100%; } - -.col-auto { - flex: 0 0 auto; - width: auto; } - -.col-1 { - flex: 0 0 8.33333%; - max-width: 8.33333%; } - -.col-2 { - flex: 0 0 16.66667%; - max-width: 16.66667%; } - -.col-3 { - flex: 0 0 25%; - max-width: 25%; } - -.col-4 { - flex: 0 0 33.33333%; - max-width: 33.33333%; } - -.col-5 { - flex: 0 0 41.66667%; - max-width: 41.66667%; } - -.col-6 { - flex: 0 0 50%; - max-width: 50%; } - -.col-7 { - flex: 0 0 58.33333%; - max-width: 58.33333%; } - -.col-8 { - flex: 0 0 66.66667%; - max-width: 66.66667%; } - -.col-9 { - flex: 0 0 75%; - max-width: 75%; } - -.col-10 { - flex: 0 0 83.33333%; - max-width: 83.33333%; } - -.col-11 { - flex: 0 0 91.66667%; - max-width: 91.66667%; } - -.col-12 { - flex: 0 0 100%; - max-width: 100%; } - -.pull-0 { - right: auto; } - -.pull-1 { - right: 8.33333%; } - -.pull-2 { - right: 16.66667%; } - -.pull-3 { - right: 25%; } - -.pull-4 { - right: 33.33333%; } - -.pull-5 { - right: 41.66667%; } - -.pull-6 { - right: 50%; } - -.pull-7 { - right: 58.33333%; } - -.pull-8 { - right: 66.66667%; } - -.pull-9 { - right: 75%; } - -.pull-10 { - right: 83.33333%; } - -.pull-11 { - right: 91.66667%; } - -.pull-12 { - right: 100%; } - -.push-0 { - left: auto; } - -.push-1 { - left: 8.33333%; } - -.push-2 { - left: 16.66667%; } - -.push-3 { - left: 25%; } - -.push-4 { - left: 33.33333%; } - -.push-5 { - left: 41.66667%; } - -.push-6 { - left: 50%; } - -.push-7 { - left: 58.33333%; } - -.push-8 { - left: 66.66667%; } - -.push-9 { - left: 75%; } - -.push-10 { - left: 83.33333%; } - -.push-11 { - left: 91.66667%; } - -.push-12 { - left: 100%; } - -.offset-1 { - margin-left: 8.33333%; } - -.offset-2 { - margin-left: 16.66667%; } - -.offset-3 { - margin-left: 25%; } - -.offset-4 { - margin-left: 33.33333%; } - -.offset-5 { - margin-left: 41.66667%; } - -.offset-6 { - margin-left: 50%; } - -.offset-7 { - margin-left: 58.33333%; } - -.offset-8 { - margin-left: 66.66667%; } - -.offset-9 { - margin-left: 75%; } - -.offset-10 { - margin-left: 83.33333%; } - -.offset-11 { - margin-left: 91.66667%; } - -@media (min-width: 576px) { - .col-sm { - flex-basis: 0; - flex-grow: 1; - max-width: 100%; } - .col-sm-auto { - flex: 0 0 auto; - width: auto; } - .col-sm-1 { - flex: 0 0 8.33333%; - max-width: 8.33333%; } - .col-sm-2 { - flex: 0 0 16.66667%; - max-width: 16.66667%; } - .col-sm-3 { - flex: 0 0 25%; - max-width: 25%; } - .col-sm-4 { - flex: 0 0 33.33333%; - max-width: 33.33333%; } - .col-sm-5 { - flex: 0 0 41.66667%; - max-width: 41.66667%; } - .col-sm-6 { - flex: 0 0 50%; - max-width: 50%; } - .col-sm-7 { - flex: 0 0 58.33333%; - max-width: 58.33333%; } - .col-sm-8 { - flex: 0 0 66.66667%; - max-width: 66.66667%; } - .col-sm-9 { - flex: 0 0 75%; - max-width: 75%; } - .col-sm-10 { - flex: 0 0 83.33333%; - max-width: 83.33333%; } - .col-sm-11 { - flex: 0 0 91.66667%; - max-width: 91.66667%; } - .col-sm-12 { - flex: 0 0 100%; - max-width: 100%; } - .pull-sm-0 { - right: auto; } - .pull-sm-1 { - right: 8.33333%; } - .pull-sm-2 { - right: 16.66667%; } - .pull-sm-3 { - right: 25%; } - .pull-sm-4 { - right: 33.33333%; } - .pull-sm-5 { - right: 41.66667%; } - .pull-sm-6 { - right: 50%; } - .pull-sm-7 { - right: 58.33333%; } - .pull-sm-8 { - right: 66.66667%; } - .pull-sm-9 { - right: 75%; } - .pull-sm-10 { - right: 83.33333%; } - .pull-sm-11 { - right: 91.66667%; } - .pull-sm-12 { - right: 100%; } - .push-sm-0 { - left: auto; } - .push-sm-1 { - left: 8.33333%; } - .push-sm-2 { - left: 16.66667%; } - .push-sm-3 { - left: 25%; } - .push-sm-4 { - left: 33.33333%; } - .push-sm-5 { - left: 41.66667%; } - .push-sm-6 { - left: 50%; } - .push-sm-7 { - left: 58.33333%; } - .push-sm-8 { - left: 66.66667%; } - .push-sm-9 { - left: 75%; } - .push-sm-10 { - left: 83.33333%; } - .push-sm-11 { - left: 91.66667%; } - .push-sm-12 { - left: 100%; } - .offset-sm-0 { - margin-left: 0%; } - .offset-sm-1 { - margin-left: 8.33333%; } - .offset-sm-2 { - margin-left: 16.66667%; } - .offset-sm-3 { - margin-left: 25%; } - .offset-sm-4 { - margin-left: 33.33333%; } - .offset-sm-5 { - margin-left: 41.66667%; } - .offset-sm-6 { - margin-left: 50%; } - .offset-sm-7 { - margin-left: 58.33333%; } - .offset-sm-8 { - margin-left: 66.66667%; } - .offset-sm-9 { - margin-left: 75%; } - .offset-sm-10 { - margin-left: 83.33333%; } - .offset-sm-11 { - margin-left: 91.66667%; } } - -@media (min-width: 768px) { - .col-md { - flex-basis: 0; - flex-grow: 1; - max-width: 100%; } - .col-md-auto { - flex: 0 0 auto; - width: auto; } - .col-md-1 { - flex: 0 0 8.33333%; - max-width: 8.33333%; } - .col-md-2 { - flex: 0 0 16.66667%; - max-width: 16.66667%; } - .col-md-3 { - flex: 0 0 25%; - max-width: 25%; } - .col-md-4 { - flex: 0 0 33.33333%; - max-width: 33.33333%; } - .col-md-5 { - flex: 0 0 41.66667%; - max-width: 41.66667%; } - .col-md-6 { - flex: 0 0 50%; - max-width: 50%; } - .col-md-7 { - flex: 0 0 58.33333%; - max-width: 58.33333%; } - .col-md-8 { - flex: 0 0 66.66667%; - max-width: 66.66667%; } - .col-md-9 { - flex: 0 0 75%; - max-width: 75%; } - .col-md-10 { - flex: 0 0 83.33333%; - max-width: 83.33333%; } - .col-md-11 { - flex: 0 0 91.66667%; - max-width: 91.66667%; } - .col-md-12 { - flex: 0 0 100%; - max-width: 100%; } - .pull-md-0 { - right: auto; } - .pull-md-1 { - right: 8.33333%; } - .pull-md-2 { - right: 16.66667%; } - .pull-md-3 { - right: 25%; } - .pull-md-4 { - right: 33.33333%; } - .pull-md-5 { - right: 41.66667%; } - .pull-md-6 { - right: 50%; } - .pull-md-7 { - right: 58.33333%; } - .pull-md-8 { - right: 66.66667%; } - .pull-md-9 { - right: 75%; } - .pull-md-10 { - right: 83.33333%; } - .pull-md-11 { - right: 91.66667%; } - .pull-md-12 { - right: 100%; } - .push-md-0 { - left: auto; } - .push-md-1 { - left: 8.33333%; } - .push-md-2 { - left: 16.66667%; } - .push-md-3 { - left: 25%; } - .push-md-4 { - left: 33.33333%; } - .push-md-5 { - left: 41.66667%; } - .push-md-6 { - left: 50%; } - .push-md-7 { - left: 58.33333%; } - .push-md-8 { - left: 66.66667%; } - .push-md-9 { - left: 75%; } - .push-md-10 { - left: 83.33333%; } - .push-md-11 { - left: 91.66667%; } - .push-md-12 { - left: 100%; } - .offset-md-0 { - margin-left: 0%; } - .offset-md-1 { - margin-left: 8.33333%; } - .offset-md-2 { - margin-left: 16.66667%; } - .offset-md-3 { - margin-left: 25%; } - .offset-md-4 { - margin-left: 33.33333%; } - .offset-md-5 { - margin-left: 41.66667%; } - .offset-md-6 { - margin-left: 50%; } - .offset-md-7 { - margin-left: 58.33333%; } - .offset-md-8 { - margin-left: 66.66667%; } - .offset-md-9 { - margin-left: 75%; } - .offset-md-10 { - margin-left: 83.33333%; } - .offset-md-11 { - margin-left: 91.66667%; } } - -@media (min-width: 992px) { - .col-lg { - flex-basis: 0; - flex-grow: 1; - max-width: 100%; } - .col-lg-auto { - flex: 0 0 auto; - width: auto; } - .col-lg-1 { - flex: 0 0 8.33333%; - max-width: 8.33333%; } - .col-lg-2 { - flex: 0 0 16.66667%; - max-width: 16.66667%; } - .col-lg-3 { - flex: 0 0 25%; - max-width: 25%; } - .col-lg-4 { - flex: 0 0 33.33333%; - max-width: 33.33333%; } - .col-lg-5 { - flex: 0 0 41.66667%; - max-width: 41.66667%; } - .col-lg-6 { - flex: 0 0 50%; - max-width: 50%; } - .col-lg-7 { - flex: 0 0 58.33333%; - max-width: 58.33333%; } - .col-lg-8 { - flex: 0 0 66.66667%; - max-width: 66.66667%; } - .col-lg-9 { - flex: 0 0 75%; - max-width: 75%; } - .col-lg-10 { - flex: 0 0 83.33333%; - max-width: 83.33333%; } - .col-lg-11 { - flex: 0 0 91.66667%; - max-width: 91.66667%; } - .col-lg-12 { - flex: 0 0 100%; - max-width: 100%; } - .pull-lg-0 { - right: auto; } - .pull-lg-1 { - right: 8.33333%; } - .pull-lg-2 { - right: 16.66667%; } - .pull-lg-3 { - right: 25%; } - .pull-lg-4 { - right: 33.33333%; } - .pull-lg-5 { - right: 41.66667%; } - .pull-lg-6 { - right: 50%; } - .pull-lg-7 { - right: 58.33333%; } - .pull-lg-8 { - right: 66.66667%; } - .pull-lg-9 { - right: 75%; } - .pull-lg-10 { - right: 83.33333%; } - .pull-lg-11 { - right: 91.66667%; } - .pull-lg-12 { - right: 100%; } - .push-lg-0 { - left: auto; } - .push-lg-1 { - left: 8.33333%; } - .push-lg-2 { - left: 16.66667%; } - .push-lg-3 { - left: 25%; } - .push-lg-4 { - left: 33.33333%; } - .push-lg-5 { - left: 41.66667%; } - .push-lg-6 { - left: 50%; } - .push-lg-7 { - left: 58.33333%; } - .push-lg-8 { - left: 66.66667%; } - .push-lg-9 { - left: 75%; } - .push-lg-10 { - left: 83.33333%; } - .push-lg-11 { - left: 91.66667%; } - .push-lg-12 { - left: 100%; } - .offset-lg-0 { - margin-left: 0%; } - .offset-lg-1 { - margin-left: 8.33333%; } - .offset-lg-2 { - margin-left: 16.66667%; } - .offset-lg-3 { - margin-left: 25%; } - .offset-lg-4 { - margin-left: 33.33333%; } - .offset-lg-5 { - margin-left: 41.66667%; } - .offset-lg-6 { - margin-left: 50%; } - .offset-lg-7 { - margin-left: 58.33333%; } - .offset-lg-8 { - margin-left: 66.66667%; } - .offset-lg-9 { - margin-left: 75%; } - .offset-lg-10 { - margin-left: 83.33333%; } - .offset-lg-11 { - margin-left: 91.66667%; } } - -@media (min-width: 1200px) { - .col-xl { - flex-basis: 0; - flex-grow: 1; - max-width: 100%; } - .col-xl-auto { - flex: 0 0 auto; - width: auto; } - .col-xl-1 { - flex: 0 0 8.33333%; - max-width: 8.33333%; } - .col-xl-2 { - flex: 0 0 16.66667%; - max-width: 16.66667%; } - .col-xl-3 { - flex: 0 0 25%; - max-width: 25%; } - .col-xl-4 { - flex: 0 0 33.33333%; - max-width: 33.33333%; } - .col-xl-5 { - flex: 0 0 41.66667%; - max-width: 41.66667%; } - .col-xl-6 { - flex: 0 0 50%; - max-width: 50%; } - .col-xl-7 { - flex: 0 0 58.33333%; - max-width: 58.33333%; } - .col-xl-8 { - flex: 0 0 66.66667%; - max-width: 66.66667%; } - .col-xl-9 { - flex: 0 0 75%; - max-width: 75%; } - .col-xl-10 { - flex: 0 0 83.33333%; - max-width: 83.33333%; } - .col-xl-11 { - flex: 0 0 91.66667%; - max-width: 91.66667%; } - .col-xl-12 { - flex: 0 0 100%; - max-width: 100%; } - .pull-xl-0 { - right: auto; } - .pull-xl-1 { - right: 8.33333%; } - .pull-xl-2 { - right: 16.66667%; } - .pull-xl-3 { - right: 25%; } - .pull-xl-4 { - right: 33.33333%; } - .pull-xl-5 { - right: 41.66667%; } - .pull-xl-6 { - right: 50%; } - .pull-xl-7 { - right: 58.33333%; } - .pull-xl-8 { - right: 66.66667%; } - .pull-xl-9 { - right: 75%; } - .pull-xl-10 { - right: 83.33333%; } - .pull-xl-11 { - right: 91.66667%; } - .pull-xl-12 { - right: 100%; } - .push-xl-0 { - left: auto; } - .push-xl-1 { - left: 8.33333%; } - .push-xl-2 { - left: 16.66667%; } - .push-xl-3 { - left: 25%; } - .push-xl-4 { - left: 33.33333%; } - .push-xl-5 { - left: 41.66667%; } - .push-xl-6 { - left: 50%; } - .push-xl-7 { - left: 58.33333%; } - .push-xl-8 { - left: 66.66667%; } - .push-xl-9 { - left: 75%; } - .push-xl-10 { - left: 83.33333%; } - .push-xl-11 { - left: 91.66667%; } - .push-xl-12 { - left: 100%; } - .offset-xl-0 { - margin-left: 0%; } - .offset-xl-1 { - margin-left: 8.33333%; } - .offset-xl-2 { - margin-left: 16.66667%; } - .offset-xl-3 { - margin-left: 25%; } - .offset-xl-4 { - margin-left: 33.33333%; } - .offset-xl-5 { - margin-left: 41.66667%; } - .offset-xl-6 { - margin-left: 50%; } - .offset-xl-7 { - margin-left: 58.33333%; } - .offset-xl-8 { - margin-left: 66.66667%; } - .offset-xl-9 { - margin-left: 75%; } - .offset-xl-10 { - margin-left: 83.33333%; } - .offset-xl-11 { - margin-left: 91.66667%; } } - -.table { - width: 100%; - max-width: 100%; - margin-bottom: 1rem; } - .table th, - .table td { - padding: 0.75rem; - vertical-align: top; - border-top: 1px solid #eceeef; } - .table thead th { - vertical-align: bottom; - border-bottom: 2px solid #eceeef; } - .table tbody + tbody { - border-top: 2px solid #eceeef; } - .table .table { - background-color: #fff; } - -.table-sm th, -.table-sm td { - padding: 0.3rem; } - -.table-bordered { - border: 1px solid #eceeef; } - .table-bordered th, - .table-bordered td { - border: 1px solid #eceeef; } - .table-bordered thead th, - .table-bordered thead td { - border-bottom-width: 2px; } - -.table-striped tbody tr:nth-of-type(odd) { - background-color: rgba(0, 0, 0, 0.05); } - -.table-hover tbody tr:hover { - background-color: rgba(0, 0, 0, 0.075); } - -.table-active, -.table-active > th, -.table-active > td { - background-color: rgba(0, 0, 0, 0.075); } - -.table-hover .table-active:hover { - background-color: rgba(0, 0, 0, 0.075); } - .table-hover .table-active:hover > td, - .table-hover .table-active:hover > th { - background-color: rgba(0, 0, 0, 0.075); } - -.table-success, -.table-success > th, -.table-success > td { - background-color: #dff0d8; } - -.table-hover .table-success:hover { - background-color: #d0e9c6; } - .table-hover .table-success:hover > td, - .table-hover .table-success:hover > th { - background-color: #d0e9c6; } - -.table-info, -.table-info > th, -.table-info > td { - background-color: #d9edf7; } - -.table-hover .table-info:hover { - background-color: #c4e3f3; } - .table-hover .table-info:hover > td, - .table-hover .table-info:hover > th { - background-color: #c4e3f3; } - -.table-warning, -.table-warning > th, -.table-warning > td { - background-color: #fcf8e3; } - -.table-hover .table-warning:hover { - background-color: #faf2cc; } - .table-hover .table-warning:hover > td, - .table-hover .table-warning:hover > th { - background-color: #faf2cc; } - -.table-danger, -.table-danger > th, -.table-danger > td { - background-color: #f2dede; } - -.table-hover .table-danger:hover { - background-color: #ebcccc; } - .table-hover .table-danger:hover > td, - .table-hover .table-danger:hover > th { - background-color: #ebcccc; } - -.thead-inverse th { - color: #fff; - background-color: #373a3c; } - -.thead-default th { - color: #55595c; - background-color: #eceeef; } - -.table-inverse { - color: #fff; - background-color: #373a3c; } - .table-inverse th, - .table-inverse td, - .table-inverse thead th { - border-color: #fff; } - .table-inverse.table-bordered { - border: 0; } - -.table-responsive { - display: block; - width: 100%; - overflow-x: auto; - -ms-overflow-style: -ms-autohiding-scrollbar; } - .table-responsive.table-bordered { - border: 0; } - -.form-control { - display: block; - width: 100%; - padding: 0.5rem 0.75rem; - font-size: 1rem; - line-height: 1.25; - color: #55595c; - background-color: #fff; - background-image: none; - background-clip: padding-box; - border: 1px solid rgba(0, 0, 0, 0.15); - border-radius: 0.25rem; - transition: border-color ease-in-out 0.15s, box-shadow ease-in-out 0.15s; } - .form-control::-ms-expand { - background-color: transparent; - border: 0; } - .form-control:focus { - color: #55595c; - background-color: #fff; - border-color: #5cb3fd; - outline: none; } - .form-control::placeholder { - color: #d5d5d5; - opacity: 1; } - .form-control:disabled, .form-control[readonly] { - background-color: #eceeef; - opacity: 1; } - .form-control:disabled { - cursor: not-allowed; } - -select.form-control:not([size]):not([multiple]) { - height: calc(2.25rem + 2px); } - -select.form-control:focus::-ms-value { - color: #55595c; - background-color: #fff; } - -.form-control-file, -.form-control-range { - display: block; } - -.col-form-label { - padding-top: calc(0.5rem - 1px * 2); - padding-bottom: calc(0.5rem - 1px * 2); - margin-bottom: 0; } - -.col-form-label-lg { - padding-top: calc(0.75rem - 1px * 2); - padding-bottom: calc(0.75rem - 1px * 2); - font-size: 1.25rem; } - -.col-form-label-sm { - padding-top: calc(0.25rem - 1px * 2); - padding-bottom: calc(0.25rem - 1px * 2); - font-size: 0.875rem; } - -.col-form-legend { - padding-top: 0.5rem; - padding-bottom: 0.5rem; - margin-bottom: 0; - font-size: 1rem; } - -.form-control-static { - padding-top: 0.5rem; - padding-bottom: 0.5rem; - margin-bottom: 0; - line-height: 1.25; - border: solid transparent; - border-width: 1px 0; } - .form-control-static.form-control-sm, .input-group-sm > .form-control-static.form-control, - .input-group-sm > .form-control-static.input-group-addon, - .input-group-sm > .input-group-btn > .form-control-static.btn, .form-control-static.form-control-lg, .input-group-lg > .form-control-static.form-control, - .input-group-lg > .form-control-static.input-group-addon, - .input-group-lg > .input-group-btn > .form-control-static.btn { - padding-right: 0; - padding-left: 0; } - -.form-control-sm, .input-group-sm > .form-control, -.input-group-sm > .input-group-addon, -.input-group-sm > .input-group-btn > .btn { - padding: 0.25rem 0.5rem; - font-size: 0.875rem; - border-radius: 0.2rem; } - -select.form-control-sm:not([size]):not([multiple]), .input-group-sm > select.form-control:not([size]):not([multiple]), -.input-group-sm > select.input-group-addon:not([size]):not([multiple]), -.input-group-sm > .input-group-btn > select.btn:not([size]):not([multiple]) { - height: 1.8125rem; } - -.form-control-lg, .input-group-lg > .form-control, -.input-group-lg > .input-group-addon, -.input-group-lg > .input-group-btn > .btn { - padding: 0.75rem 1.5rem; - font-size: 1.25rem; - border-radius: 0.3rem; } - -select.form-control-lg:not([size]):not([multiple]), .input-group-lg > select.form-control:not([size]):not([multiple]), -.input-group-lg > select.input-group-addon:not([size]):not([multiple]), -.input-group-lg > .input-group-btn > select.btn:not([size]):not([multiple]) { - height: 3.16667rem; } - -.form-group { - margin-bottom: 1rem; } - -.form-text { - display: block; - margin-top: 0.25rem; } - -.form-check { - position: relative; - display: block; - margin-bottom: 0.5rem; } - .form-check.disabled .form-check-label { - color: #d5d5d5; - cursor: not-allowed; } - -.form-check-label { - padding-left: 1.25rem; - margin-bottom: 0; - cursor: pointer; } - -.form-check-input { - position: absolute; - margin-top: 0.25rem; - margin-left: -1.25rem; } - .form-check-input:only-child { - position: static; } - -.form-check-inline { - display: inline-block; } - .form-check-inline .form-check-label { - vertical-align: middle; } - .form-check-inline + .form-check-inline { - margin-left: 0.75rem; } - -.form-control-feedback { - margin-top: 0.25rem; } - -.form-control-success, -.form-control-warning, -.form-control-danger { - padding-right: 2.25rem; - background-repeat: no-repeat; - background-position: center right 0.5625rem; - background-size: 1.125rem 1.125rem; } - -.has-success .form-control-feedback, -.has-success .form-control-label, -.has-success .col-form-label, -.has-success .form-check-label, -.has-success .custom-control { - color: #5cb85c; } - -.has-success .form-control { - border-color: #5cb85c; } - -.has-success .input-group-addon { - color: #5cb85c; - border-color: #5cb85c; - background-color: #eaf6ea; } - -.has-success .form-control-success { - background-image: url("data:image/svg+xml;charset=utf8,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 8 8'%3E%3Cpath fill='%235cb85c' d='M2.3 6.73L.6 4.53c-.4-1.04.46-1.4 1.1-.8l1.1 1.4 3.4-3.8c.6-.63 1.6-.27 1.2.7l-4 4.6c-.43.5-.8.4-1.1.1z'/%3E%3C/svg%3E"); } - -.has-warning .form-control-feedback, -.has-warning .form-control-label, -.has-warning .col-form-label, -.has-warning .form-check-label, -.has-warning .custom-control { - color: #f0ad4e; } - -.has-warning .form-control { - border-color: #f0ad4e; } - -.has-warning .input-group-addon { - color: #f0ad4e; - border-color: #f0ad4e; - background-color: white; } - -.has-warning .form-control-warning { - background-image: url("data:image/svg+xml;charset=utf8,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 8 8'%3E%3Cpath fill='%23f0ad4e' d='M4.4 5.324h-.8v-2.46h.8zm0 1.42h-.8V5.89h.8zM3.76.63L.04 7.075c-.115.2.016.425.26.426h7.397c.242 0 .372-.226.258-.426C6.726 4.924 5.47 2.79 4.253.63c-.113-.174-.39-.174-.494 0z'/%3E%3C/svg%3E"); } - -.has-danger .form-control-feedback, -.has-danger .form-control-label, -.has-danger .col-form-label, -.has-danger .form-check-label, -.has-danger .custom-control { - color: #d9534f; } - -.has-danger .form-control { - border-color: #d9534f; } - -.has-danger .input-group-addon { - color: #d9534f; - border-color: #d9534f; - background-color: #fdf7f7; } - -.has-danger .form-control-danger { - background-image: url("data:image/svg+xml;charset=utf8,%3Csvg xmlns='http://www.w3.org/2000/svg' fill='%23d9534f' viewBox='-2 -2 7 7'%3E%3Cpath stroke='%23d9534f' d='M0 0l3 3m0-3L0 3'/%3E%3Ccircle r='.5'/%3E%3Ccircle cx='3' r='.5'/%3E%3Ccircle cy='3' r='.5'/%3E%3Ccircle cx='3' cy='3' r='.5'/%3E%3C/svg%3E"); } - -.form-inline { - display: flex; - flex-flow: row wrap; - align-items: center; } - .form-inline .form-check { - width: 100%; } - @media (min-width: 576px) { - .form-inline label { - display: flex; - align-items: center; - justify-content: center; - margin-bottom: 0; } - .form-inline .form-group { - display: flex; - flex: 0 0 auto; - flex-flow: row wrap; - align-items: center; - margin-bottom: 0; } - .form-inline .form-control { - display: inline-block; - width: auto; - vertical-align: middle; } - .form-inline .form-control-static { - display: inline-block; } - .form-inline .input-group { - width: auto; } - .form-inline .form-control-label { - margin-bottom: 0; - vertical-align: middle; } - .form-inline .form-check { - display: flex; - align-items: center; - justify-content: center; - width: auto; - margin-top: 0; - margin-bottom: 0; } - .form-inline .form-check-label { - padding-left: 0; } - .form-inline .form-check-input { - position: relative; - margin-top: 0; - margin-right: 0.25rem; - margin-left: 0; } - .form-inline .custom-control { - display: flex; - align-items: center; - justify-content: center; - padding-left: 0; } - .form-inline .custom-control-indicator { - position: static; - display: inline-block; - margin-right: 0.25rem; - vertical-align: text-bottom; } - .form-inline .has-feedback .form-control-feedback { - top: 0; } } - -.btn { - display: inline-block; - font-weight: normal; - line-height: 1.25; - text-align: center; - white-space: nowrap; - vertical-align: middle; - user-select: none; - border: 1px solid transparent; - padding: 0.5rem 1rem; - font-size: 1rem; - border-radius: 0.25rem; - transition: all 0.2s ease-in-out; } - .btn:focus, .btn:hover { - text-decoration: none; } - .btn:focus, .btn.focus { - outline: 0; - box-shadow: 0 0 0 2px rgba(2, 117, 216, 0.25); } - .btn.disabled, .btn:disabled { - cursor: not-allowed; - opacity: .65; } - .btn:active, .btn.active { - background-image: none; } - -a.btn.disabled, -fieldset[disabled] a.btn { - pointer-events: none; } - -.btn-primary { - color: #fff; - background-color: #0275d8; - border-color: #0275d8; } - .btn-primary:hover { - color: #fff; - background-color: #025aa5; - border-color: #01549b; } - .btn-primary:focus, .btn-primary.focus { - box-shadow: 0 0 0 2px rgba(2, 117, 216, 0.5); } - .btn-primary.disabled, .btn-primary:disabled { - background-color: #0275d8; - border-color: #0275d8; } - .btn-primary:active, .btn-primary.active, - .show > .btn-primary.dropdown-toggle { - color: #fff; - background-color: #025aa5; - background-image: none; - border-color: #01549b; } - -.btn-secondary { - color: #373a3c; - background-color: #fff; - border-color: #ccc; } - .btn-secondary:hover { - color: #373a3c; - background-color: #e6e6e6; - border-color: #adadad; } - .btn-secondary:focus, .btn-secondary.focus { - box-shadow: 0 0 0 2px rgba(204, 204, 204, 0.5); } - .btn-secondary.disabled, .btn-secondary:disabled { - background-color: #fff; - border-color: #ccc; } - .btn-secondary:active, .btn-secondary.active, - .show > .btn-secondary.dropdown-toggle { - color: #373a3c; - background-color: #e6e6e6; - background-image: none; - border-color: #adadad; } - -.btn-info { - color: #fff; - background-color: #5bc0de; - border-color: #5bc0de; } - .btn-info:hover { - color: #fff; - background-color: #31b0d5; - border-color: #2aabd2; } - .btn-info:focus, .btn-info.focus { - box-shadow: 0 0 0 2px rgba(91, 192, 222, 0.5); } - .btn-info.disabled, .btn-info:disabled { - background-color: #5bc0de; - border-color: #5bc0de; } - .btn-info:active, .btn-info.active, - .show > .btn-info.dropdown-toggle { - color: #fff; - background-color: #31b0d5; - background-image: none; - border-color: #2aabd2; } - -.btn-success { - color: #fff; - background-color: #5cb85c; - border-color: #5cb85c; } - .btn-success:hover { - color: #fff; - background-color: #449d44; - border-color: #419641; } - .btn-success:focus, .btn-success.focus { - box-shadow: 0 0 0 2px rgba(92, 184, 92, 0.5); } - .btn-success.disabled, .btn-success:disabled { - background-color: #5cb85c; - border-color: #5cb85c; } - .btn-success:active, .btn-success.active, - .show > .btn-success.dropdown-toggle { - color: #fff; - background-color: #449d44; - background-image: none; - border-color: #419641; } - -.btn-warning { - color: #fff; - background-color: #f0ad4e; - border-color: #f0ad4e; } - .btn-warning:hover { - color: #fff; - background-color: #ec971f; - border-color: #eb9316; } - .btn-warning:focus, .btn-warning.focus { - box-shadow: 0 0 0 2px rgba(240, 173, 78, 0.5); } - .btn-warning.disabled, .btn-warning:disabled { - background-color: #f0ad4e; - border-color: #f0ad4e; } - .btn-warning:active, .btn-warning.active, - .show > .btn-warning.dropdown-toggle { - color: #fff; - background-color: #ec971f; - background-image: none; - border-color: #eb9316; } - -.btn-danger { - color: #fff; - background-color: #d9534f; - border-color: #d9534f; } - .btn-danger:hover { - color: #fff; - background-color: #c9302c; - border-color: #c12e2a; } - .btn-danger:focus, .btn-danger.focus { - box-shadow: 0 0 0 2px rgba(217, 83, 79, 0.5); } - .btn-danger.disabled, .btn-danger:disabled { - background-color: #d9534f; - border-color: #d9534f; } - .btn-danger:active, .btn-danger.active, - .show > .btn-danger.dropdown-toggle { - color: #fff; - background-color: #c9302c; - background-image: none; - border-color: #c12e2a; } - -.btn-outline-primary { - color: #0275d8; - background-image: none; - background-color: transparent; - border-color: #0275d8; } - .btn-outline-primary:hover { - color: #fff; - background-color: #0275d8; - border-color: #0275d8; } - .btn-outline-primary:focus, .btn-outline-primary.focus { - box-shadow: 0 0 0 2px rgba(2, 117, 216, 0.5); } - .btn-outline-primary.disabled, .btn-outline-primary:disabled { - color: #0275d8; - background-color: transparent; } - .btn-outline-primary:active, .btn-outline-primary.active, - .show > .btn-outline-primary.dropdown-toggle { - color: #fff; - background-color: #0275d8; - border-color: #0275d8; } - -.btn-outline-secondary { - color: #ccc; - background-image: none; - background-color: transparent; - border-color: #ccc; } - .btn-outline-secondary:hover { - color: #fff; - background-color: #ccc; - border-color: #ccc; } - .btn-outline-secondary:focus, .btn-outline-secondary.focus { - box-shadow: 0 0 0 2px rgba(204, 204, 204, 0.5); } - .btn-outline-secondary.disabled, .btn-outline-secondary:disabled { - color: #ccc; - background-color: transparent; } - .btn-outline-secondary:active, .btn-outline-secondary.active, - .show > .btn-outline-secondary.dropdown-toggle { - color: #fff; - background-color: #ccc; - border-color: #ccc; } - -.btn-outline-info { - color: #5bc0de; - background-image: none; - background-color: transparent; - border-color: #5bc0de; } - .btn-outline-info:hover { - color: #fff; - background-color: #5bc0de; - border-color: #5bc0de; } - .btn-outline-info:focus, .btn-outline-info.focus { - box-shadow: 0 0 0 2px rgba(91, 192, 222, 0.5); } - .btn-outline-info.disabled, .btn-outline-info:disabled { - color: #5bc0de; - background-color: transparent; } - .btn-outline-info:active, .btn-outline-info.active, - .show > .btn-outline-info.dropdown-toggle { - color: #fff; - background-color: #5bc0de; - border-color: #5bc0de; } - -.btn-outline-success { - color: #5cb85c; - background-image: none; - background-color: transparent; - border-color: #5cb85c; } - .btn-outline-success:hover { - color: #fff; - background-color: #5cb85c; - border-color: #5cb85c; } - .btn-outline-success:focus, .btn-outline-success.focus { - box-shadow: 0 0 0 2px rgba(92, 184, 92, 0.5); } - .btn-outline-success.disabled, .btn-outline-success:disabled { - color: #5cb85c; - background-color: transparent; } - .btn-outline-success:active, .btn-outline-success.active, - .show > .btn-outline-success.dropdown-toggle { - color: #fff; - background-color: #5cb85c; - border-color: #5cb85c; } - -.btn-outline-warning { - color: #f0ad4e; - background-image: none; - background-color: transparent; - border-color: #f0ad4e; } - .btn-outline-warning:hover { - color: #fff; - background-color: #f0ad4e; - border-color: #f0ad4e; } - .btn-outline-warning:focus, .btn-outline-warning.focus { - box-shadow: 0 0 0 2px rgba(240, 173, 78, 0.5); } - .btn-outline-warning.disabled, .btn-outline-warning:disabled { - color: #f0ad4e; - background-color: transparent; } - .btn-outline-warning:active, .btn-outline-warning.active, - .show > .btn-outline-warning.dropdown-toggle { - color: #fff; - background-color: #f0ad4e; - border-color: #f0ad4e; } - -.btn-outline-danger { - color: #d9534f; - background-image: none; - background-color: transparent; - border-color: #d9534f; } - .btn-outline-danger:hover { - color: #fff; - background-color: #d9534f; - border-color: #d9534f; } - .btn-outline-danger:focus, .btn-outline-danger.focus { - box-shadow: 0 0 0 2px rgba(217, 83, 79, 0.5); } - .btn-outline-danger.disabled, .btn-outline-danger:disabled { - color: #d9534f; - background-color: transparent; } - .btn-outline-danger:active, .btn-outline-danger.active, - .show > .btn-outline-danger.dropdown-toggle { - color: #fff; - background-color: #d9534f; - border-color: #d9534f; } - -.btn-link { - font-weight: normal; - color: #0275d8; - border-radius: 0; } - .btn-link, .btn-link:active, .btn-link.active, .btn-link:disabled { - background-color: transparent; } - .btn-link, .btn-link:focus, .btn-link:active { - border-color: transparent; } - .btn-link:hover { - border-color: transparent; } - .btn-link:focus, .btn-link:hover { - color: #014c8c; - text-decoration: underline; - background-color: transparent; } - .btn-link:disabled { - color: #d5d5d5; } - .btn-link:disabled:focus, .btn-link:disabled:hover { - text-decoration: none; } - -.btn-lg, .btn-group-lg > .btn { - padding: 0.75rem 1.5rem; - font-size: 1.25rem; - border-radius: 0.3rem; } - -.btn-sm, .btn-group-sm > .btn { - padding: 0.25rem 0.5rem; - font-size: 0.875rem; - border-radius: 0.2rem; } - -.btn-block { - display: block; - width: 100%; } - -.btn-block + .btn-block { - margin-top: 0.5rem; } - -input[type="submit"].btn-block, -input[type="reset"].btn-block, -input[type="button"].btn-block { - width: 100%; } - -.fade { - opacity: 0; - transition: opacity 0.15s linear; } - .fade.show { - opacity: 1; } - -.collapse { - display: none; } - .collapse.show { - display: block; } - -tr.collapse.show { - display: table-row; } - -tbody.collapse.show { - display: table-row-group; } - -.collapsing { - position: relative; - height: 0; - overflow: hidden; - transition: height 0.35s ease; } - -.dropup, -.dropdown { - position: relative; } - -.dropdown-toggle::after { - display: inline-block; - width: 0; - height: 0; - margin-left: 0.3em; - vertical-align: middle; - content: ""; - border-top: 0.3em solid; - border-right: 0.3em solid transparent; - border-left: 0.3em solid transparent; } - -.dropdown-toggle:focus { - outline: 0; } - -.dropup .dropdown-toggle::after { - border-top: 0; - border-bottom: 0.3em solid; } - -.dropdown-menu { - position: absolute; - top: 100%; - left: 0; - z-index: 1000; - display: none; - float: left; - min-width: 10rem; - padding: 0.5rem 0; - margin: 0.125rem 0 0; - font-size: 1rem; - color: #373a3c; - text-align: left; - list-style: none; - background-color: #fff; - background-clip: padding-box; - border: 1px solid rgba(0, 0, 0, 0.15); - border-radius: 0.25rem; } - -.dropdown-divider { - height: 1px; - margin: 0.5rem 0; - overflow: hidden; - background-color: #eceeef; } - -.dropdown-item { - display: block; - width: 100%; - padding: 3px 1.5rem; - clear: both; - font-weight: normal; - color: #373a3c; - text-align: inherit; - white-space: nowrap; - background: none; - border: 0; } - .dropdown-item:focus, .dropdown-item:hover { - color: #2b2d2f; - text-decoration: none; - background-color: #f3f3f3; } - .dropdown-item.active, .dropdown-item:active { - color: #fff; - text-decoration: none; - background-color: #0275d8; } - .dropdown-item.disabled, .dropdown-item:disabled { - color: #d5d5d5; - cursor: not-allowed; - background-color: transparent; } - -.show > .dropdown-menu { - display: block; } - -.show > a { - outline: 0; } - -.dropdown-menu-right { - right: 0; - left: auto; } - -.dropdown-menu-left { - right: auto; - left: 0; } - -.dropdown-header { - display: block; - padding: 0.5rem 1.5rem; - margin-bottom: 0; - font-size: 0.875rem; - color: #d5d5d5; - white-space: nowrap; } - -.dropdown-backdrop { - position: fixed; - top: 0; - right: 0; - bottom: 0; - left: 0; - z-index: 990; } - -.dropup .dropdown-menu { - top: auto; - bottom: 100%; - margin-bottom: 0.125rem; } - -.btn-group, -.btn-group-vertical { - position: relative; - display: inline-flex; - vertical-align: middle; } - .btn-group > .btn, - .btn-group-vertical > .btn { - position: relative; - flex: 0 1 auto; } - .btn-group > .btn:hover, - .btn-group-vertical > .btn:hover { - z-index: 2; } - .btn-group > .btn:focus, .btn-group > .btn:active, .btn-group > .btn.active, - .btn-group-vertical > .btn:focus, - .btn-group-vertical > .btn:active, - .btn-group-vertical > .btn.active { - z-index: 2; } - .btn-group .btn + .btn, - .btn-group .btn + .btn-group, - .btn-group .btn-group + .btn, - .btn-group .btn-group + .btn-group, - .btn-group-vertical .btn + .btn, - .btn-group-vertical .btn + .btn-group, - .btn-group-vertical .btn-group + .btn, - .btn-group-vertical .btn-group + .btn-group { - margin-left: -1px; } - -.btn-toolbar { - display: flex; - justify-content: flex-start; } - .btn-toolbar .input-group { - width: auto; } - -.btn-group > .btn:not(:first-child):not(:last-child):not(.dropdown-toggle) { - border-radius: 0; } - -.btn-group > .btn:first-child { - margin-left: 0; } - .btn-group > .btn:first-child:not(:last-child):not(.dropdown-toggle) { - border-bottom-right-radius: 0; - border-top-right-radius: 0; } - -.btn-group > .btn:last-child:not(:first-child), -.btn-group > .dropdown-toggle:not(:first-child) { - border-bottom-left-radius: 0; - border-top-left-radius: 0; } - -.btn-group > .btn-group { - float: left; } - -.btn-group > .btn-group:not(:first-child):not(:last-child) > .btn { - border-radius: 0; } - -.btn-group > .btn-group:first-child:not(:last-child) > .btn:last-child, -.btn-group > .btn-group:first-child:not(:last-child) > .dropdown-toggle { - border-bottom-right-radius: 0; - border-top-right-radius: 0; } - -.btn-group > .btn-group:last-child:not(:first-child) > .btn:first-child { - border-bottom-left-radius: 0; - border-top-left-radius: 0; } - -.btn-group .dropdown-toggle:active, -.btn-group.open .dropdown-toggle { - outline: 0; } - -.btn + .dropdown-toggle-split { - padding-right: 0.75rem; - padding-left: 0.75rem; } - .btn + .dropdown-toggle-split::after { - margin-left: 0; } - -.btn-sm + .dropdown-toggle-split, .btn-group-sm > .btn + .dropdown-toggle-split { - padding-right: 0.375rem; - padding-left: 0.375rem; } - -.btn-lg + .dropdown-toggle-split, .btn-group-lg > .btn + .dropdown-toggle-split { - padding-right: 1.125rem; - padding-left: 1.125rem; } - -.btn-group-vertical { - display: inline-flex; - flex-direction: column; - align-items: flex-start; - justify-content: center; } - .btn-group-vertical .btn, - .btn-group-vertical .btn-group { - width: 100%; } - .btn-group-vertical > .btn + .btn, - .btn-group-vertical > .btn + .btn-group, - .btn-group-vertical > .btn-group + .btn, - .btn-group-vertical > .btn-group + .btn-group { - margin-top: -1px; - margin-left: 0; } - -.btn-group-vertical > .btn:not(:first-child):not(:last-child) { - border-radius: 0; } - -.btn-group-vertical > .btn:first-child:not(:last-child) { - border-bottom-right-radius: 0; - border-bottom-left-radius: 0; } - -.btn-group-vertical > .btn:last-child:not(:first-child) { - border-top-right-radius: 0; - border-top-left-radius: 0; } - -.btn-group-vertical > .btn-group:not(:first-child):not(:last-child) > .btn { - border-radius: 0; } - -.btn-group-vertical > .btn-group:first-child:not(:last-child) > .btn:last-child, -.btn-group-vertical > .btn-group:first-child:not(:last-child) > .dropdown-toggle { - border-bottom-right-radius: 0; - border-bottom-left-radius: 0; } - -.btn-group-vertical > .btn-group:last-child:not(:first-child) > .btn:first-child { - border-top-right-radius: 0; - border-top-left-radius: 0; } - -[data-toggle="buttons"] > .btn input[type="radio"], -[data-toggle="buttons"] > .btn input[type="checkbox"], -[data-toggle="buttons"] > .btn-group > .btn input[type="radio"], -[data-toggle="buttons"] > .btn-group > .btn input[type="checkbox"] { - position: absolute; - clip: rect(0, 0, 0, 0); - pointer-events: none; } - -.input-group { - position: relative; - display: flex; - width: 100%; } - .input-group .form-control { - position: relative; - z-index: 2; - flex: 1 1 auto; - width: 1%; - margin-bottom: 0; } - .input-group .form-control:focus, .input-group .form-control:active, .input-group .form-control:hover { - z-index: 3; } - -.input-group-addon, -.input-group-btn, -.input-group .form-control { - display: flex; - flex-direction: column; - justify-content: center; } - .input-group-addon:not(:first-child):not(:last-child), - .input-group-btn:not(:first-child):not(:last-child), - .input-group .form-control:not(:first-child):not(:last-child) { - border-radius: 0; } - -.input-group-addon, -.input-group-btn { - white-space: nowrap; - vertical-align: middle; } - -.input-group-addon { - padding: 0.5rem 0.75rem; - margin-bottom: 0; - font-size: 1rem; - font-weight: normal; - line-height: 1.25; - color: #55595c; - text-align: center; - background-color: #eceeef; - border: 1px solid rgba(0, 0, 0, 0.15); - border-radius: 0.25rem; } - .input-group-addon.form-control-sm, - .input-group-sm > .input-group-addon, - .input-group-sm > .input-group-btn > .input-group-addon.btn { - padding: 0.25rem 0.5rem; - font-size: 0.875rem; - border-radius: 0.2rem; } - .input-group-addon.form-control-lg, - .input-group-lg > .input-group-addon, - .input-group-lg > .input-group-btn > .input-group-addon.btn { - padding: 0.75rem 1.5rem; - font-size: 1.25rem; - border-radius: 0.3rem; } - .input-group-addon input[type="radio"], - .input-group-addon input[type="checkbox"] { - margin-top: 0; } - -.input-group .form-control:not(:last-child), -.input-group-addon:not(:last-child), -.input-group-btn:not(:last-child) > .btn, -.input-group-btn:not(:last-child) > .btn-group > .btn, -.input-group-btn:not(:last-child) > .dropdown-toggle, -.input-group-btn:not(:first-child) > .btn:not(:last-child):not(.dropdown-toggle), -.input-group-btn:not(:first-child) > .btn-group:not(:last-child) > .btn { - border-bottom-right-radius: 0; - border-top-right-radius: 0; } - -.input-group-addon:not(:last-child) { - border-right: 0; } - -.input-group .form-control:not(:first-child), -.input-group-addon:not(:first-child), -.input-group-btn:not(:first-child) > .btn, -.input-group-btn:not(:first-child) > .btn-group > .btn, -.input-group-btn:not(:first-child) > .dropdown-toggle, -.input-group-btn:not(:last-child) > .btn:not(:first-child), -.input-group-btn:not(:last-child) > .btn-group:not(:first-child) > .btn { - border-bottom-left-radius: 0; - border-top-left-radius: 0; } - -.form-control + .input-group-addon:not(:first-child) { - border-left: 0; } - -.input-group-btn { - position: relative; - font-size: 0; - white-space: nowrap; } - .input-group-btn > .btn { - position: relative; - flex: 1; } - .input-group-btn > .btn + .btn { - margin-left: -1px; } - .input-group-btn > .btn:focus, .input-group-btn > .btn:active, .input-group-btn > .btn:hover { - z-index: 3; } - .input-group-btn:not(:last-child) > .btn, - .input-group-btn:not(:last-child) > .btn-group { - margin-right: -1px; } - .input-group-btn:not(:first-child) > .btn, - .input-group-btn:not(:first-child) > .btn-group { - z-index: 2; - margin-left: -1px; } - .input-group-btn:not(:first-child) > .btn:focus, .input-group-btn:not(:first-child) > .btn:active, .input-group-btn:not(:first-child) > .btn:hover, - .input-group-btn:not(:first-child) > .btn-group:focus, - .input-group-btn:not(:first-child) > .btn-group:active, - .input-group-btn:not(:first-child) > .btn-group:hover { - z-index: 3; } - -.custom-control { - position: relative; - display: inline-flex; - min-height: 1.5rem; - padding-left: 1.5rem; - margin-right: 1rem; - cursor: pointer; } - -.custom-control-input { - position: absolute; - z-index: -1; - opacity: 0; } - .custom-control-input:checked ~ .custom-control-indicator { - color: #fff; - background-color: #0275d8; } - .custom-control-input:focus ~ .custom-control-indicator { - box-shadow: 0 0 0 1px #fff, 0 0 0 3px #0275d8; } - .custom-control-input:active ~ .custom-control-indicator { - color: #fff; - background-color: #8fcafe; } - .custom-control-input:disabled ~ .custom-control-indicator { - cursor: not-allowed; - background-color: #eceeef; } - .custom-control-input:disabled ~ .custom-control-description { - color: #d5d5d5; - cursor: not-allowed; } - -.custom-control-indicator { - position: absolute; - top: 0.25rem; - left: 0; - display: block; - width: 1rem; - height: 1rem; - pointer-events: none; - user-select: none; - background-color: #ddd; - background-repeat: no-repeat; - background-position: center center; - background-size: 50% 50%; } - -.custom-checkbox .custom-control-indicator { - border-radius: 0.25rem; } - -.custom-checkbox .custom-control-input:checked ~ .custom-control-indicator { - background-image: url("data:image/svg+xml;charset=utf8,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 8 8'%3E%3Cpath fill='%23fff' d='M6.564.75l-3.59 3.612-1.538-1.55L0 4.26 2.974 7.25 8 2.193z'/%3E%3C/svg%3E"); } - -.custom-checkbox .custom-control-input:indeterminate ~ .custom-control-indicator { - background-color: #0275d8; - background-image: url("data:image/svg+xml;charset=utf8,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 4 4'%3E%3Cpath stroke='%23fff' d='M0 2h4'/%3E%3C/svg%3E"); } - -.custom-radio .custom-control-indicator { - border-radius: 50%; } - -.custom-radio .custom-control-input:checked ~ .custom-control-indicator { - background-image: url("data:image/svg+xml;charset=utf8,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='-4 -4 8 8'%3E%3Ccircle r='3' fill='%23fff'/%3E%3C/svg%3E"); } - -.custom-controls-stacked { - display: flex; - flex-direction: column; } - .custom-controls-stacked .custom-control { - margin-bottom: 0.25rem; } - .custom-controls-stacked .custom-control + .custom-control { - margin-left: 0; } - -.custom-select { - display: inline-block; - max-width: 100%; - height: calc(2.25rem + 2px); - padding: 0.375rem 1.75rem 0.375rem 0.75rem; - line-height: 1.25; - color: #55595c; - vertical-align: middle; - background: #fff url("data:image/svg+xml;charset=utf8,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 4 5'%3E%3Cpath fill='%23333' d='M2 0L0 2h4zm0 5L0 3h4z'/%3E%3C/svg%3E") no-repeat right 0.75rem center; - background-size: 8px 10px; - border: 1px solid rgba(0, 0, 0, 0.15); - border-radius: 0.25rem; - -moz-appearance: none; - -webkit-appearance: none; } - .custom-select:focus { - border-color: #5cb3fd; - outline: none; } - .custom-select:focus::-ms-value { - color: #55595c; - background-color: #fff; } - .custom-select:disabled { - color: #d5d5d5; - cursor: not-allowed; - background-color: #eceeef; } - .custom-select::-ms-expand { - opacity: 0; } - -.custom-select-sm { - padding-top: 0.375rem; - padding-bottom: 0.375rem; - font-size: 75%; } - -.custom-file { - position: relative; - display: inline-block; - max-width: 100%; - height: 2.5rem; - margin-bottom: 0; - cursor: pointer; } - -.custom-file-input { - min-width: 14rem; - max-width: 100%; - height: 2.5rem; - margin: 0; - filter: alpha(opacity=0); - opacity: 0; } - -.custom-file-control { - position: absolute; - top: 0; - right: 0; - left: 0; - z-index: 5; - height: 2.5rem; - padding: 0.5rem 1rem; - line-height: 1.5; - color: #55595c; - pointer-events: none; - user-select: none; - background-color: #fff; - border: 1px solid rgba(0, 0, 0, 0.15); - border-radius: 0.25rem; } - .custom-file-control:lang(en)::after { - content: "Choose file..."; } - .custom-file-control::before { - position: absolute; - top: -1px; - right: -1px; - bottom: -1px; - z-index: 6; - display: block; - height: 2.5rem; - padding: 0.5rem 1rem; - line-height: 1.5; - color: #55595c; - background-color: #eceeef; - border: 1px solid rgba(0, 0, 0, 0.15); - border-radius: 0 0.25rem 0.25rem 0; } - .custom-file-control:lang(en)::before { - content: "Browse"; } - -.nav { - display: flex; - padding-left: 0; - margin-bottom: 0; - list-style: none; } - -.nav-link { - display: block; - padding: 0.5em 1em; } - .nav-link:focus, .nav-link:hover { - text-decoration: none; } - .nav-link.disabled { - color: #d5d5d5; - cursor: not-allowed; } - -.nav-tabs { - border-bottom: 1px solid #ddd; } - .nav-tabs .nav-item { - margin-bottom: -1px; } - .nav-tabs .nav-link { - border: 1px solid transparent; - border-top-right-radius: 0.25rem; - border-top-left-radius: 0.25rem; } - .nav-tabs .nav-link:focus, .nav-tabs .nav-link:hover { - border-color: #eceeef #eceeef #ddd; } - .nav-tabs .nav-link.disabled { - color: #d5d5d5; - background-color: transparent; - border-color: transparent; } - .nav-tabs .nav-link.active, - .nav-tabs .nav-item.show .nav-link { - color: #55595c; - background-color: #fff; - border-color: #ddd #ddd #fff; } - .nav-tabs .dropdown-menu { - margin-top: -1px; - border-top-right-radius: 0; - border-top-left-radius: 0; } - -.nav-pills .nav-link { - border-radius: 0.25rem; } - -.nav-pills .nav-link.active, -.nav-pills .nav-item.show .nav-link { - color: #fff; - cursor: default; - background-color: #0275d8; } - -.nav-fill .nav-item { - flex: 1 1 auto; - text-align: center; } - -.nav-justified .nav-item { - flex: 1 1 100%; - text-align: center; } - -.tab-content > .tab-pane { - display: none; } - -.tab-content > .active { - display: block; } - -.navbar { - position: relative; - display: flex; - flex-direction: column; - padding: 0.5rem 1rem; } - -.navbar-brand { - display: inline-block; - padding-top: .25rem; - padding-bottom: .25rem; - margin-right: 1rem; - font-size: 1.25rem; - line-height: inherit; - white-space: nowrap; } - .navbar-brand:focus, .navbar-brand:hover { - text-decoration: none; } - -.navbar-nav { - display: flex; - flex-direction: column; - padding-left: 0; - margin-bottom: 0; - list-style: none; } - .navbar-nav .nav-link { - padding-right: 0; - padding-left: 0; } - -.navbar-text { - display: inline-block; - padding-top: .425rem; - padding-bottom: .425rem; } - -.navbar-toggler { - align-self: flex-start; - padding: 0.25rem 0.75rem; - font-size: 1.25rem; - line-height: 1; - background: transparent; - border: 1px solid transparent; - border-radius: 0.25rem; } - .navbar-toggler:focus, .navbar-toggler:hover { - text-decoration: none; } - -.navbar-toggler-icon { - display: inline-block; - width: 1.5em; - height: 1.5em; - vertical-align: middle; - content: ""; - background: no-repeat center center; - background-size: 100% 100%; } - -.navbar-toggler-left { - position: absolute; - left: 1rem; } - -.navbar-toggler-right { - position: absolute; - right: 1rem; } - -@media (max-width: 575px) { - .navbar-toggleable .navbar-nav .dropdown-menu { - position: static; - float: none; } - .navbar-toggleable > .container { - padding-right: 0; - padding-left: 0; } } - -@media (min-width: 576px) { - .navbar-toggleable { - flex-direction: row; - flex-wrap: nowrap; - align-items: center; } - .navbar-toggleable .navbar-nav { - flex-direction: row; } - .navbar-toggleable .navbar-nav .nav-link { - padding-right: .5rem; - padding-left: .5rem; } - .navbar-toggleable > .container { - display: flex; - flex-wrap: nowrap; - align-items: center; } - .navbar-toggleable .navbar-collapse { - display: flex !important; - width: 100%; } - .navbar-toggleable .navbar-toggler { - display: none; } } - -@media (max-width: 767px) { - .navbar-toggleable-sm .navbar-nav .dropdown-menu { - position: static; - float: none; } - .navbar-toggleable-sm > .container { - padding-right: 0; - padding-left: 0; } } - -@media (min-width: 768px) { - .navbar-toggleable-sm { - flex-direction: row; - flex-wrap: nowrap; - align-items: center; } - .navbar-toggleable-sm .navbar-nav { - flex-direction: row; } - .navbar-toggleable-sm .navbar-nav .nav-link { - padding-right: .5rem; - padding-left: .5rem; } - .navbar-toggleable-sm > .container { - display: flex; - flex-wrap: nowrap; - align-items: center; } - .navbar-toggleable-sm .navbar-collapse { - display: flex !important; - width: 100%; } - .navbar-toggleable-sm .navbar-toggler { - display: none; } } - -@media (max-width: 991px) { - .navbar-toggleable-md .navbar-nav .dropdown-menu { - position: static; - float: none; } - .navbar-toggleable-md > .container { - padding-right: 0; - padding-left: 0; } } - -@media (min-width: 992px) { - .navbar-toggleable-md { - flex-direction: row; - flex-wrap: nowrap; - align-items: center; } - .navbar-toggleable-md .navbar-nav { - flex-direction: row; } - .navbar-toggleable-md .navbar-nav .nav-link { - padding-right: .5rem; - padding-left: .5rem; } - .navbar-toggleable-md > .container { - display: flex; - flex-wrap: nowrap; - align-items: center; } - .navbar-toggleable-md .navbar-collapse { - display: flex !important; - width: 100%; } - .navbar-toggleable-md .navbar-toggler { - display: none; } } - -@media (max-width: 1199px) { - .navbar-toggleable-lg .navbar-nav .dropdown-menu { - position: static; - float: none; } - .navbar-toggleable-lg > .container { - padding-right: 0; - padding-left: 0; } } - -@media (min-width: 1200px) { - .navbar-toggleable-lg { - flex-direction: row; - flex-wrap: nowrap; - align-items: center; } - .navbar-toggleable-lg .navbar-nav { - flex-direction: row; } - .navbar-toggleable-lg .navbar-nav .nav-link { - padding-right: .5rem; - padding-left: .5rem; } - .navbar-toggleable-lg > .container { - display: flex; - flex-wrap: nowrap; - align-items: center; } - .navbar-toggleable-lg .navbar-collapse { - display: flex !important; - width: 100%; } - .navbar-toggleable-lg .navbar-toggler { - display: none; } } - -.navbar-toggleable-xl { - flex-direction: row; - flex-wrap: nowrap; - align-items: center; } - .navbar-toggleable-xl .navbar-nav .dropdown-menu { - position: static; - float: none; } - .navbar-toggleable-xl > .container { - padding-right: 0; - padding-left: 0; } - .navbar-toggleable-xl .navbar-nav { - flex-direction: row; } - .navbar-toggleable-xl .navbar-nav .nav-link { - padding-right: .5rem; - padding-left: .5rem; } - .navbar-toggleable-xl > .container { - display: flex; - flex-wrap: nowrap; - align-items: center; } - .navbar-toggleable-xl .navbar-collapse { - display: flex !important; - width: 100%; } - .navbar-toggleable-xl .navbar-toggler { - display: none; } - -.navbar-light .navbar-brand, -.navbar-light .navbar-toggler { - color: rgba(0, 0, 0, 0.9); } - .navbar-light .navbar-brand:focus, .navbar-light .navbar-brand:hover, - .navbar-light .navbar-toggler:focus, - .navbar-light .navbar-toggler:hover { - color: rgba(0, 0, 0, 0.9); } - -.navbar-light .navbar-nav .nav-link { - color: rgba(0, 0, 0, 0.5); } - .navbar-light .navbar-nav .nav-link:focus, .navbar-light .navbar-nav .nav-link:hover { - color: rgba(0, 0, 0, 0.7); } - .navbar-light .navbar-nav .nav-link.disabled { - color: rgba(0, 0, 0, 0.3); } - -.navbar-light .navbar-nav .open > .nav-link, -.navbar-light .navbar-nav .active > .nav-link, -.navbar-light .navbar-nav .nav-link.open, -.navbar-light .navbar-nav .nav-link.active { - color: rgba(0, 0, 0, 0.9); } - -.navbar-light .navbar-toggler { - border-color: rgba(0, 0, 0, 0.1); } - -.navbar-light .navbar-toggler-icon { - background-image: url("data:image/svg+xml;charset=utf8,%3Csvg viewBox='0 0 32 32' xmlns='http://www.w3.org/2000/svg'%3E%3Cpath stroke='rgba(0, 0, 0, 0.5)' stroke-width='2' stroke-linecap='round' stroke-miterlimit='10' d='M4 8h24M4 16h24M4 24h24'/%3E%3C/svg%3E"); } - -.navbar-light .navbar-text { - color: rgba(0, 0, 0, 0.5); } - -.navbar-inverse .navbar-brand, -.navbar-inverse .navbar-toggler { - color: white; } - .navbar-inverse .navbar-brand:focus, .navbar-inverse .navbar-brand:hover, - .navbar-inverse .navbar-toggler:focus, - .navbar-inverse .navbar-toggler:hover { - color: white; } - -.navbar-inverse .navbar-nav .nav-link { - color: rgba(255, 255, 255, 0.5); } - .navbar-inverse .navbar-nav .nav-link:focus, .navbar-inverse .navbar-nav .nav-link:hover { - color: rgba(255, 255, 255, 0.75); } - .navbar-inverse .navbar-nav .nav-link.disabled { - color: rgba(255, 255, 255, 0.25); } - -.navbar-inverse .navbar-nav .open > .nav-link, -.navbar-inverse .navbar-nav .active > .nav-link, -.navbar-inverse .navbar-nav .nav-link.open, -.navbar-inverse .navbar-nav .nav-link.active { - color: white; } - -.navbar-inverse .navbar-toggler { - border-color: rgba(255, 255, 255, 0.1); } - -.navbar-inverse .navbar-toggler-icon { - background-image: url("data:image/svg+xml;charset=utf8,%3Csvg viewBox='0 0 32 32' xmlns='http://www.w3.org/2000/svg'%3E%3Cpath stroke='rgba(255, 255, 255, 0.5)' stroke-width='2' stroke-linecap='round' stroke-miterlimit='10' d='M4 8h24M4 16h24M4 24h24'/%3E%3C/svg%3E"); } - -.navbar-inverse .navbar-text { - color: rgba(255, 255, 255, 0.5); } - -.card { - position: relative; - display: flex; - flex-direction: column; - background-color: #fff; - border: 1px solid rgba(0, 0, 0, 0.125); - border-radius: 0.25rem; } - -.card-block { - flex: 1 1 auto; - padding: 1.25rem; } - -.card-title { - margin-bottom: 0.75rem; } - -.card-subtitle { - margin-top: -0.375rem; - margin-bottom: 0; } - -.card-text:last-child { - margin-bottom: 0; } - -.card-link:hover { - text-decoration: none; } - -.card-link + .card-link { - margin-left: 1.25rem; } - -.card > .list-group:first-child .list-group-item:first-child { - border-top-right-radius: 0.25rem; - border-top-left-radius: 0.25rem; } - -.card > .list-group:last-child .list-group-item:last-child { - border-bottom-right-radius: 0.25rem; - border-bottom-left-radius: 0.25rem; } - -.card-header { - padding: 0.75rem 1.25rem; - margin-bottom: 0; - background-color: #f3f3f3; - border-bottom: 1px solid rgba(0, 0, 0, 0.125); } - .card-header:first-child { - border-radius: calc(0.25rem - 1px) calc(0.25rem - 1px) 0 0; } - -.card-footer { - padding: 0.75rem 1.25rem; - background-color: #f3f3f3; - border-top: 1px solid rgba(0, 0, 0, 0.125); } - .card-footer:last-child { - border-radius: 0 0 calc(0.25rem - 1px) calc(0.25rem - 1px); } - -.card-header-tabs { - margin-right: -0.625rem; - margin-bottom: -0.75rem; - margin-left: -0.625rem; - border-bottom: 0; } - -.card-header-pills { - margin-right: -0.625rem; - margin-left: -0.625rem; } - -.card-primary { - background-color: #0275d8; - border-color: #0275d8; } - .card-primary .card-header, - .card-primary .card-footer { - background-color: transparent; } - -.card-success { - background-color: #5cb85c; - border-color: #5cb85c; } - .card-success .card-header, - .card-success .card-footer { - background-color: transparent; } - -.card-info { - background-color: #5bc0de; - border-color: #5bc0de; } - .card-info .card-header, - .card-info .card-footer { - background-color: transparent; } - -.card-warning { - background-color: #f0ad4e; - border-color: #f0ad4e; } - .card-warning .card-header, - .card-warning .card-footer { - background-color: transparent; } - -.card-danger { - background-color: #d9534f; - border-color: #d9534f; } - .card-danger .card-header, - .card-danger .card-footer { - background-color: transparent; } - -.card-outline-primary { - background-color: transparent; - border-color: #0275d8; } - -.card-outline-secondary { - background-color: transparent; - border-color: #ccc; } - -.card-outline-info { - background-color: transparent; - border-color: #5bc0de; } - -.card-outline-success { - background-color: transparent; - border-color: #5cb85c; } - -.card-outline-warning { - background-color: transparent; - border-color: #f0ad4e; } - -.card-outline-danger { - background-color: transparent; - border-color: #d9534f; } - -.card-inverse { - color: rgba(255, 255, 255, 0.65); } - .card-inverse .card-header, - .card-inverse .card-footer { - background-color: transparent; - border-color: rgba(255, 255, 255, 0.2); } - .card-inverse .card-header, - .card-inverse .card-footer, - .card-inverse .card-title, - .card-inverse .card-blockquote { - color: #fff; } - .card-inverse .card-link, - .card-inverse .card-text, - .card-inverse .card-subtitle, - .card-inverse .card-blockquote .blockquote-footer { - color: rgba(255, 255, 255, 0.65); } - .card-inverse .card-link:focus, .card-inverse .card-link:hover { - color: #fff; } - -.card-blockquote { - padding: 0; - margin-bottom: 0; - border-left: 0; } - -.card-img { - border-radius: calc(0.25rem - 1px); } - -.card-img-overlay { - position: absolute; - top: 0; - right: 0; - bottom: 0; - left: 0; - padding: 1.25rem; } - -.card-img-top { - border-top-right-radius: calc(0.25rem - 1px); - border-top-left-radius: calc(0.25rem - 1px); } - -.card-img-bottom { - border-bottom-right-radius: calc(0.25rem - 1px); - border-bottom-left-radius: calc(0.25rem - 1px); } - -@media (min-width: 576px) { - .card-deck { - display: flex; - flex-flow: row wrap; } - .card-deck .card { - display: flex; - flex: 1 0 0; - flex-direction: column; } - .card-deck .card:not(:first-child) { - margin-left: 15px; } - .card-deck .card:not(:last-child) { - margin-right: 15px; } } - -@media (min-width: 576px) { - .card-group { - display: flex; - flex-flow: row wrap; } - .card-group .card { - flex: 1 0 0; } - .card-group .card + .card { - margin-left: 0; - border-left: 0; } - .card-group .card:first-child { - border-bottom-right-radius: 0; - border-top-right-radius: 0; } - .card-group .card:first-child .card-img-top { - border-top-right-radius: 0; } - .card-group .card:first-child .card-img-bottom { - border-bottom-right-radius: 0; } - .card-group .card:last-child { - border-bottom-left-radius: 0; - border-top-left-radius: 0; } - .card-group .card:last-child .card-img-top { - border-top-left-radius: 0; } - .card-group .card:last-child .card-img-bottom { - border-bottom-left-radius: 0; } - .card-group .card:not(:first-child):not(:last-child) { - border-radius: 0; } - .card-group .card:not(:first-child):not(:last-child) .card-img-top, - .card-group .card:not(:first-child):not(:last-child) .card-img-bottom { - border-radius: 0; } } - -@media (min-width: 576px) { - .card-columns { - column-count: 3; - column-gap: 1.25rem; } - .card-columns .card { - display: inline-block; - width: 100%; - margin-bottom: 0.75rem; } } - -.breadcrumb { - padding: 0.75rem 1rem; - margin-bottom: 1rem; - list-style: none; - background-color: #eceeef; - border-radius: 0.25rem; } - .breadcrumb::after { - display: block; - content: ""; - clear: both; } - -.breadcrumb-item { - float: left; } - .breadcrumb-item + .breadcrumb-item::before { - display: inline-block; - padding-right: 0.5rem; - padding-left: 0.5rem; - color: #d5d5d5; - content: "/"; } - .breadcrumb-item + .breadcrumb-item:hover::before { - text-decoration: underline; } - .breadcrumb-item + .breadcrumb-item:hover::before { - text-decoration: none; } - .breadcrumb-item.active { - color: #d5d5d5; } - -.pagination { - display: flex; - padding-left: 0; - list-style: none; - border-radius: 0.25rem; } - -.page-item:first-child .page-link { - margin-left: 0; - border-bottom-left-radius: 0.25rem; - border-top-left-radius: 0.25rem; } - -.page-item:last-child .page-link { - border-bottom-right-radius: 0.25rem; - border-top-right-radius: 0.25rem; } - -.page-item.active .page-link { - z-index: 2; - color: #fff; - background-color: #0275d8; - border-color: #0275d8; } - -.page-item.disabled .page-link { - color: #d5d5d5; - pointer-events: none; - cursor: not-allowed; - background-color: #fff; - border-color: #ddd; } - -.page-link { - position: relative; - display: block; - padding: 0.5rem 0.75rem; - margin-left: -1px; - line-height: 1.25; - color: #0275d8; - background-color: #fff; - border: 1px solid #ddd; } - .page-link:focus, .page-link:hover { - color: #014c8c; - text-decoration: none; - background-color: #eceeef; - border-color: #ddd; } - -.pagination-lg .page-link { - padding: 0.75rem 1.5rem; - font-size: 1.25rem; } - -.pagination-lg .page-item:first-child .page-link { - border-bottom-left-radius: 0.3rem; - border-top-left-radius: 0.3rem; } - -.pagination-lg .page-item:last-child .page-link { - border-bottom-right-radius: 0.3rem; - border-top-right-radius: 0.3rem; } - -.pagination-sm .page-link { - padding: 0.25rem 0.5rem; - font-size: 0.875rem; } - -.pagination-sm .page-item:first-child .page-link { - border-bottom-left-radius: 0.2rem; - border-top-left-radius: 0.2rem; } - -.pagination-sm .page-item:last-child .page-link { - border-bottom-right-radius: 0.2rem; - border-top-right-radius: 0.2rem; } - -.badge { - display: inline-block; - padding: 0.25em 0.4em; - font-size: 75%; - font-weight: bold; - line-height: 1; - color: #fff; - text-align: center; - white-space: nowrap; - vertical-align: baseline; - border-radius: 0.25rem; } - .badge:empty { - display: none; } - -.btn .badge { - position: relative; - top: -1px; } - -a.badge:focus, a.badge:hover { - color: #fff; - text-decoration: none; - cursor: pointer; } - -.badge-pill { - padding-right: 0.6em; - padding-left: 0.6em; - border-radius: 10rem; } - -.badge-default { - background-color: #d5d5d5; } - .badge-default[href]:focus, .badge-default[href]:hover { - background-color: #bcbcbc; } - -.badge-primary { - background-color: #0275d8; } - .badge-primary[href]:focus, .badge-primary[href]:hover { - background-color: #025aa5; } - -.badge-success { - background-color: #5cb85c; } - .badge-success[href]:focus, .badge-success[href]:hover { - background-color: #449d44; } - -.badge-info { - background-color: #5bc0de; } - .badge-info[href]:focus, .badge-info[href]:hover { - background-color: #31b0d5; } - -.badge-warning { - background-color: #f0ad4e; } - .badge-warning[href]:focus, .badge-warning[href]:hover { - background-color: #ec971f; } - -.badge-danger { - background-color: #d9534f; } - .badge-danger[href]:focus, .badge-danger[href]:hover { - background-color: #c9302c; } - -.jumbotron { - padding: 2rem 1rem; - margin-bottom: 2rem; - background-color: #eceeef; - border-radius: 0.3rem; } - @media (min-width: 576px) { - .jumbotron { - padding: 4rem 2rem; } } - -.jumbotron-hr { - border-top-color: #d0d5d8; } - -.jumbotron-fluid { - padding-right: 0; - padding-left: 0; - border-radius: 0; } - -.alert { - padding: 0.75rem 1.25rem; - margin-bottom: 1rem; - border: 1px solid transparent; - border-radius: 0.25rem; } - -.alert-heading { - color: inherit; } - -.alert-link { - font-weight: bold; } - -.alert-dismissible .close { - position: relative; - top: -0.75rem; - right: -1.25rem; - padding: 0.75rem 1.25rem; - color: inherit; } - -.alert-success { - background-color: #dff0d8; - border-color: #d0e9c6; - color: #3c763d; } - .alert-success hr { - border-top-color: #c1e2b3; } - .alert-success .alert-link { - color: #2b542c; } - -.alert-info { - background-color: #d9edf7; - border-color: #bcdff1; - color: #31708f; } - .alert-info hr { - border-top-color: #a6d5ec; } - .alert-info .alert-link { - color: #245269; } - -.alert-warning { - background-color: #fcf8e3; - border-color: #faf2cc; - color: #8a6d3b; } - .alert-warning hr { - border-top-color: #f7ecb5; } - .alert-warning .alert-link { - color: #66512c; } - -.alert-danger { - background-color: #f2dede; - border-color: #ebcccc; - color: #a94442; } - .alert-danger hr { - border-top-color: #e4b9b9; } - .alert-danger .alert-link { - color: #843534; } - -@keyframes progress-bar-stripes { - from { - background-position: 1rem 0; } - to { - background-position: 0 0; } } - -.progress { - display: flex; - overflow: hidden; - font-size: 0.75rem; - line-height: 1rem; - text-align: center; - background-color: #eceeef; - border-radius: 0.25rem; } - -.progress-bar { - height: 1rem; - color: #fff; - background-color: #0275d8; } - -.progress-bar-striped { - background-image: linear-gradient(45deg, rgba(255, 255, 255, 0.15) 25%, transparent 25%, transparent 50%, rgba(255, 255, 255, 0.15) 50%, rgba(255, 255, 255, 0.15) 75%, transparent 75%, transparent); - background-size: 1rem 1rem; } - -.progress-bar-animated { - animation: progress-bar-stripes 1s linear infinite; } - -.media { - display: flex; - align-items: flex-start; } - -.media-body { - flex: 1; } - -.list-group { - display: flex; - flex-direction: column; - padding-left: 0; - margin-bottom: 0; } - -.list-group-item-action { - width: 100%; - color: #55595c; - text-align: inherit; } - .list-group-item-action .list-group-item-heading { - color: #373a3c; } - .list-group-item-action:focus, .list-group-item-action:hover { - color: #55595c; - text-decoration: none; - background-color: #f3f3f3; } - .list-group-item-action:active { - color: #373a3c; - background-color: #eceeef; } - -.list-group-item { - position: relative; - display: flex; - flex-flow: row wrap; - align-items: center; - padding: 0.75rem 1.25rem; - margin-bottom: -1px; - background-color: #fff; - border: 1px solid rgba(0, 0, 0, 0.125); } - .list-group-item:first-child { - border-top-right-radius: 0.25rem; - border-top-left-radius: 0.25rem; } - .list-group-item:last-child { - margin-bottom: 0; - border-bottom-right-radius: 0.25rem; - border-bottom-left-radius: 0.25rem; } - .list-group-item:focus, .list-group-item:hover { - text-decoration: none; } - .list-group-item.disabled, .list-group-item:disabled { - color: #d5d5d5; - cursor: not-allowed; - background-color: #fff; } - .list-group-item.disabled .list-group-item-heading, .list-group-item:disabled .list-group-item-heading { - color: inherit; } - .list-group-item.disabled .list-group-item-text, .list-group-item:disabled .list-group-item-text { - color: #d5d5d5; } - .list-group-item.active { - z-index: 2; - color: #fff; - background-color: #0275d8; - border-color: #0275d8; } - .list-group-item.active .list-group-item-heading, - .list-group-item.active .list-group-item-heading > small, - .list-group-item.active .list-group-item-heading > .small { - color: inherit; } - .list-group-item.active .list-group-item-text { - color: #daeeff; } - -.list-group-flush .list-group-item { - border-right: 0; - border-left: 0; - border-radius: 0; } - -.list-group-flush:first-child .list-group-item:first-child { - border-top: 0; } - -.list-group-flush:last-child .list-group-item:last-child { - border-bottom: 0; } - -.list-group-item-success { - color: #3c763d; - background-color: #dff0d8; } - -a.list-group-item-success, -button.list-group-item-success { - color: #3c763d; } - a.list-group-item-success .list-group-item-heading, - button.list-group-item-success .list-group-item-heading { - color: inherit; } - a.list-group-item-success:focus, a.list-group-item-success:hover, - button.list-group-item-success:focus, - button.list-group-item-success:hover { - color: #3c763d; - background-color: #d0e9c6; } - a.list-group-item-success.active, - button.list-group-item-success.active { - color: #fff; - background-color: #3c763d; - border-color: #3c763d; } - -.list-group-item-info { - color: #31708f; - background-color: #d9edf7; } - -a.list-group-item-info, -button.list-group-item-info { - color: #31708f; } - a.list-group-item-info .list-group-item-heading, - button.list-group-item-info .list-group-item-heading { - color: inherit; } - a.list-group-item-info:focus, a.list-group-item-info:hover, - button.list-group-item-info:focus, - button.list-group-item-info:hover { - color: #31708f; - background-color: #c4e3f3; } - a.list-group-item-info.active, - button.list-group-item-info.active { - color: #fff; - background-color: #31708f; - border-color: #31708f; } - -.list-group-item-warning { - color: #8a6d3b; - background-color: #fcf8e3; } - -a.list-group-item-warning, -button.list-group-item-warning { - color: #8a6d3b; } - a.list-group-item-warning .list-group-item-heading, - button.list-group-item-warning .list-group-item-heading { - color: inherit; } - a.list-group-item-warning:focus, a.list-group-item-warning:hover, - button.list-group-item-warning:focus, - button.list-group-item-warning:hover { - color: #8a6d3b; - background-color: #faf2cc; } - a.list-group-item-warning.active, - button.list-group-item-warning.active { - color: #fff; - background-color: #8a6d3b; - border-color: #8a6d3b; } - -.list-group-item-danger { - color: #a94442; - background-color: #f2dede; } - -a.list-group-item-danger, -button.list-group-item-danger { - color: #a94442; } - a.list-group-item-danger .list-group-item-heading, - button.list-group-item-danger .list-group-item-heading { - color: inherit; } - a.list-group-item-danger:focus, a.list-group-item-danger:hover, - button.list-group-item-danger:focus, - button.list-group-item-danger:hover { - color: #a94442; - background-color: #ebcccc; } - a.list-group-item-danger.active, - button.list-group-item-danger.active { - color: #fff; - background-color: #a94442; - border-color: #a94442; } - -.embed-responsive { - position: relative; - display: block; - width: 100%; - padding: 0; - overflow: hidden; } - .embed-responsive::before { - display: block; - content: ""; } - .embed-responsive .embed-responsive-item, - .embed-responsive iframe, - .embed-responsive embed, - .embed-responsive object, - .embed-responsive video { - position: absolute; - top: 0; - bottom: 0; - left: 0; - width: 100%; - height: 100%; - border: 0; } - -.embed-responsive-21by9::before { - padding-top: 42.85714%; } - -.embed-responsive-16by9::before { - padding-top: 56.25%; } - -.embed-responsive-4by3::before { - padding-top: 75%; } - -.embed-responsive-1by1::before { - padding-top: 100%; } - -.close { - float: right; - font-size: 1.5rem; - font-weight: bold; - line-height: 1; - color: #000; - text-shadow: 0 1px 0 #fff; - opacity: .5; } - .close:focus, .close:hover { - color: #000; - text-decoration: none; - cursor: pointer; - opacity: .75; } - -button.close { - padding: 0; - cursor: pointer; - background: transparent; - border: 0; - -webkit-appearance: none; } - -.modal-open { - overflow: hidden; } - -.modal { - position: fixed; - top: 0; - right: 0; - bottom: 0; - left: 0; - z-index: 1050; - display: none; - overflow: hidden; - outline: 0; } - .modal.fade .modal-dialog { - transition: transform 0.3s ease-out; - transform: translate(0, -25%); } - .modal.show .modal-dialog { - transform: translate(0, 0); } - -.modal-open .modal { - overflow-x: hidden; - overflow-y: auto; } - -.modal-dialog { - position: relative; - width: auto; - margin: 10px; } - -.modal-content { - position: relative; - display: flex; - flex-direction: column; - background-color: #fff; - background-clip: padding-box; - border: 1px solid rgba(0, 0, 0, 0.2); - border-radius: 0.3rem; - outline: 0; } - -.modal-backdrop { - position: fixed; - top: 0; - right: 0; - bottom: 0; - left: 0; - z-index: 1040; - background-color: #000; } - .modal-backdrop.fade { - opacity: 0; } - .modal-backdrop.show { - opacity: 0.5; } - -.modal-header { - display: flex; - align-items: center; - justify-content: space-between; - padding: 15px; - border-bottom: 1px solid #eceeef; } - -.modal-title { - margin-bottom: 0; - line-height: 1.5; } - -.modal-body { - position: relative; - flex: 1 1 auto; - padding: 15px; } - -.modal-footer { - display: flex; - align-items: center; - justify-content: flex-end; - padding: 15px; - border-top: 1px solid #eceeef; } - .modal-footer > :not(:first-child) { - margin-left: .25rem; } - .modal-footer > :not(:last-child) { - margin-right: .25rem; } - -.modal-scrollbar-measure { - position: absolute; - top: -9999px; - width: 50px; - height: 50px; - overflow: scroll; } - -@media (min-width: 576px) { - .modal-dialog { - max-width: 500px; - margin: 30px auto; } - .modal-sm { - max-width: 300px; } } - -@media (min-width: 992px) { - .modal-lg { - max-width: 800px; } } - -.tooltip { - position: absolute; - z-index: 1070; - display: block; - font-family: "Open Sans"; - font-style: normal; - font-weight: normal; - letter-spacing: normal; - line-break: auto; - line-height: 1.5; - text-align: left; - text-align: start; - text-decoration: none; - text-shadow: none; - text-transform: none; - white-space: normal; - word-break: normal; - word-spacing: normal; - font-size: 0.875rem; - word-wrap: break-word; - opacity: 0; } - .tooltip.show { - opacity: 0.9; } - .tooltip.tooltip-top, .tooltip.bs-tether-element-attached-bottom { - padding: 5px 0; - margin-top: -3px; } - .tooltip.tooltip-top .tooltip-inner::before, .tooltip.bs-tether-element-attached-bottom .tooltip-inner::before { - bottom: 0; - left: 50%; - margin-left: -5px; - content: ""; - border-width: 5px 5px 0; - border-top-color: #000; } - .tooltip.tooltip-right, .tooltip.bs-tether-element-attached-left { - padding: 0 5px; - margin-left: 3px; } - .tooltip.tooltip-right .tooltip-inner::before, .tooltip.bs-tether-element-attached-left .tooltip-inner::before { - top: 50%; - left: 0; - margin-top: -5px; - content: ""; - border-width: 5px 5px 5px 0; - border-right-color: #000; } - .tooltip.tooltip-bottom, .tooltip.bs-tether-element-attached-top { - padding: 5px 0; - margin-top: 3px; } - .tooltip.tooltip-bottom .tooltip-inner::before, .tooltip.bs-tether-element-attached-top .tooltip-inner::before { - top: 0; - left: 50%; - margin-left: -5px; - content: ""; - border-width: 0 5px 5px; - border-bottom-color: #000; } - .tooltip.tooltip-left, .tooltip.bs-tether-element-attached-right { - padding: 0 5px; - margin-left: -3px; } - .tooltip.tooltip-left .tooltip-inner::before, .tooltip.bs-tether-element-attached-right .tooltip-inner::before { - top: 50%; - right: 0; - margin-top: -5px; - content: ""; - border-width: 5px 0 5px 5px; - border-left-color: #000; } - -.tooltip-inner { - max-width: 200px; - padding: 3px 8px; - color: #fff; - text-align: center; - background-color: #000; - border-radius: 0.25rem; } - .tooltip-inner::before { - position: absolute; - width: 0; - height: 0; - border-color: transparent; - border-style: solid; } - -.popover { - position: absolute; - top: 0; - left: 0; - z-index: 1060; - display: block; - max-width: 276px; - padding: 1px; - font-family: "Open Sans"; - font-style: normal; - font-weight: normal; - letter-spacing: normal; - line-break: auto; - line-height: 1.5; - text-align: left; - text-align: start; - text-decoration: none; - text-shadow: none; - text-transform: none; - white-space: normal; - word-break: normal; - word-spacing: normal; - font-size: 0.875rem; - word-wrap: break-word; - background-color: #fff; - background-clip: padding-box; - border: 1px solid rgba(0, 0, 0, 0.2); - border-radius: 0.3rem; } - .popover.popover-top, .popover.bs-tether-element-attached-bottom { - margin-top: -10px; } - .popover.popover-top::before, .popover.popover-top::after, .popover.bs-tether-element-attached-bottom::before, .popover.bs-tether-element-attached-bottom::after { - left: 50%; - border-bottom-width: 0; } - .popover.popover-top::before, .popover.bs-tether-element-attached-bottom::before { - bottom: -11px; - margin-left: -11px; - border-top-color: rgba(0, 0, 0, 0.25); } - .popover.popover-top::after, .popover.bs-tether-element-attached-bottom::after { - bottom: -10px; - margin-left: -10px; - border-top-color: #fff; } - .popover.popover-right, .popover.bs-tether-element-attached-left { - margin-left: 10px; } - .popover.popover-right::before, .popover.popover-right::after, .popover.bs-tether-element-attached-left::before, .popover.bs-tether-element-attached-left::after { - top: 50%; - border-left-width: 0; } - .popover.popover-right::before, .popover.bs-tether-element-attached-left::before { - left: -11px; - margin-top: -11px; - border-right-color: rgba(0, 0, 0, 0.25); } - .popover.popover-right::after, .popover.bs-tether-element-attached-left::after { - left: -10px; - margin-top: -10px; - border-right-color: #fff; } - .popover.popover-bottom, .popover.bs-tether-element-attached-top { - margin-top: 10px; } - .popover.popover-bottom::before, .popover.popover-bottom::after, .popover.bs-tether-element-attached-top::before, .popover.bs-tether-element-attached-top::after { - left: 50%; - border-top-width: 0; } - .popover.popover-bottom::before, .popover.bs-tether-element-attached-top::before { - top: -11px; - margin-left: -11px; - border-bottom-color: rgba(0, 0, 0, 0.25); } - .popover.popover-bottom::after, .popover.bs-tether-element-attached-top::after { - top: -10px; - margin-left: -10px; - border-bottom-color: #f7f7f7; } - .popover.popover-bottom .popover-title::before, .popover.bs-tether-element-attached-top .popover-title::before { - position: absolute; - top: 0; - left: 50%; - display: block; - width: 20px; - margin-left: -10px; - content: ""; - border-bottom: 1px solid #f7f7f7; } - .popover.popover-left, .popover.bs-tether-element-attached-right { - margin-left: -10px; } - .popover.popover-left::before, .popover.popover-left::after, .popover.bs-tether-element-attached-right::before, .popover.bs-tether-element-attached-right::after { - top: 50%; - border-right-width: 0; } - .popover.popover-left::before, .popover.bs-tether-element-attached-right::before { - right: -11px; - margin-top: -11px; - border-left-color: rgba(0, 0, 0, 0.25); } - .popover.popover-left::after, .popover.bs-tether-element-attached-right::after { - right: -10px; - margin-top: -10px; - border-left-color: #fff; } - -.popover-title { - padding: 8px 14px; - margin-bottom: 0; - font-size: 1rem; - background-color: #f7f7f7; - border-bottom: 1px solid #ebebeb; - border-top-right-radius: calc(0.3rem - 1px); - border-top-left-radius: calc(0.3rem - 1px); } - .popover-title:empty { - display: none; } - -.popover-content { - padding: 9px 14px; } - -.popover::before, -.popover::after { - position: absolute; - display: block; - width: 0; - height: 0; - border-color: transparent; - border-style: solid; } - -.popover::before { - content: ""; - border-width: 11px; } - -.popover::after { - content: ""; - border-width: 10px; } - -.carousel { - position: relative; } - -.carousel-inner { - position: relative; - width: 100%; - overflow: hidden; } - -.carousel-item { - position: relative; - display: none; - width: 100%; } - @media (-webkit-transform-3d) { - .carousel-item { - transition: transform 0.6s ease-in-out; - backface-visibility: hidden; - perspective: 1000px; } } - @supports (transform: translate3d(0, 0, 0)) { - .carousel-item { - transition: transform 0.6s ease-in-out; - backface-visibility: hidden; - perspective: 1000px; } } - -.carousel-item.active, -.carousel-item-next, -.carousel-item-prev { - display: flex; } - -.carousel-item-next, -.carousel-item-prev { - position: absolute; - top: 0; } - -@media (-webkit-transform-3d) { - .carousel-item-next.carousel-item-left, - .carousel-item-prev.carousel-item-right { - transform: translate3d(0, 0, 0); } - .carousel-item-next, - .active.carousel-item-right { - transform: translate3d(100%, 0, 0); } - .carousel-item-prev, - .active.carousel-item-left { - transform: translate3d(-100%, 0, 0); } } - -@supports (transform: translate3d(0, 0, 0)) { - .carousel-item-next.carousel-item-left, - .carousel-item-prev.carousel-item-right { - transform: translate3d(0, 0, 0); } - .carousel-item-next, - .active.carousel-item-right { - transform: translate3d(100%, 0, 0); } - .carousel-item-prev, - .active.carousel-item-left { - transform: translate3d(-100%, 0, 0); } } - -.carousel-control-prev, -.carousel-control-next { - position: absolute; - top: 0; - bottom: 0; - display: flex; - align-items: center; - justify-content: center; - width: 15%; - color: #fff; - text-align: center; - opacity: 0.5; } - .carousel-control-prev:focus, .carousel-control-prev:hover, - .carousel-control-next:focus, - .carousel-control-next:hover { - color: #fff; - text-decoration: none; - outline: 0; - opacity: .9; } - -.carousel-control-prev { - left: 0; } - -.carousel-control-next { - right: 0; } - -.carousel-control-prev-icon, -.carousel-control-next-icon { - display: inline-block; - width: 20px; - height: 20px; - background: transparent no-repeat center center; - background-size: 100% 100%; } - -.carousel-control-prev-icon { - background-image: url("data:image/svg+xml;charset=utf8,%3Csvg xmlns='http://www.w3.org/2000/svg' fill='%23fff' viewBox='0 0 8 8'%3E%3Cpath d='M4 0l-4 4 4 4 1.5-1.5-2.5-2.5 2.5-2.5-1.5-1.5z'/%3E%3C/svg%3E"); } - -.carousel-control-next-icon { - background-image: url("data:image/svg+xml;charset=utf8,%3Csvg xmlns='http://www.w3.org/2000/svg' fill='%23fff' viewBox='0 0 8 8'%3E%3Cpath d='M1.5 0l-1.5 1.5 2.5 2.5-2.5 2.5 1.5 1.5 4-4-4-4z'/%3E%3C/svg%3E"); } - -.carousel-indicators { - position: absolute; - right: 0; - bottom: 10px; - left: 0; - z-index: 15; - display: flex; - justify-content: center; - padding-left: 0; - margin-right: 15%; - margin-left: 15%; - list-style: none; } - .carousel-indicators li { - position: relative; - flex: 1 0 auto; - max-width: 30px; - height: 3px; - margin-right: 3px; - margin-left: 3px; - text-indent: -999px; - cursor: pointer; - background-color: rgba(255, 255, 255, 0.5); } - .carousel-indicators li::before { - position: absolute; - top: -10px; - left: 0; - display: inline-block; - width: 100%; - height: 10px; - content: ""; } - .carousel-indicators li::after { - position: absolute; - bottom: -10px; - left: 0; - display: inline-block; - width: 100%; - height: 10px; - content: ""; } - .carousel-indicators .active { - background-color: #fff; } - -.carousel-caption { - position: absolute; - right: 15%; - bottom: 20px; - left: 15%; - z-index: 10; - padding-top: 20px; - padding-bottom: 20px; - color: #fff; - text-align: center; } - -.align-baseline { - vertical-align: baseline !important; } - -.align-top { - vertical-align: top !important; } - -.align-middle { - vertical-align: middle !important; } - -.align-bottom { - vertical-align: bottom !important; } - -.align-text-bottom { - vertical-align: text-bottom !important; } - -.align-text-top { - vertical-align: text-top !important; } - -.bg-faded { - background-color: #f7f7f7; } - -.bg-primary { - background-color: #0275d8 !important; } - -a.bg-primary:focus, a.bg-primary:hover { - background-color: #025aa5 !important; } - -.bg-success { - background-color: #5cb85c !important; } - -a.bg-success:focus, a.bg-success:hover { - background-color: #449d44 !important; } - -.bg-info { - background-color: #5bc0de !important; } - -a.bg-info:focus, a.bg-info:hover { - background-color: #31b0d5 !important; } - -.bg-warning { - background-color: #f0ad4e !important; } - -a.bg-warning:focus, a.bg-warning:hover { - background-color: #ec971f !important; } - -.bg-danger { - background-color: #d9534f !important; } - -a.bg-danger:focus, a.bg-danger:hover { - background-color: #c9302c !important; } - -.bg-inverse { - background-color: #373a3c !important; } - -a.bg-inverse:focus, a.bg-inverse:hover { - background-color: #1f2021 !important; } - -.border-0 { - border: 0 !important; } - -.border-top-0 { - border-top: 0 !important; } - -.border-right-0 { - border-right: 0 !important; } - -.border-bottom-0 { - border-bottom: 0 !important; } - -.border-left-0 { - border-left: 0 !important; } - -.rounded { - border-radius: 0.25rem; } - -.rounded-top { - border-top-right-radius: 0.25rem; - border-top-left-radius: 0.25rem; } - -.rounded-right { - border-bottom-right-radius: 0.25rem; - border-top-right-radius: 0.25rem; } - -.rounded-bottom { - border-bottom-right-radius: 0.25rem; - border-bottom-left-radius: 0.25rem; } - -.rounded-left { - border-bottom-left-radius: 0.25rem; - border-top-left-radius: 0.25rem; } - -.rounded-circle { - border-radius: 50%; } - -.rounded-0 { - border-radius: 0; } - -.clearfix::after { - display: block; - content: ""; - clear: both; } - -.d-none { - display: none !important; } - -.d-inline { - display: inline !important; } - -.d-inline-block { - display: inline-block !important; } - -.d-block { - display: block !important; } - -.d-table { - display: table !important; } - -.d-table-cell { - display: table-cell !important; } - -.d-flex { - display: flex !important; } - -.d-inline-flex { - display: inline-flex !important; } - -@media (min-width: 576px) { - .d-sm-none { - display: none !important; } - .d-sm-inline { - display: inline !important; } - .d-sm-inline-block { - display: inline-block !important; } - .d-sm-block { - display: block !important; } - .d-sm-table { - display: table !important; } - .d-sm-table-cell { - display: table-cell !important; } - .d-sm-flex { - display: flex !important; } - .d-sm-inline-flex { - display: inline-flex !important; } } - -@media (min-width: 768px) { - .d-md-none { - display: none !important; } - .d-md-inline { - display: inline !important; } - .d-md-inline-block { - display: inline-block !important; } - .d-md-block { - display: block !important; } - .d-md-table { - display: table !important; } - .d-md-table-cell { - display: table-cell !important; } - .d-md-flex { - display: flex !important; } - .d-md-inline-flex { - display: inline-flex !important; } } - -@media (min-width: 992px) { - .d-lg-none { - display: none !important; } - .d-lg-inline { - display: inline !important; } - .d-lg-inline-block { - display: inline-block !important; } - .d-lg-block { - display: block !important; } - .d-lg-table { - display: table !important; } - .d-lg-table-cell { - display: table-cell !important; } - .d-lg-flex { - display: flex !important; } - .d-lg-inline-flex { - display: inline-flex !important; } } - -@media (min-width: 1200px) { - .d-xl-none { - display: none !important; } - .d-xl-inline { - display: inline !important; } - .d-xl-inline-block { - display: inline-block !important; } - .d-xl-block { - display: block !important; } - .d-xl-table { - display: table !important; } - .d-xl-table-cell { - display: table-cell !important; } - .d-xl-flex { - display: flex !important; } - .d-xl-inline-flex { - display: inline-flex !important; } } - -.flex-first { - order: -1; } - -.flex-last { - order: 1; } - -.flex-unordered { - order: 0; } - -.flex-row { - flex-direction: row !important; } - -.flex-column { - flex-direction: column !important; } - -.flex-row-reverse { - flex-direction: row-reverse !important; } - -.flex-column-reverse { - flex-direction: column-reverse !important; } - -.flex-wrap { - flex-wrap: wrap !important; } - -.flex-nowrap { - flex-wrap: nowrap !important; } - -.flex-wrap-reverse { - flex-wrap: wrap-reverse !important; } - -.justify-content-start { - justify-content: flex-start !important; } - -.justify-content-end { - justify-content: flex-end !important; } - -.justify-content-center { - justify-content: center !important; } - -.justify-content-between { - justify-content: space-between !important; } - -.justify-content-around { - justify-content: space-around !important; } - -.align-items-start { - align-items: flex-start !important; } - -.align-items-end { - align-items: flex-end !important; } - -.align-items-center { - align-items: center !important; } - -.align-items-baseline { - align-items: baseline !important; } - -.align-items-stretch { - align-items: stretch !important; } - -.align-content-start { - align-content: flex-start !important; } - -.align-content-end { - align-content: flex-end !important; } - -.align-content-center { - align-content: center !important; } - -.align-content-between { - align-content: space-between !important; } - -.align-content-around { - align-content: space-around !important; } - -.align-content-stretch { - align-content: stretch !important; } - -.align-self-auto { - align-self: auto !important; } - -.align-self-start { - align-self: flex-start !important; } - -.align-self-end { - align-self: flex-end !important; } - -.align-self-center { - align-self: center !important; } - -.align-self-baseline { - align-self: baseline !important; } - -.align-self-stretch { - align-self: stretch !important; } - -@media (min-width: 576px) { - .flex-sm-first { - order: -1; } - .flex-sm-last { - order: 1; } - .flex-sm-unordered { - order: 0; } - .flex-sm-row { - flex-direction: row !important; } - .flex-sm-column { - flex-direction: column !important; } - .flex-sm-row-reverse { - flex-direction: row-reverse !important; } - .flex-sm-column-reverse { - flex-direction: column-reverse !important; } - .flex-sm-wrap { - flex-wrap: wrap !important; } - .flex-sm-nowrap { - flex-wrap: nowrap !important; } - .flex-sm-wrap-reverse { - flex-wrap: wrap-reverse !important; } - .justify-content-sm-start { - justify-content: flex-start !important; } - .justify-content-sm-end { - justify-content: flex-end !important; } - .justify-content-sm-center { - justify-content: center !important; } - .justify-content-sm-between { - justify-content: space-between !important; } - .justify-content-sm-around { - justify-content: space-around !important; } - .align-items-sm-start { - align-items: flex-start !important; } - .align-items-sm-end { - align-items: flex-end !important; } - .align-items-sm-center { - align-items: center !important; } - .align-items-sm-baseline { - align-items: baseline !important; } - .align-items-sm-stretch { - align-items: stretch !important; } - .align-content-sm-start { - align-content: flex-start !important; } - .align-content-sm-end { - align-content: flex-end !important; } - .align-content-sm-center { - align-content: center !important; } - .align-content-sm-between { - align-content: space-between !important; } - .align-content-sm-around { - align-content: space-around !important; } - .align-content-sm-stretch { - align-content: stretch !important; } - .align-self-sm-auto { - align-self: auto !important; } - .align-self-sm-start { - align-self: flex-start !important; } - .align-self-sm-end { - align-self: flex-end !important; } - .align-self-sm-center { - align-self: center !important; } - .align-self-sm-baseline { - align-self: baseline !important; } - .align-self-sm-stretch { - align-self: stretch !important; } } - -@media (min-width: 768px) { - .flex-md-first { - order: -1; } - .flex-md-last { - order: 1; } - .flex-md-unordered { - order: 0; } - .flex-md-row { - flex-direction: row !important; } - .flex-md-column { - flex-direction: column !important; } - .flex-md-row-reverse { - flex-direction: row-reverse !important; } - .flex-md-column-reverse { - flex-direction: column-reverse !important; } - .flex-md-wrap { - flex-wrap: wrap !important; } - .flex-md-nowrap { - flex-wrap: nowrap !important; } - .flex-md-wrap-reverse { - flex-wrap: wrap-reverse !important; } - .justify-content-md-start { - justify-content: flex-start !important; } - .justify-content-md-end { - justify-content: flex-end !important; } - .justify-content-md-center { - justify-content: center !important; } - .justify-content-md-between { - justify-content: space-between !important; } - .justify-content-md-around { - justify-content: space-around !important; } - .align-items-md-start { - align-items: flex-start !important; } - .align-items-md-end { - align-items: flex-end !important; } - .align-items-md-center { - align-items: center !important; } - .align-items-md-baseline { - align-items: baseline !important; } - .align-items-md-stretch { - align-items: stretch !important; } - .align-content-md-start { - align-content: flex-start !important; } - .align-content-md-end { - align-content: flex-end !important; } - .align-content-md-center { - align-content: center !important; } - .align-content-md-between { - align-content: space-between !important; } - .align-content-md-around { - align-content: space-around !important; } - .align-content-md-stretch { - align-content: stretch !important; } - .align-self-md-auto { - align-self: auto !important; } - .align-self-md-start { - align-self: flex-start !important; } - .align-self-md-end { - align-self: flex-end !important; } - .align-self-md-center { - align-self: center !important; } - .align-self-md-baseline { - align-self: baseline !important; } - .align-self-md-stretch { - align-self: stretch !important; } } - -@media (min-width: 992px) { - .flex-lg-first { - order: -1; } - .flex-lg-last { - order: 1; } - .flex-lg-unordered { - order: 0; } - .flex-lg-row { - flex-direction: row !important; } - .flex-lg-column { - flex-direction: column !important; } - .flex-lg-row-reverse { - flex-direction: row-reverse !important; } - .flex-lg-column-reverse { - flex-direction: column-reverse !important; } - .flex-lg-wrap { - flex-wrap: wrap !important; } - .flex-lg-nowrap { - flex-wrap: nowrap !important; } - .flex-lg-wrap-reverse { - flex-wrap: wrap-reverse !important; } - .justify-content-lg-start { - justify-content: flex-start !important; } - .justify-content-lg-end { - justify-content: flex-end !important; } - .justify-content-lg-center { - justify-content: center !important; } - .justify-content-lg-between { - justify-content: space-between !important; } - .justify-content-lg-around { - justify-content: space-around !important; } - .align-items-lg-start { - align-items: flex-start !important; } - .align-items-lg-end { - align-items: flex-end !important; } - .align-items-lg-center { - align-items: center !important; } - .align-items-lg-baseline { - align-items: baseline !important; } - .align-items-lg-stretch { - align-items: stretch !important; } - .align-content-lg-start { - align-content: flex-start !important; } - .align-content-lg-end { - align-content: flex-end !important; } - .align-content-lg-center { - align-content: center !important; } - .align-content-lg-between { - align-content: space-between !important; } - .align-content-lg-around { - align-content: space-around !important; } - .align-content-lg-stretch { - align-content: stretch !important; } - .align-self-lg-auto { - align-self: auto !important; } - .align-self-lg-start { - align-self: flex-start !important; } - .align-self-lg-end { - align-self: flex-end !important; } - .align-self-lg-center { - align-self: center !important; } - .align-self-lg-baseline { - align-self: baseline !important; } - .align-self-lg-stretch { - align-self: stretch !important; } } - -@media (min-width: 1200px) { - .flex-xl-first { - order: -1; } - .flex-xl-last { - order: 1; } - .flex-xl-unordered { - order: 0; } - .flex-xl-row { - flex-direction: row !important; } - .flex-xl-column { - flex-direction: column !important; } - .flex-xl-row-reverse { - flex-direction: row-reverse !important; } - .flex-xl-column-reverse { - flex-direction: column-reverse !important; } - .flex-xl-wrap { - flex-wrap: wrap !important; } - .flex-xl-nowrap { - flex-wrap: nowrap !important; } - .flex-xl-wrap-reverse { - flex-wrap: wrap-reverse !important; } - .justify-content-xl-start { - justify-content: flex-start !important; } - .justify-content-xl-end { - justify-content: flex-end !important; } - .justify-content-xl-center { - justify-content: center !important; } - .justify-content-xl-between { - justify-content: space-between !important; } - .justify-content-xl-around { - justify-content: space-around !important; } - .align-items-xl-start { - align-items: flex-start !important; } - .align-items-xl-end { - align-items: flex-end !important; } - .align-items-xl-center { - align-items: center !important; } - .align-items-xl-baseline { - align-items: baseline !important; } - .align-items-xl-stretch { - align-items: stretch !important; } - .align-content-xl-start { - align-content: flex-start !important; } - .align-content-xl-end { - align-content: flex-end !important; } - .align-content-xl-center { - align-content: center !important; } - .align-content-xl-between { - align-content: space-between !important; } - .align-content-xl-around { - align-content: space-around !important; } - .align-content-xl-stretch { - align-content: stretch !important; } - .align-self-xl-auto { - align-self: auto !important; } - .align-self-xl-start { - align-self: flex-start !important; } - .align-self-xl-end { - align-self: flex-end !important; } - .align-self-xl-center { - align-self: center !important; } - .align-self-xl-baseline { - align-self: baseline !important; } - .align-self-xl-stretch { - align-self: stretch !important; } } - -.float-left { - float: left !important; } - -.float-right { - float: right !important; } - -.float-none { - float: none !important; } - -@media (min-width: 576px) { - .float-sm-left { - float: left !important; } - .float-sm-right { - float: right !important; } - .float-sm-none { - float: none !important; } } - -@media (min-width: 768px) { - .float-md-left { - float: left !important; } - .float-md-right { - float: right !important; } - .float-md-none { - float: none !important; } } - -@media (min-width: 992px) { - .float-lg-left { - float: left !important; } - .float-lg-right { - float: right !important; } - .float-lg-none { - float: none !important; } } - -@media (min-width: 1200px) { - .float-xl-left { - float: left !important; } - .float-xl-right { - float: right !important; } - .float-xl-none { - float: none !important; } } - -.fixed-top { - position: fixed; - top: 0; - right: 0; - left: 0; - z-index: 1030; } - -.fixed-bottom { - position: fixed; - right: 0; - bottom: 0; - left: 0; - z-index: 1030; } - -.sticky-top { - position: sticky; - top: 0; - z-index: 1030; } - -.sr-only { - position: absolute; - width: 1px; - height: 1px; - padding: 0; - margin: -1px; - overflow: hidden; - clip: rect(0, 0, 0, 0); - border: 0; } - -.sr-only-focusable:active, .sr-only-focusable:focus { - position: static; - width: auto; - height: auto; - margin: 0; - overflow: visible; - clip: auto; } - -.w-25 { - width: 25% !important; } - -.w-50 { - width: 50% !important; } - -.w-75 { - width: 75% !important; } - -.w-100 { - width: 100% !important; } - -.h-25 { - height: 25% !important; } - -.h-50 { - height: 50% !important; } - -.h-75 { - height: 75% !important; } - -.h-100 { - height: 100% !important; } - -.mw-100 { - max-width: 100% !important; } - -.mh-100 { - max-height: 100% !important; } - -.m-0 { - margin: 0 0 !important; } - -.mt-0 { - margin-top: 0 !important; } - -.mr-0 { - margin-right: 0 !important; } - -.mb-0 { - margin-bottom: 0 !important; } - -.ml-0 { - margin-left: 0 !important; } - -.mx-0 { - margin-right: 0 !important; - margin-left: 0 !important; } - -.my-0 { - margin-top: 0 !important; - margin-bottom: 0 !important; } - -.m-1 { - margin: 0.25rem 0.25rem !important; } - -.mt-1 { - margin-top: 0.25rem !important; } - -.mr-1 { - margin-right: 0.25rem !important; } - -.mb-1 { - margin-bottom: 0.25rem !important; } - -.ml-1 { - margin-left: 0.25rem !important; } - -.mx-1 { - margin-right: 0.25rem !important; - margin-left: 0.25rem !important; } - -.my-1 { - margin-top: 0.25rem !important; - margin-bottom: 0.25rem !important; } - -.m-2 { - margin: 0.5rem 0.5rem !important; } - -.mt-2 { - margin-top: 0.5rem !important; } - -.mr-2 { - margin-right: 0.5rem !important; } - -.mb-2 { - margin-bottom: 0.5rem !important; } - -.ml-2 { - margin-left: 0.5rem !important; } - -.mx-2 { - margin-right: 0.5rem !important; - margin-left: 0.5rem !important; } - -.my-2 { - margin-top: 0.5rem !important; - margin-bottom: 0.5rem !important; } - -.m-3 { - margin: 1rem 1rem !important; } - -.mt-3 { - margin-top: 1rem !important; } - -.mr-3 { - margin-right: 1rem !important; } - -.mb-3 { - margin-bottom: 1rem !important; } - -.ml-3 { - margin-left: 1rem !important; } - -.mx-3 { - margin-right: 1rem !important; - margin-left: 1rem !important; } - -.my-3 { - margin-top: 1rem !important; - margin-bottom: 1rem !important; } - -.m-4 { - margin: 1.5rem 1.5rem !important; } - -.mt-4 { - margin-top: 1.5rem !important; } - -.mr-4 { - margin-right: 1.5rem !important; } - -.mb-4 { - margin-bottom: 1.5rem !important; } - -.ml-4 { - margin-left: 1.5rem !important; } - -.mx-4 { - margin-right: 1.5rem !important; - margin-left: 1.5rem !important; } - -.my-4 { - margin-top: 1.5rem !important; - margin-bottom: 1.5rem !important; } - -.m-5 { - margin: 3rem 3rem !important; } - -.mt-5 { - margin-top: 3rem !important; } - -.mr-5 { - margin-right: 3rem !important; } - -.mb-5 { - margin-bottom: 3rem !important; } - -.ml-5 { - margin-left: 3rem !important; } - -.mx-5 { - margin-right: 3rem !important; - margin-left: 3rem !important; } - -.my-5 { - margin-top: 3rem !important; - margin-bottom: 3rem !important; } - -.p-0 { - padding: 0 0 !important; } - -.pt-0 { - padding-top: 0 !important; } - -.pr-0 { - padding-right: 0 !important; } - -.pb-0 { - padding-bottom: 0 !important; } - -.pl-0 { - padding-left: 0 !important; } - -.px-0 { - padding-right: 0 !important; - padding-left: 0 !important; } - -.py-0 { - padding-top: 0 !important; - padding-bottom: 0 !important; } - -.p-1 { - padding: 0.25rem 0.25rem !important; } - -.pt-1 { - padding-top: 0.25rem !important; } - -.pr-1 { - padding-right: 0.25rem !important; } - -.pb-1 { - padding-bottom: 0.25rem !important; } - -.pl-1 { - padding-left: 0.25rem !important; } - -.px-1 { - padding-right: 0.25rem !important; - padding-left: 0.25rem !important; } - -.py-1 { - padding-top: 0.25rem !important; - padding-bottom: 0.25rem !important; } - -.p-2 { - padding: 0.5rem 0.5rem !important; } - -.pt-2 { - padding-top: 0.5rem !important; } - -.pr-2 { - padding-right: 0.5rem !important; } - -.pb-2 { - padding-bottom: 0.5rem !important; } - -.pl-2 { - padding-left: 0.5rem !important; } - -.px-2 { - padding-right: 0.5rem !important; - padding-left: 0.5rem !important; } - -.py-2 { - padding-top: 0.5rem !important; - padding-bottom: 0.5rem !important; } - -.p-3 { - padding: 1rem 1rem !important; } - -.pt-3 { - padding-top: 1rem !important; } - -.pr-3 { - padding-right: 1rem !important; } - -.pb-3 { - padding-bottom: 1rem !important; } - -.pl-3 { - padding-left: 1rem !important; } - -.px-3 { - padding-right: 1rem !important; - padding-left: 1rem !important; } - -.py-3 { - padding-top: 1rem !important; - padding-bottom: 1rem !important; } - -.p-4 { - padding: 1.5rem 1.5rem !important; } - -.pt-4 { - padding-top: 1.5rem !important; } - -.pr-4 { - padding-right: 1.5rem !important; } - -.pb-4 { - padding-bottom: 1.5rem !important; } - -.pl-4 { - padding-left: 1.5rem !important; } - -.px-4 { - padding-right: 1.5rem !important; - padding-left: 1.5rem !important; } - -.py-4 { - padding-top: 1.5rem !important; - padding-bottom: 1.5rem !important; } - -.p-5 { - padding: 3rem 3rem !important; } - -.pt-5 { - padding-top: 3rem !important; } - -.pr-5 { - padding-right: 3rem !important; } - -.pb-5 { - padding-bottom: 3rem !important; } - -.pl-5 { - padding-left: 3rem !important; } - -.px-5 { - padding-right: 3rem !important; - padding-left: 3rem !important; } - -.py-5 { - padding-top: 3rem !important; - padding-bottom: 3rem !important; } - -.m-auto { - margin: auto !important; } - -.mt-auto { - margin-top: auto !important; } - -.mr-auto { - margin-right: auto !important; } - -.mb-auto { - margin-bottom: auto !important; } - -.ml-auto { - margin-left: auto !important; } - -.mx-auto { - margin-right: auto !important; - margin-left: auto !important; } - -.my-auto { - margin-top: auto !important; - margin-bottom: auto !important; } - -@media (min-width: 576px) { - .m-sm-0 { - margin: 0 0 !important; } - .mt-sm-0 { - margin-top: 0 !important; } - .mr-sm-0 { - margin-right: 0 !important; } - .mb-sm-0 { - margin-bottom: 0 !important; } - .ml-sm-0 { - margin-left: 0 !important; } - .mx-sm-0 { - margin-right: 0 !important; - margin-left: 0 !important; } - .my-sm-0 { - margin-top: 0 !important; - margin-bottom: 0 !important; } - .m-sm-1 { - margin: 0.25rem 0.25rem !important; } - .mt-sm-1 { - margin-top: 0.25rem !important; } - .mr-sm-1 { - margin-right: 0.25rem !important; } - .mb-sm-1 { - margin-bottom: 0.25rem !important; } - .ml-sm-1 { - margin-left: 0.25rem !important; } - .mx-sm-1 { - margin-right: 0.25rem !important; - margin-left: 0.25rem !important; } - .my-sm-1 { - margin-top: 0.25rem !important; - margin-bottom: 0.25rem !important; } - .m-sm-2 { - margin: 0.5rem 0.5rem !important; } - .mt-sm-2 { - margin-top: 0.5rem !important; } - .mr-sm-2 { - margin-right: 0.5rem !important; } - .mb-sm-2 { - margin-bottom: 0.5rem !important; } - .ml-sm-2 { - margin-left: 0.5rem !important; } - .mx-sm-2 { - margin-right: 0.5rem !important; - margin-left: 0.5rem !important; } - .my-sm-2 { - margin-top: 0.5rem !important; - margin-bottom: 0.5rem !important; } - .m-sm-3 { - margin: 1rem 1rem !important; } - .mt-sm-3 { - margin-top: 1rem !important; } - .mr-sm-3 { - margin-right: 1rem !important; } - .mb-sm-3 { - margin-bottom: 1rem !important; } - .ml-sm-3 { - margin-left: 1rem !important; } - .mx-sm-3 { - margin-right: 1rem !important; - margin-left: 1rem !important; } - .my-sm-3 { - margin-top: 1rem !important; - margin-bottom: 1rem !important; } - .m-sm-4 { - margin: 1.5rem 1.5rem !important; } - .mt-sm-4 { - margin-top: 1.5rem !important; } - .mr-sm-4 { - margin-right: 1.5rem !important; } - .mb-sm-4 { - margin-bottom: 1.5rem !important; } - .ml-sm-4 { - margin-left: 1.5rem !important; } - .mx-sm-4 { - margin-right: 1.5rem !important; - margin-left: 1.5rem !important; } - .my-sm-4 { - margin-top: 1.5rem !important; - margin-bottom: 1.5rem !important; } - .m-sm-5 { - margin: 3rem 3rem !important; } - .mt-sm-5 { - margin-top: 3rem !important; } - .mr-sm-5 { - margin-right: 3rem !important; } - .mb-sm-5 { - margin-bottom: 3rem !important; } - .ml-sm-5 { - margin-left: 3rem !important; } - .mx-sm-5 { - margin-right: 3rem !important; - margin-left: 3rem !important; } - .my-sm-5 { - margin-top: 3rem !important; - margin-bottom: 3rem !important; } - .p-sm-0 { - padding: 0 0 !important; } - .pt-sm-0 { - padding-top: 0 !important; } - .pr-sm-0 { - padding-right: 0 !important; } - .pb-sm-0 { - padding-bottom: 0 !important; } - .pl-sm-0 { - padding-left: 0 !important; } - .px-sm-0 { - padding-right: 0 !important; - padding-left: 0 !important; } - .py-sm-0 { - padding-top: 0 !important; - padding-bottom: 0 !important; } - .p-sm-1 { - padding: 0.25rem 0.25rem !important; } - .pt-sm-1 { - padding-top: 0.25rem !important; } - .pr-sm-1 { - padding-right: 0.25rem !important; } - .pb-sm-1 { - padding-bottom: 0.25rem !important; } - .pl-sm-1 { - padding-left: 0.25rem !important; } - .px-sm-1 { - padding-right: 0.25rem !important; - padding-left: 0.25rem !important; } - .py-sm-1 { - padding-top: 0.25rem !important; - padding-bottom: 0.25rem !important; } - .p-sm-2 { - padding: 0.5rem 0.5rem !important; } - .pt-sm-2 { - padding-top: 0.5rem !important; } - .pr-sm-2 { - padding-right: 0.5rem !important; } - .pb-sm-2 { - padding-bottom: 0.5rem !important; } - .pl-sm-2 { - padding-left: 0.5rem !important; } - .px-sm-2 { - padding-right: 0.5rem !important; - padding-left: 0.5rem !important; } - .py-sm-2 { - padding-top: 0.5rem !important; - padding-bottom: 0.5rem !important; } - .p-sm-3 { - padding: 1rem 1rem !important; } - .pt-sm-3 { - padding-top: 1rem !important; } - .pr-sm-3 { - padding-right: 1rem !important; } - .pb-sm-3 { - padding-bottom: 1rem !important; } - .pl-sm-3 { - padding-left: 1rem !important; } - .px-sm-3 { - padding-right: 1rem !important; - padding-left: 1rem !important; } - .py-sm-3 { - padding-top: 1rem !important; - padding-bottom: 1rem !important; } - .p-sm-4 { - padding: 1.5rem 1.5rem !important; } - .pt-sm-4 { - padding-top: 1.5rem !important; } - .pr-sm-4 { - padding-right: 1.5rem !important; } - .pb-sm-4 { - padding-bottom: 1.5rem !important; } - .pl-sm-4 { - padding-left: 1.5rem !important; } - .px-sm-4 { - padding-right: 1.5rem !important; - padding-left: 1.5rem !important; } - .py-sm-4 { - padding-top: 1.5rem !important; - padding-bottom: 1.5rem !important; } - .p-sm-5 { - padding: 3rem 3rem !important; } - .pt-sm-5 { - padding-top: 3rem !important; } - .pr-sm-5 { - padding-right: 3rem !important; } - .pb-sm-5 { - padding-bottom: 3rem !important; } - .pl-sm-5 { - padding-left: 3rem !important; } - .px-sm-5 { - padding-right: 3rem !important; - padding-left: 3rem !important; } - .py-sm-5 { - padding-top: 3rem !important; - padding-bottom: 3rem !important; } - .m-sm-auto { - margin: auto !important; } - .mt-sm-auto { - margin-top: auto !important; } - .mr-sm-auto { - margin-right: auto !important; } - .mb-sm-auto { - margin-bottom: auto !important; } - .ml-sm-auto { - margin-left: auto !important; } - .mx-sm-auto { - margin-right: auto !important; - margin-left: auto !important; } - .my-sm-auto { - margin-top: auto !important; - margin-bottom: auto !important; } } - -@media (min-width: 768px) { - .m-md-0 { - margin: 0 0 !important; } - .mt-md-0 { - margin-top: 0 !important; } - .mr-md-0 { - margin-right: 0 !important; } - .mb-md-0 { - margin-bottom: 0 !important; } - .ml-md-0 { - margin-left: 0 !important; } - .mx-md-0 { - margin-right: 0 !important; - margin-left: 0 !important; } - .my-md-0 { - margin-top: 0 !important; - margin-bottom: 0 !important; } - .m-md-1 { - margin: 0.25rem 0.25rem !important; } - .mt-md-1 { - margin-top: 0.25rem !important; } - .mr-md-1 { - margin-right: 0.25rem !important; } - .mb-md-1 { - margin-bottom: 0.25rem !important; } - .ml-md-1 { - margin-left: 0.25rem !important; } - .mx-md-1 { - margin-right: 0.25rem !important; - margin-left: 0.25rem !important; } - .my-md-1 { - margin-top: 0.25rem !important; - margin-bottom: 0.25rem !important; } - .m-md-2 { - margin: 0.5rem 0.5rem !important; } - .mt-md-2 { - margin-top: 0.5rem !important; } - .mr-md-2 { - margin-right: 0.5rem !important; } - .mb-md-2 { - margin-bottom: 0.5rem !important; } - .ml-md-2 { - margin-left: 0.5rem !important; } - .mx-md-2 { - margin-right: 0.5rem !important; - margin-left: 0.5rem !important; } - .my-md-2 { - margin-top: 0.5rem !important; - margin-bottom: 0.5rem !important; } - .m-md-3 { - margin: 1rem 1rem !important; } - .mt-md-3 { - margin-top: 1rem !important; } - .mr-md-3 { - margin-right: 1rem !important; } - .mb-md-3 { - margin-bottom: 1rem !important; } - .ml-md-3 { - margin-left: 1rem !important; } - .mx-md-3 { - margin-right: 1rem !important; - margin-left: 1rem !important; } - .my-md-3 { - margin-top: 1rem !important; - margin-bottom: 1rem !important; } - .m-md-4 { - margin: 1.5rem 1.5rem !important; } - .mt-md-4 { - margin-top: 1.5rem !important; } - .mr-md-4 { - margin-right: 1.5rem !important; } - .mb-md-4 { - margin-bottom: 1.5rem !important; } - .ml-md-4 { - margin-left: 1.5rem !important; } - .mx-md-4 { - margin-right: 1.5rem !important; - margin-left: 1.5rem !important; } - .my-md-4 { - margin-top: 1.5rem !important; - margin-bottom: 1.5rem !important; } - .m-md-5 { - margin: 3rem 3rem !important; } - .mt-md-5 { - margin-top: 3rem !important; } - .mr-md-5 { - margin-right: 3rem !important; } - .mb-md-5 { - margin-bottom: 3rem !important; } - .ml-md-5 { - margin-left: 3rem !important; } - .mx-md-5 { - margin-right: 3rem !important; - margin-left: 3rem !important; } - .my-md-5 { - margin-top: 3rem !important; - margin-bottom: 3rem !important; } - .p-md-0 { - padding: 0 0 !important; } - .pt-md-0 { - padding-top: 0 !important; } - .pr-md-0 { - padding-right: 0 !important; } - .pb-md-0 { - padding-bottom: 0 !important; } - .pl-md-0 { - padding-left: 0 !important; } - .px-md-0 { - padding-right: 0 !important; - padding-left: 0 !important; } - .py-md-0 { - padding-top: 0 !important; - padding-bottom: 0 !important; } - .p-md-1 { - padding: 0.25rem 0.25rem !important; } - .pt-md-1 { - padding-top: 0.25rem !important; } - .pr-md-1 { - padding-right: 0.25rem !important; } - .pb-md-1 { - padding-bottom: 0.25rem !important; } - .pl-md-1 { - padding-left: 0.25rem !important; } - .px-md-1 { - padding-right: 0.25rem !important; - padding-left: 0.25rem !important; } - .py-md-1 { - padding-top: 0.25rem !important; - padding-bottom: 0.25rem !important; } - .p-md-2 { - padding: 0.5rem 0.5rem !important; } - .pt-md-2 { - padding-top: 0.5rem !important; } - .pr-md-2 { - padding-right: 0.5rem !important; } - .pb-md-2 { - padding-bottom: 0.5rem !important; } - .pl-md-2 { - padding-left: 0.5rem !important; } - .px-md-2 { - padding-right: 0.5rem !important; - padding-left: 0.5rem !important; } - .py-md-2 { - padding-top: 0.5rem !important; - padding-bottom: 0.5rem !important; } - .p-md-3 { - padding: 1rem 1rem !important; } - .pt-md-3 { - padding-top: 1rem !important; } - .pr-md-3 { - padding-right: 1rem !important; } - .pb-md-3 { - padding-bottom: 1rem !important; } - .pl-md-3 { - padding-left: 1rem !important; } - .px-md-3 { - padding-right: 1rem !important; - padding-left: 1rem !important; } - .py-md-3 { - padding-top: 1rem !important; - padding-bottom: 1rem !important; } - .p-md-4 { - padding: 1.5rem 1.5rem !important; } - .pt-md-4 { - padding-top: 1.5rem !important; } - .pr-md-4 { - padding-right: 1.5rem !important; } - .pb-md-4 { - padding-bottom: 1.5rem !important; } - .pl-md-4 { - padding-left: 1.5rem !important; } - .px-md-4 { - padding-right: 1.5rem !important; - padding-left: 1.5rem !important; } - .py-md-4 { - padding-top: 1.5rem !important; - padding-bottom: 1.5rem !important; } - .p-md-5 { - padding: 3rem 3rem !important; } - .pt-md-5 { - padding-top: 3rem !important; } - .pr-md-5 { - padding-right: 3rem !important; } - .pb-md-5 { - padding-bottom: 3rem !important; } - .pl-md-5 { - padding-left: 3rem !important; } - .px-md-5 { - padding-right: 3rem !important; - padding-left: 3rem !important; } - .py-md-5 { - padding-top: 3rem !important; - padding-bottom: 3rem !important; } - .m-md-auto { - margin: auto !important; } - .mt-md-auto { - margin-top: auto !important; } - .mr-md-auto { - margin-right: auto !important; } - .mb-md-auto { - margin-bottom: auto !important; } - .ml-md-auto { - margin-left: auto !important; } - .mx-md-auto { - margin-right: auto !important; - margin-left: auto !important; } - .my-md-auto { - margin-top: auto !important; - margin-bottom: auto !important; } } - -@media (min-width: 992px) { - .m-lg-0 { - margin: 0 0 !important; } - .mt-lg-0 { - margin-top: 0 !important; } - .mr-lg-0 { - margin-right: 0 !important; } - .mb-lg-0 { - margin-bottom: 0 !important; } - .ml-lg-0 { - margin-left: 0 !important; } - .mx-lg-0 { - margin-right: 0 !important; - margin-left: 0 !important; } - .my-lg-0 { - margin-top: 0 !important; - margin-bottom: 0 !important; } - .m-lg-1 { - margin: 0.25rem 0.25rem !important; } - .mt-lg-1 { - margin-top: 0.25rem !important; } - .mr-lg-1 { - margin-right: 0.25rem !important; } - .mb-lg-1 { - margin-bottom: 0.25rem !important; } - .ml-lg-1 { - margin-left: 0.25rem !important; } - .mx-lg-1 { - margin-right: 0.25rem !important; - margin-left: 0.25rem !important; } - .my-lg-1 { - margin-top: 0.25rem !important; - margin-bottom: 0.25rem !important; } - .m-lg-2 { - margin: 0.5rem 0.5rem !important; } - .mt-lg-2 { - margin-top: 0.5rem !important; } - .mr-lg-2 { - margin-right: 0.5rem !important; } - .mb-lg-2 { - margin-bottom: 0.5rem !important; } - .ml-lg-2 { - margin-left: 0.5rem !important; } - .mx-lg-2 { - margin-right: 0.5rem !important; - margin-left: 0.5rem !important; } - .my-lg-2 { - margin-top: 0.5rem !important; - margin-bottom: 0.5rem !important; } - .m-lg-3 { - margin: 1rem 1rem !important; } - .mt-lg-3 { - margin-top: 1rem !important; } - .mr-lg-3 { - margin-right: 1rem !important; } - .mb-lg-3 { - margin-bottom: 1rem !important; } - .ml-lg-3 { - margin-left: 1rem !important; } - .mx-lg-3 { - margin-right: 1rem !important; - margin-left: 1rem !important; } - .my-lg-3 { - margin-top: 1rem !important; - margin-bottom: 1rem !important; } - .m-lg-4 { - margin: 1.5rem 1.5rem !important; } - .mt-lg-4 { - margin-top: 1.5rem !important; } - .mr-lg-4 { - margin-right: 1.5rem !important; } - .mb-lg-4 { - margin-bottom: 1.5rem !important; } - .ml-lg-4 { - margin-left: 1.5rem !important; } - .mx-lg-4 { - margin-right: 1.5rem !important; - margin-left: 1.5rem !important; } - .my-lg-4 { - margin-top: 1.5rem !important; - margin-bottom: 1.5rem !important; } - .m-lg-5 { - margin: 3rem 3rem !important; } - .mt-lg-5 { - margin-top: 3rem !important; } - .mr-lg-5 { - margin-right: 3rem !important; } - .mb-lg-5 { - margin-bottom: 3rem !important; } - .ml-lg-5 { - margin-left: 3rem !important; } - .mx-lg-5 { - margin-right: 3rem !important; - margin-left: 3rem !important; } - .my-lg-5 { - margin-top: 3rem !important; - margin-bottom: 3rem !important; } - .p-lg-0 { - padding: 0 0 !important; } - .pt-lg-0 { - padding-top: 0 !important; } - .pr-lg-0 { - padding-right: 0 !important; } - .pb-lg-0 { - padding-bottom: 0 !important; } - .pl-lg-0 { - padding-left: 0 !important; } - .px-lg-0 { - padding-right: 0 !important; - padding-left: 0 !important; } - .py-lg-0 { - padding-top: 0 !important; - padding-bottom: 0 !important; } - .p-lg-1 { - padding: 0.25rem 0.25rem !important; } - .pt-lg-1 { - padding-top: 0.25rem !important; } - .pr-lg-1 { - padding-right: 0.25rem !important; } - .pb-lg-1 { - padding-bottom: 0.25rem !important; } - .pl-lg-1 { - padding-left: 0.25rem !important; } - .px-lg-1 { - padding-right: 0.25rem !important; - padding-left: 0.25rem !important; } - .py-lg-1 { - padding-top: 0.25rem !important; - padding-bottom: 0.25rem !important; } - .p-lg-2 { - padding: 0.5rem 0.5rem !important; } - .pt-lg-2 { - padding-top: 0.5rem !important; } - .pr-lg-2 { - padding-right: 0.5rem !important; } - .pb-lg-2 { - padding-bottom: 0.5rem !important; } - .pl-lg-2 { - padding-left: 0.5rem !important; } - .px-lg-2 { - padding-right: 0.5rem !important; - padding-left: 0.5rem !important; } - .py-lg-2 { - padding-top: 0.5rem !important; - padding-bottom: 0.5rem !important; } - .p-lg-3 { - padding: 1rem 1rem !important; } - .pt-lg-3 { - padding-top: 1rem !important; } - .pr-lg-3 { - padding-right: 1rem !important; } - .pb-lg-3 { - padding-bottom: 1rem !important; } - .pl-lg-3 { - padding-left: 1rem !important; } - .px-lg-3 { - padding-right: 1rem !important; - padding-left: 1rem !important; } - .py-lg-3 { - padding-top: 1rem !important; - padding-bottom: 1rem !important; } - .p-lg-4 { - padding: 1.5rem 1.5rem !important; } - .pt-lg-4 { - padding-top: 1.5rem !important; } - .pr-lg-4 { - padding-right: 1.5rem !important; } - .pb-lg-4 { - padding-bottom: 1.5rem !important; } - .pl-lg-4 { - padding-left: 1.5rem !important; } - .px-lg-4 { - padding-right: 1.5rem !important; - padding-left: 1.5rem !important; } - .py-lg-4 { - padding-top: 1.5rem !important; - padding-bottom: 1.5rem !important; } - .p-lg-5 { - padding: 3rem 3rem !important; } - .pt-lg-5 { - padding-top: 3rem !important; } - .pr-lg-5 { - padding-right: 3rem !important; } - .pb-lg-5 { - padding-bottom: 3rem !important; } - .pl-lg-5 { - padding-left: 3rem !important; } - .px-lg-5 { - padding-right: 3rem !important; - padding-left: 3rem !important; } - .py-lg-5 { - padding-top: 3rem !important; - padding-bottom: 3rem !important; } - .m-lg-auto { - margin: auto !important; } - .mt-lg-auto { - margin-top: auto !important; } - .mr-lg-auto { - margin-right: auto !important; } - .mb-lg-auto { - margin-bottom: auto !important; } - .ml-lg-auto { - margin-left: auto !important; } - .mx-lg-auto { - margin-right: auto !important; - margin-left: auto !important; } - .my-lg-auto { - margin-top: auto !important; - margin-bottom: auto !important; } } - -@media (min-width: 1200px) { - .m-xl-0 { - margin: 0 0 !important; } - .mt-xl-0 { - margin-top: 0 !important; } - .mr-xl-0 { - margin-right: 0 !important; } - .mb-xl-0 { - margin-bottom: 0 !important; } - .ml-xl-0 { - margin-left: 0 !important; } - .mx-xl-0 { - margin-right: 0 !important; - margin-left: 0 !important; } - .my-xl-0 { - margin-top: 0 !important; - margin-bottom: 0 !important; } - .m-xl-1 { - margin: 0.25rem 0.25rem !important; } - .mt-xl-1 { - margin-top: 0.25rem !important; } - .mr-xl-1 { - margin-right: 0.25rem !important; } - .mb-xl-1 { - margin-bottom: 0.25rem !important; } - .ml-xl-1 { - margin-left: 0.25rem !important; } - .mx-xl-1 { - margin-right: 0.25rem !important; - margin-left: 0.25rem !important; } - .my-xl-1 { - margin-top: 0.25rem !important; - margin-bottom: 0.25rem !important; } - .m-xl-2 { - margin: 0.5rem 0.5rem !important; } - .mt-xl-2 { - margin-top: 0.5rem !important; } - .mr-xl-2 { - margin-right: 0.5rem !important; } - .mb-xl-2 { - margin-bottom: 0.5rem !important; } - .ml-xl-2 { - margin-left: 0.5rem !important; } - .mx-xl-2 { - margin-right: 0.5rem !important; - margin-left: 0.5rem !important; } - .my-xl-2 { - margin-top: 0.5rem !important; - margin-bottom: 0.5rem !important; } - .m-xl-3 { - margin: 1rem 1rem !important; } - .mt-xl-3 { - margin-top: 1rem !important; } - .mr-xl-3 { - margin-right: 1rem !important; } - .mb-xl-3 { - margin-bottom: 1rem !important; } - .ml-xl-3 { - margin-left: 1rem !important; } - .mx-xl-3 { - margin-right: 1rem !important; - margin-left: 1rem !important; } - .my-xl-3 { - margin-top: 1rem !important; - margin-bottom: 1rem !important; } - .m-xl-4 { - margin: 1.5rem 1.5rem !important; } - .mt-xl-4 { - margin-top: 1.5rem !important; } - .mr-xl-4 { - margin-right: 1.5rem !important; } - .mb-xl-4 { - margin-bottom: 1.5rem !important; } - .ml-xl-4 { - margin-left: 1.5rem !important; } - .mx-xl-4 { - margin-right: 1.5rem !important; - margin-left: 1.5rem !important; } - .my-xl-4 { - margin-top: 1.5rem !important; - margin-bottom: 1.5rem !important; } - .m-xl-5 { - margin: 3rem 3rem !important; } - .mt-xl-5 { - margin-top: 3rem !important; } - .mr-xl-5 { - margin-right: 3rem !important; } - .mb-xl-5 { - margin-bottom: 3rem !important; } - .ml-xl-5 { - margin-left: 3rem !important; } - .mx-xl-5 { - margin-right: 3rem !important; - margin-left: 3rem !important; } - .my-xl-5 { - margin-top: 3rem !important; - margin-bottom: 3rem !important; } - .p-xl-0 { - padding: 0 0 !important; } - .pt-xl-0 { - padding-top: 0 !important; } - .pr-xl-0 { - padding-right: 0 !important; } - .pb-xl-0 { - padding-bottom: 0 !important; } - .pl-xl-0 { - padding-left: 0 !important; } - .px-xl-0 { - padding-right: 0 !important; - padding-left: 0 !important; } - .py-xl-0 { - padding-top: 0 !important; - padding-bottom: 0 !important; } - .p-xl-1 { - padding: 0.25rem 0.25rem !important; } - .pt-xl-1 { - padding-top: 0.25rem !important; } - .pr-xl-1 { - padding-right: 0.25rem !important; } - .pb-xl-1 { - padding-bottom: 0.25rem !important; } - .pl-xl-1 { - padding-left: 0.25rem !important; } - .px-xl-1 { - padding-right: 0.25rem !important; - padding-left: 0.25rem !important; } - .py-xl-1 { - padding-top: 0.25rem !important; - padding-bottom: 0.25rem !important; } - .p-xl-2 { - padding: 0.5rem 0.5rem !important; } - .pt-xl-2 { - padding-top: 0.5rem !important; } - .pr-xl-2 { - padding-right: 0.5rem !important; } - .pb-xl-2 { - padding-bottom: 0.5rem !important; } - .pl-xl-2 { - padding-left: 0.5rem !important; } - .px-xl-2 { - padding-right: 0.5rem !important; - padding-left: 0.5rem !important; } - .py-xl-2 { - padding-top: 0.5rem !important; - padding-bottom: 0.5rem !important; } - .p-xl-3 { - padding: 1rem 1rem !important; } - .pt-xl-3 { - padding-top: 1rem !important; } - .pr-xl-3 { - padding-right: 1rem !important; } - .pb-xl-3 { - padding-bottom: 1rem !important; } - .pl-xl-3 { - padding-left: 1rem !important; } - .px-xl-3 { - padding-right: 1rem !important; - padding-left: 1rem !important; } - .py-xl-3 { - padding-top: 1rem !important; - padding-bottom: 1rem !important; } - .p-xl-4 { - padding: 1.5rem 1.5rem !important; } - .pt-xl-4 { - padding-top: 1.5rem !important; } - .pr-xl-4 { - padding-right: 1.5rem !important; } - .pb-xl-4 { - padding-bottom: 1.5rem !important; } - .pl-xl-4 { - padding-left: 1.5rem !important; } - .px-xl-4 { - padding-right: 1.5rem !important; - padding-left: 1.5rem !important; } - .py-xl-4 { - padding-top: 1.5rem !important; - padding-bottom: 1.5rem !important; } - .p-xl-5 { - padding: 3rem 3rem !important; } - .pt-xl-5 { - padding-top: 3rem !important; } - .pr-xl-5 { - padding-right: 3rem !important; } - .pb-xl-5 { - padding-bottom: 3rem !important; } - .pl-xl-5 { - padding-left: 3rem !important; } - .px-xl-5 { - padding-right: 3rem !important; - padding-left: 3rem !important; } - .py-xl-5 { - padding-top: 3rem !important; - padding-bottom: 3rem !important; } - .m-xl-auto { - margin: auto !important; } - .mt-xl-auto { - margin-top: auto !important; } - .mr-xl-auto { - margin-right: auto !important; } - .mb-xl-auto { - margin-bottom: auto !important; } - .ml-xl-auto { - margin-left: auto !important; } - .mx-xl-auto { - margin-right: auto !important; - margin-left: auto !important; } - .my-xl-auto { - margin-top: auto !important; - margin-bottom: auto !important; } } - -.text-justify { - text-align: justify !important; } - -.text-nowrap { - white-space: nowrap !important; } - -.text-truncate { - overflow: hidden; - text-overflow: ellipsis; - white-space: nowrap; } - -.text-left { - text-align: left !important; } - -.text-right { - text-align: right !important; } - -.text-center { - text-align: center !important; } - -@media (min-width: 576px) { - .text-sm-left { - text-align: left !important; } - .text-sm-right { - text-align: right !important; } - .text-sm-center { - text-align: center !important; } } - -@media (min-width: 768px) { - .text-md-left { - text-align: left !important; } - .text-md-right { - text-align: right !important; } - .text-md-center { - text-align: center !important; } } - -@media (min-width: 992px) { - .text-lg-left { - text-align: left !important; } - .text-lg-right { - text-align: right !important; } - .text-lg-center { - text-align: center !important; } } - -@media (min-width: 1200px) { - .text-xl-left { - text-align: left !important; } - .text-xl-right { - text-align: right !important; } - .text-xl-center { - text-align: center !important; } } - -.text-lowercase { - text-transform: lowercase !important; } - -.text-uppercase { - text-transform: uppercase !important; } - -.text-capitalize { - text-transform: capitalize !important; } - -.font-weight-normal { - font-weight: normal; } - -.font-weight-bold { - font-weight: bold; } - -.font-italic { - font-style: italic; } - -.text-white { - color: #fff !important; } - -.text-muted { - color: #d5d5d5 !important; } - -a.text-muted:focus, a.text-muted:hover { - color: #bcbcbc !important; } - -.text-primary { - color: #0275d8 !important; } - -a.text-primary:focus, a.text-primary:hover { - color: #025aa5 !important; } - -.text-success { - color: #5cb85c !important; } - -a.text-success:focus, a.text-success:hover { - color: #449d44 !important; } - -.text-info { - color: #5bc0de !important; } - -a.text-info:focus, a.text-info:hover { - color: #31b0d5 !important; } - -.text-warning { - color: #f0ad4e !important; } - -a.text-warning:focus, a.text-warning:hover { - color: #ec971f !important; } - -.text-danger { - color: #d9534f !important; } - -a.text-danger:focus, a.text-danger:hover { - color: #c9302c !important; } - -.text-gray-dark { - color: #373a3c !important; } - -a.text-gray-dark:focus, a.text-gray-dark:hover { - color: #1f2021 !important; } - -.text-hide { - font: 0/0 a; - color: transparent; - text-shadow: none; - background-color: transparent; - border: 0; } - -.invisible { - visibility: hidden !important; } - -.hidden-xs-up { - display: none !important; } - -@media (max-width: 575px) { - .hidden-xs-down { - display: none !important; } } - -@media (min-width: 576px) { - .hidden-sm-up { - display: none !important; } } - -@media (max-width: 767px) { - .hidden-sm-down { - display: none !important; } } - -@media (min-width: 768px) { - .hidden-md-up { - display: none !important; } } - -@media (max-width: 991px) { - .hidden-md-down { - display: none !important; } } - -@media (min-width: 992px) { - .hidden-lg-up { - display: none !important; } } - -@media (max-width: 1199px) { - .hidden-lg-down { - display: none !important; } } - -@media (min-width: 1200px) { - .hidden-xl-up { - display: none !important; } } - -.hidden-xl-down { - display: none !important; } - -.visible-print-block { - display: none !important; } - @media print { - .visible-print-block { - display: block !important; } } - -.visible-print-inline { - display: none !important; } - @media print { - .visible-print-inline { - display: inline !important; } } - -.visible-print-inline-block { - display: none !important; } - @media print { - .visible-print-inline-block { - display: inline-block !important; } } - -@media print { - .hidden-print { - display: none !important; } } - -.container-narrow { - position: relative; - margin-left: auto; - margin-right: auto; - padding-right: 15px; - padding-left: 15px; } - @media (min-width: 576px) { - .container-narrow { - padding-right: 15px; - padding-left: 15px; } } - @media (min-width: 768px) { - .container-narrow { - padding-right: 15px; - padding-left: 15px; } } - @media (min-width: 992px) { - .container-narrow { - padding-right: 15px; - padding-left: 15px; } } - @media (min-width: 1200px) { - .container-narrow { - padding-right: 15px; - padding-left: 15px; } } - @media (min-width: 576px) { - .container-narrow { - max-width: 34rem; } } - @media (min-width: 768px) { - .container-narrow { - max-width: 45rem; } } - @media (min-width: 992px) { - .container-narrow { - max-width: 45rem; } } - @media (min-width: 1200px) { - .container-narrow { - max-width: 45rem; } } - -.nav-underline .nav-item.active, .nav-underline .nav-item.active:hover { - box-shadow: 0px -3px 0 0 #0275d8 inset; } - .nav-underline .nav-item.active .nav-link, .nav-underline .nav-item.active:hover .nav-link { - color: #0275d8; } - -.nav-underline li:hover { - box-shadow: 0px -3px 0 0 #ddd inset; } - -.nav-underline li { - padding-top: 0.2rem; - padding-bottom: 0.2rem; } - -.navbar-underline { - background-color: #d5d5d5; - border-top: 1px solid #c8c8c8; } - -pre { - background-color: #fdf6e3; - padding: 1rem; } - -.table-expand-col { - min-width: 100%; } - -body { - background-color: #373a3c; } - -.card-success { - background-color: #dff0d8; - border-color: #d0e9c6; - color: #3c763d; } - .card-success hr { - border-top-color: #c1e2b3; } - .card-success .alert-link { - color: #2b542c; } - .card-success .card-header { - background-color: #d0e9c6; - border-bottom: 1px solid #c1e2b3; } - -.card-info { - background-color: #d9edf7; - border-color: #bcdff1; - color: #31708f; } - .card-info hr { - border-top-color: #a6d5ec; } - .card-info .alert-link { - color: #245269; } - .card-info .card-header { - background-color: #c4e3f3; - border-bottom: 1px solid #afd9ee; } - -.card-primary { - background-color: #d9edf7; - border-color: #bcdff1; - color: #31708f; } - .card-primary hr { - border-top-color: #a6d5ec; } - .card-primary .alert-link { - color: #245269; } - .card-primary .card-header { - background-color: #c4e3f3; - border-bottom: 1px solid #afd9ee; } - -.card-warning { - background-color: #fcf8e3; - border-color: #faf2cc; - color: #8a6d3b; } - .card-warning hr { - border-top-color: #f7ecb5; } - .card-warning .alert-link { - color: #66512c; } - .card-warning .card-header { - background-color: #faf2cc; - border-bottom: 1px solid #f7ecb5; } - -.card-danger { - background-color: #f2dede; - border-color: #ebcccc; - color: #a94442; } - .card-danger hr { - border-top-color: #e4b9b9; } - .card-danger .alert-link { - color: #843534; } - .card-danger .card-header { - background-color: #ebcccc; - border-bottom: 1px solid #e4b9b9; } - -.masthead { - background-image: linear-gradient(to bottom, #eee 0%, #ddd 100%); - background-repeat: repeat-x; - padding-top: 10px; - padding-bottom: 10px; } - -.subheader { - background: #f3f3f3; - border-bottom: 1px solid #d5d5d5; } - .subheader .nav-tabs { - margin-bottom: -1px; } - -.footer { - background-color: #373a3c; } - -.bodycontent { - background: #fff; } - -/*Overrides for content generated by python docutils*/ -.document-docutils > .section { - padding-bottom: 1rem; } - -.document-docutils pre { - /* Comment */ - /* Error */ - /* Generic */ - /* Keyword */ - /* Literal */ - /* Name */ - /* Operator */ - /* Other */ - /* Punctuation */ - /* Comment.Multiline */ - /* Comment.Preproc */ - /* Comment.Single */ - /* Comment.Special */ - /* Generic.Deleted */ - /* Generic.Emph */ - /* Generic.Error */ - /* Generic.Heading */ - /* Generic.Inserted */ - /* Generic.Output */ - /* Generic.Prompt */ - /* Generic.Strong */ - /* Generic.Subheading */ - /* Generic.Traceback */ - /* Keyword.Constant */ - /* Keyword.Declaration */ - /* Keyword.Namespace */ - /* Keyword.Pseudo */ - /* Keyword.Reserved */ - /* Keyword.Type */ - /* Literal.Date */ - /* Literal.Number */ - /* Literal.String */ - /* Name.Attribute */ - /* Name.Builtin */ - /* Name.Class */ - /* Name.Constant */ - /* Name.Decorator */ - /* Name.Entity */ - /* Name.Exception */ - /* Name.Function */ - /* Name.Label */ - /* Name.Namespace */ - /* Name.Other */ - /* Name.Property */ - /* Name.Tag */ - /* Name.Variable */ - /* Operator.Word */ - /* Text.Whitespace */ - /* Literal.Number.Float */ - /* Literal.Number.Hex */ - /* Literal.Number.Integer */ - /* Literal.Number.Oct */ - /* Literal.String.Backtick */ - /* Literal.String.Char */ - /* Literal.String.Doc */ - /* Literal.String.Double */ - /* Literal.String.Escape */ - /* Literal.String.Heredoc */ - /* Literal.String.Interpol */ - /* Literal.String.Other */ - /* Literal.String.Regex */ - /* Literal.String.Single */ - /* Literal.String.Symbol */ - /* Name.Builtin.Pseudo */ - /* Name.Variable.Class */ - /* Name.Variable.Global */ - /* Name.Variable.Instance */ - /* Literal.Number.Integer.Long */ } - .document-docutils pre .comment { - color: #586e75; } - .document-docutils pre .error { - color: #93a1a1; } - .document-docutils pre .generic { - color: #93a1a1; } - .document-docutils pre .keyword { - color: #859900; } - .document-docutils pre .literal { - color: #93a1a1; } - .document-docutils pre .name { - color: #93a1a1; } - .document-docutils pre .operator { - color: #859900; } - .document-docutils pre .other { - color: #cb4b16; } - .document-docutils pre .punctuation { - color: #93a1a1; } - .document-docutils pre .comment.multiline { - color: #586e75; } - .document-docutils pre .comment.preproc { - color: #859900; } - .document-docutils pre .comment.single { - color: #586e75; } - .document-docutils pre .comment.special { - color: #859900; } - .document-docutils pre .generic.deleted { - color: #2aa198; } - .document-docutils pre .generic.emph { - color: #93a1a1; - font-style: italic; } - .document-docutils pre .generic.error { - color: #dc322f; } - .document-docutils pre .generic.heading { - color: #cb4b16; } - .document-docutils pre .generic.inserted { - color: #859900; } - .document-docutils pre .generic.output { - color: #93a1a1; } - .document-docutils pre .generic.prompt { - color: #93a1a1; } - .document-docutils pre .generic.strong { - color: #93a1a1; - font-weight: bold; } - .document-docutils pre .generic.subheading { - color: #cb4b16; } - .document-docutils pre .generic.traceback { - color: #93a1a1; } - .document-docutils pre .keyword.constant { - color: #cb4b16; } - .document-docutils pre .keyword.declaration { - color: #268bd2; } - .document-docutils pre .keyword.namespace { - color: #859900; } - .document-docutils pre .keyword.pseudo { - color: #859900; } - .document-docutils pre .keyword.reserved { - color: #268bd2; } - .document-docutils pre .keyword.type { - color: #dc322f; } - .document-docutils pre .literal.date { - color: #93a1a1; } - .document-docutils pre .literal.number { - color: #2aa198; } - .document-docutils pre .literal.string { - color: #2aa198; } - .document-docutils pre .name.attribute { - color: #93a1a1; } - .document-docutils pre .name.builtin { - color: #B58900; } - .document-docutils pre .name.class { - color: #268bd2; } - .document-docutils pre .name.constant { - color: #cb4b16; } - .document-docutils pre .name.decorator { - color: #268bd2; } - .document-docutils pre .name.entity { - color: #cb4b16; } - .document-docutils pre .name.exception { - color: #cb4b16; } - .document-docutils pre .name.function { - color: #268bd2; } - .document-docutils pre .name.label { - color: #93a1a1; } - .document-docutils pre .name.namespace { - color: #93a1a1; } - .document-docutils pre .name.other { - color: #93a1a1; } - .document-docutils pre .name.property { - color: #93a1a1; } - .document-docutils pre .name.tag { - color: #268bd2; } - .document-docutils pre .name.variable { - color: #268bd2; } - .document-docutils pre .operator.word { - color: #859900; } - .document-docutils pre .text.whitespace { - color: #93a1a1; } - .document-docutils pre .literal.number.float { - color: #2aa198; } - .document-docutils pre .literal.number.hex { - color: #2aa198; } - .document-docutils pre .literal.number.integer { - color: #2aa198; } - .document-docutils pre .literal.number.oct { - color: #2aa198; } - .document-docutils pre .literal.string.backtick { - color: #586e75; } - .document-docutils pre .literal.string.char { - color: #2aa198; } - .document-docutils pre .literal.string.doc { - color: #93a1a1; } - .document-docutils pre .literal.string.double { - color: #2aa198; } - .document-docutils pre .literal.string.escape { - color: #cb4b16; } - .document-docutils pre .literal.string.heredoc { - color: #93a1a1; } - .document-docutils pre .literal.string.interpol { - color: #2aa198; } - .document-docutils pre .literal.string.other { - color: #2aa198; } - .document-docutils pre .literal.string.regex { - color: #dc322f; } - .document-docutils pre .literal.string.single { - color: #2aa198; } - .document-docutils pre .literal.string.symbol { - color: #2aa198; } - .document-docutils pre .name.builtin.pseudo { - color: #268bd2; } - .document-docutils pre .name.variable.class { - color: #268bd2; } - .document-docutils pre .name.variable.global { - color: #268bd2; } - .document-docutils pre .name.variable.instance { - color: #268bd2; } - .document-docutils pre .literal.number.integer.long { - color: #2aa198; } diff --git a/theme/static/fedora-bootstrap.js b/theme/static/fedora-bootstrap.js deleted file mode 100644 index 90013fa..0000000 --- a/theme/static/fedora-bootstrap.js +++ /dev/null @@ -1,5422 +0,0 @@ -/******/ (function(modules) { // webpackBootstrap -/******/ // The module cache -/******/ var installedModules = {}; - -/******/ // The require function -/******/ function __webpack_require__(moduleId) { - -/******/ // Check if module is in cache -/******/ if(installedModules[moduleId]) -/******/ return installedModules[moduleId].exports; - -/******/ // Create a new module (and put it into the cache) -/******/ var module = installedModules[moduleId] = { -/******/ exports: {}, -/******/ id: moduleId, -/******/ loaded: false -/******/ }; - -/******/ // Execute the module function -/******/ modules[moduleId].call(module.exports, module, module.exports, __webpack_require__); - -/******/ // Flag the module as loaded -/******/ module.loaded = true; - -/******/ // Return the exports of the module -/******/ return module.exports; -/******/ } - - -/******/ // expose the modules object (__webpack_modules__) -/******/ __webpack_require__.m = modules; - -/******/ // expose the module cache -/******/ __webpack_require__.c = installedModules; - -/******/ // __webpack_public_path__ -/******/ __webpack_require__.p = ""; - -/******/ // Load entry module and return exports -/******/ return __webpack_require__(0); -/******/ }) -/************************************************************************/ -/******/ ([ -/* 0 */ -/***/ function(module, exports, __webpack_require__) { - - /*fedora-bootstrap v1.0.3 -- https://pagure.io/fedora-bootstrap */ - 'use strict'; - - __webpack_require__(1); - - __webpack_require__(2); - - __webpack_require__(3); - -/***/ }, -/* 1 */ -/***/ function(module, exports, __webpack_require__) { - - var __WEBPACK_AMD_DEFINE_FACTORY__, __WEBPACK_AMD_DEFINE_RESULT__;/*! tether 1.4.0 */ - - (function(root, factory) { - if (true) { - !(__WEBPACK_AMD_DEFINE_FACTORY__ = (factory), __WEBPACK_AMD_DEFINE_RESULT__ = (typeof __WEBPACK_AMD_DEFINE_FACTORY__ === 'function' ? (__WEBPACK_AMD_DEFINE_FACTORY__.call(exports, __webpack_require__, exports, module)) : __WEBPACK_AMD_DEFINE_FACTORY__), __WEBPACK_AMD_DEFINE_RESULT__ !== undefined && (module.exports = __WEBPACK_AMD_DEFINE_RESULT__)); - } else if (typeof exports === 'object') { - module.exports = factory(require, exports, module); - } else { - root.Tether = factory(); - } - }(this, function(require, exports, module) { - - 'use strict'; - - var _createClass = (function () { function defineProperties(target, props) { for (var i = 0; i < props.length; i++) { var descriptor = props[i]; descriptor.enumerable = descriptor.enumerable || false; descriptor.configurable = true; if ('value' in descriptor) descriptor.writable = true; Object.defineProperty(target, descriptor.key, descriptor); } } return function (Constructor, protoProps, staticProps) { if (protoProps) defineProperties(Constructor.prototype, protoProps); if (staticProps) defineProperties(Constructor, staticProps); return Constructor; }; })(); - - function _classCallCheck(instance, Constructor) { if (!(instance instanceof Constructor)) { throw new TypeError('Cannot call a class as a function'); } } - - var TetherBase = undefined; - if (typeof TetherBase === 'undefined') { - TetherBase = { modules: [] }; - } - - var zeroElement = null; - - // Same as native getBoundingClientRect, except it takes into account parent offsets - // if the element lies within a nested document ( or