From 9f54ac3b07ccff5ac32448c94f8e24250288bd41 Mon Sep 17 00:00:00 2001 From: Otto Urpelainen Date: Aug 22 2021 11:01:27 +0000 Subject: Prefer [#some-ref] over [[some-ref]] --- 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 index 4b7ca86..4b33870 100644 --- 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 @@ -3,7 +3,7 @@ = How to Get Sponsored into the Packager Group :toc: -[[sponsorship_model]] +[#sponsorship_model] == Sponsorship model Getting sponsored allows anyone interested to become a Fedora maintainer @@ -25,7 +25,7 @@ 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] == Convincing someone to sponsor you There are several ways to get sponsored into the `packager` group @@ -33,7 +33,7 @@ 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] === Submitting quality new packages Until you are sponsored into the `packager` group @@ -99,7 +99,7 @@ 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] === Show Your Expertise by Commenting on other Review Requests To show you familiarity with Fedora's guidelines, @@ -128,7 +128,7 @@ 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] === Show Your Expertise by Opening Pull Requests The https://pagure.io[Pagure] based https://src.fedoraproject.org[src.fedoraproject.org] system @@ -142,7 +142,7 @@ 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] === Become a co-maintainer Another way to enter the `packager` group @@ -178,7 +178,7 @@ 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] === Other paths Sponsors can decide to sponsor you for any other reason as well. @@ -197,7 +197,7 @@ 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] == How to sponsor If you are looking for information on sponsoring someone, diff --git a/modules/ROOT/pages/How_to_Sponsor_a_New_Contributor.adoc b/modules/ROOT/pages/How_to_Sponsor_a_New_Contributor.adoc index 57f43c1..aacb792 100644 --- a/modules/ROOT/pages/How_to_Sponsor_a_New_Contributor.adoc +++ b/modules/ROOT/pages/How_to_Sponsor_a_New_Contributor.adoc @@ -3,7 +3,7 @@ = How to Sponsor a New Contributor :toc: -[[becoming_a_fedora_package_collection_sponsor]] +[#becoming_a_fedora_package_collection_sponsor] == Becoming a Fedora Package Collection Sponsor The Fedora Package Collection has been setup so @@ -53,7 +53,7 @@ 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 Fedora Package Collection Sponsoring someone @@ -112,7 +112,7 @@ 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] == Sponsoring Someone for provenpackagers https://docs.fedoraproject.org/en-US/fesco/Provenpackager_policy/[Provenpackagers] have access to most packages. @@ -139,7 +139,7 @@ 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] == Welcome Note Once you have sponsored someone, diff --git a/modules/ROOT/pages/Joining_the_Package_Maintainers.adoc b/modules/ROOT/pages/Joining_the_Package_Maintainers.adoc index 4e5f27c..2e443cf 100644 --- a/modules/ROOT/pages/Joining_the_Package_Maintainers.adoc +++ b/modules/ROOT/pages/Joining_the_Package_Maintainers.adoc @@ -10,7 +10,7 @@ or update to an existing package. == Preparation -[[read_the_guidelines]] +[#read_the_guidelines] === Read the Guidelines If you don't know how to create an RPM package, @@ -23,7 +23,7 @@ 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] === Create a Bugzilla Account Make sure you have an account in https://bugzilla.redhat.com/[Red Hat Bugzilla]. @@ -31,7 +31,7 @@ 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 a Fedora Account Create an account in the https://fedoraproject.org/wiki/Account_System?rd=Infrastructure/AccountSystem[Fedora Account System]. @@ -55,7 +55,7 @@ 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] === 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. @@ -79,7 +79,7 @@ is https://lists.fedoraproject.org/admin/lists/packaging@lists.fedoraproject.org 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] === Introduce yourself Next, you should introduce yourself to the community on the mailing list. @@ -113,7 +113,7 @@ 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_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 @@ -130,7 +130,7 @@ or waiting for review. * Be aware of https://fedoraproject.org/wiki/Forbidden_items[forbidden items]. -[[understand_your_responsibilities]] +[#understand_your_responsibilities] === Understand your responsibilities Software components included in Fedora need to be maintained actively, @@ -143,7 +143,7 @@ and seek the help of the Fedora community via the development mailing list whenever needed. -[[read_other_submissions]] +[#read_other_submissions] === Read Other Submissions Read some other package submissions @@ -155,7 +155,7 @@ All comments on Fedora package reviews are sent to this (read-only from your point of view) list. -[[configure_your_git]] +[#configure_your_git] === Configure Your Git The first thing to do when you set up Fedora packaging @@ -167,7 +167,7 @@ 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] === Install the developer client tools To build Packages for the Fedora Collection or EPEL @@ -248,12 +248,12 @@ 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] == Adding a new package Follow xref:New_Package_Process_for_New_Contributors.adoc[New Package Process for New Contributors]. -[[getting_help]] +[#getting_help] == Getting Help We know that this process can be as clear as mud sometimes, @@ -263,7 +263,7 @@ or have any questions please ask on the mailing list or in on freenode.net. -[[one_off_contributions]] +[#one_off_contributions] == One-off contributions Changes to https://src.fedoraproject.org/browse/projects/[existing packages] diff --git a/modules/ROOT/pages/New_Package_Process_for_New_Contributors.adoc b/modules/ROOT/pages/New_Package_Process_for_New_Contributors.adoc index 800b07b..f8d9aef 100644 --- a/modules/ROOT/pages/New_Package_Process_for_New_Contributors.adoc +++ b/modules/ROOT/pages/New_Package_Process_for_New_Contributors.adoc @@ -7,7 +7,7 @@ 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] == Make a Package * If you don't know how to create an RPM package, @@ -22,7 +22,7 @@ see the https://docs.fedoraproject.org/en-US/quick-docs/creating-rpm-packages/in This is surprisingly important because a significant number of submissions don't. -[[upload_your_package]] +[#upload_your_package] == Upload Your Package Upload your SRPM and SPEC files onto the Internet somewhere @@ -40,7 +40,7 @@ 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] == Create Your Review Request Fill out https://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Fedora&format=fedora-review[Bugzilla Fedora review form]. @@ -72,7 +72,7 @@ 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] == Inform Upstream The Fedora Project prefers xref:Staying_Close_to_Upstream_Projects.adoc[Staying Close to Upstream Projects]. @@ -87,14 +87,14 @@ of important bugs in the existing release, future roadmaps etc. -[[watch_for_feedback]] +[#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] == Get Sponsored When the package is APPROVED by the reviewer, @@ -113,7 +113,7 @@ 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] == 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] @@ -140,7 +140,7 @@ 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] == Check out the module You _could_ check out your module now, @@ -156,7 +156,7 @@ Now you are ready to checkout your module from the SCM: fedpkg clone your-package .... -[[test_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] @@ -165,7 +165,7 @@ 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] == Import, commit, and build your package Now that you've checked out your (empty) package module with `fedpkg`, @@ -211,7 +211,7 @@ 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] == Update Your Branches (if desired) Branches are `f#` @@ -264,7 +264,7 @@ 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] === Submit Package as Update in Bodhi The Fedora update system called Bodhi @@ -283,7 +283,7 @@ 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] == Make the package available in "comps" files If appropriate for the package, @@ -292,7 +292,7 @@ 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] === Watch for updates Fedora has the infrastructure available diff --git a/modules/ROOT/pages/Package_Maintenance_Guide.adoc b/modules/ROOT/pages/Package_Maintenance_Guide.adoc index 3142ce1..06e6959 100644 --- a/modules/ROOT/pages/Package_Maintenance_Guide.adoc +++ b/modules/ROOT/pages/Package_Maintenance_Guide.adoc @@ -18,7 +18,7 @@ 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] == Installing _fedpkg_ and doing initial setup Start by installing `fedpkg` with `dnf install fedpkg`. @@ -42,7 +42,7 @@ 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] == Common fedpkg commands This section lists typical fedpkg commands in a normal workflow, @@ -297,7 +297,7 @@ See xref:Package_Update_Guide.adoc#updating_inter_dependent_packages[Updating in if you are making inter-dependent changes to more than one package. -[[typical_fedpkg_session]] +[#typical_fedpkg_session] == Typical fedpkg session A typical session may look like this: @@ -315,7 +315,7 @@ fedpkg lint fedpkg commit -p -c # commit and push in one go .... -[[working_with_branches]] +[#working_with_branches] == Working with branches Each Fedora release is represented by a branch in the git repository. @@ -383,7 +383,7 @@ changes made by others in working on a package, and consider how your changes will affect others. -[[resolving_merge_conflicts]] +[#resolving_merge_conflicts] === Resolving merge conflicts This is a large topic and somewhat beyond the scope of this guide, @@ -402,7 +402,7 @@ 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] === Using git mergetool to resolve conflicts Git provides a graphical diff program to help resolve conflicts. @@ -421,7 +421,7 @@ git add CONFLICTEDFILES git commit .... -[[requesting_special_dist_tags]] +[#requesting_special_dist_tags] == Requesting special dist tags When a change to a package affects a large number of dependencies @@ -439,7 +439,7 @@ 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] == Using fedpkg anonymously You can use fedpkg like this: @@ -481,10 +481,10 @@ 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] == Tips and tricks -[[local_branch_names]] +[#local_branch_names] === Local branch names If you use git commands to branch and checkout directly, @@ -492,7 +492,7 @@ 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] === Current branch and state in shell prompt It is often helpful to know what branch you are working on @@ -500,7 +500,7 @@ 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] === Importing a .src.rpm to update The command usually used to initially populate a git package repository @@ -518,7 +518,7 @@ 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] === Making changes on an older branch without breaking the upgrade path Here is the scenario: @@ -545,7 +545,7 @@ 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] === Removing a package build pending for Rawhide or Branched From time to time @@ -574,7 +574,7 @@ 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] === ssh fingerprint The recommended option is to include `VerifyHostKeyDNS yes` @@ -588,7 +588,7 @@ 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] === Problems connecting to the repository The `fedpkg` tool clones repositories using the ssh:// protocol, @@ -599,7 +599,7 @@ 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_doesnt_it_build_there] === It builds here, why doesn't it build there? Is your package building locally diff --git a/modules/ROOT/pages/Package_Orphaning_Process.adoc b/modules/ROOT/pages/Package_Orphaning_Process.adoc index 01b41fc..af776a0 100644 --- a/modules/ROOT/pages/Package_Orphaning_Process.adoc +++ b/modules/ROOT/pages/Package_Orphaning_Process.adoc @@ -6,7 +6,7 @@ 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] == Orphaning Procedure . If the package has co-maintainers, contact them @@ -45,7 +45,7 @@ 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] == Claiming Ownership of an Orphaned Package . Check why the package was orphaned @@ -63,7 +63,7 @@ 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] == 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 index e22db93..7384665 100644 --- a/modules/ROOT/pages/Package_Renaming_Process.adoc +++ b/modules/ROOT/pages/Package_Renaming_Process.adoc @@ -8,7 +8,7 @@ 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] == Re-review required When you wish to rename a package, @@ -22,7 +22,7 @@ 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 After the review is completed, and is satisfactory diff --git a/modules/ROOT/pages/Package_Retirement_Process.adoc b/modules/ROOT/pages/Package_Retirement_Process.adoc index 45a8f79..62e970b 100644 --- a/modules/ROOT/pages/Package_Retirement_Process.adoc +++ b/modules/ROOT/pages/Package_Retirement_Process.adoc @@ -8,7 +8,7 @@ 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] == What can be retired == Packages can normally only be retired in the following branches: @@ -56,7 +56,7 @@ Remove the package from https://fedoraproject.org/wiki/How_to_use_and_edit_comps Remove the package from any https://pagure.io/fedora-kickstarts[spin kickstart file]. -[[upstream_release_monitoring]] +[#upstream_release_monitoring] === Upstream Release Monitoring Remove the package from xref:Upstream_release_monitoring.adco[Upstream release monitoring] if it is listed. @@ -107,7 +107,7 @@ 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] == Claiming Ownership of a Retired Package If you really want to maintain a retired package, @@ -151,7 +151,7 @@ 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] == Obsoleting Packages While not strictly part of the process, @@ -168,7 +168,7 @@ 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]] +[#complete_removal] == Completely Removing a Package In rare cases, such as when licensing issues are discovered, diff --git a/modules/ROOT/pages/Package_Review_Process.adoc b/modules/ROOT/pages/Package_Review_Process.adoc index d3478dd..3c30d7f 100644 --- a/modules/ROOT/pages/Package_Review_Process.adoc +++ b/modules/ROOT/pages/Package_Review_Process.adoc @@ -3,7 +3,7 @@ = Package Review Process :toc: -[[review_purpose]] +[#review_purpose] == Review Purpose In order for a new package to be added to Fedora, @@ -32,7 +32,7 @@ instead of a bug number: fedpkg request-repo --exception .... -[[review_process]] +[#review_process] == Review Process There are two roles in the review process, @@ -249,7 +249,7 @@ 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] == Definitions for fedora-review flag Settings [cols=",,",] @@ -260,7 +260,7 @@ when the process is complete. |fedora-review |+ |Package Approved |=== -[[special_blocker_tickets]] +[#special_blocker_tickets] == Special blocker tickets There are a few tickets which can be placed in the "Blocks" field @@ -273,7 +273,7 @@ to indicate specific ticket statuses: |FE-Legal |The package is currently awaiting review by the legal team. |=== -[[the_whiteboard]] +[#the_whiteboard] == The Whiteboard To save time for reviewers, @@ -321,7 +321,7 @@ 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] == Tracking of Package Requests The http://fedoraproject.org/PackageReviewStatus[Package Review Tracker] provides various review-related reports diff --git a/modules/ROOT/pages/Package_Update_Guide.adoc b/modules/ROOT/pages/Package_Update_Guide.adoc index 0c01d75..01dc974 100644 --- a/modules/ROOT/pages/Package_Update_Guide.adoc +++ b/modules/ROOT/pages/Package_Update_Guide.adoc @@ -31,10 +31,10 @@ 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] == Rawhide and early Branched -[[single_packages]] +[#single_packages] === Single Packages The update workflow for single package builds @@ -65,7 +65,7 @@ running the tests (on the now hopefully fixed package), and so forth. -[[multiple_packages]] +[#multiple_packages] === Multiple Packages Some updates require changes in multiple related packages, @@ -84,7 +84,7 @@ 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] ==== Creating a side-tag To create a side-tag for building packages for Rawhide, @@ -128,7 +128,7 @@ 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] ==== Bodhi update for builds in a side-tag When you're done building all packages you want in a side-tag, @@ -182,7 +182,7 @@ 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] == Later Branched and stable releases At the https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#updates-testing-activation[updates-testing activation] point, @@ -211,7 +211,7 @@ submit the update to https://docs.fedoraproject.org/en-US/quick-docs/repositorie with `bodhi updates request stable` or the web interface. -[[update_attributes]] +[#update_attributes] === Update attributes At the time you submit the update, @@ -264,7 +264,7 @@ and a choice of 5 or even 10 may be appropriate. -[[who_will_receive_your_update_when]] +[#who_will_receive_your_update_when] === Who will receive your update, when? When a release is in Branched state, @@ -292,7 +292,7 @@ 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] === Updating inter-dependent packages If an update you wish to submit would cause a dependency issue of any kind @@ -363,7 +363,7 @@ You can also request buildroot overrides from the https://bodhi.fedoraproject.or 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] === Handling feedback from automated tests Fedora's automated testing system, OpenQA, @@ -382,7 +382,7 @@ 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] ==== Waive a result At present, a failure of the _dist.rpmdeplint_, _dist.abicheck_, or _org.centos.prod.ci.pipeline.complete_ tests @@ -430,7 +430,7 @@ 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] ==== Waive the absence of a result Submitting a waiver using subject/testcase @@ -489,7 +489,7 @@ 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] === Branched milestone freezes For a short period before each milestone release, @@ -511,7 +511,7 @@ through the https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process[blocker bu For more on the Fedora development process, see https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle[Fedora Release Life Cycle]. -[[security_updates]] +[#security_updates] == Security updates For bugs identified as security issues, @@ -521,7 +521,7 @@ 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] == New package submissions If you want to build a new package, @@ -538,7 +538,7 @@ after they have passed the xref:Package_Review_Process.adoc[Package Review Proce 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] == Consider creating a package test plan If you https://fedoraproject.org/wiki/QA:SOP_test_case_creation[create test cases] for your package, diff --git a/modules/ROOT/pages/Policy_for_Stalled_Package_Reviews.adoc b/modules/ROOT/pages/Policy_for_Stalled_Package_Reviews.adoc index 0e46338..8f75c2f 100644 --- a/modules/ROOT/pages/Policy_for_Stalled_Package_Reviews.adoc +++ b/modules/ROOT/pages/Policy_for_Stalled_Package_Reviews.adoc @@ -16,7 +16,7 @@ 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] == Reviewer not responding * When a review ticket is assigned to a reviewer @@ -31,7 +31,7 @@ The ticket is reassigned to `nobody@fedoraproject.org` with the intention to move the ticket back to a state where another reviewer can work on it. -[[submitter_not_responding]] +[#submitter_not_responding] == Submitter not responding * When the submitter of a review ticket has not responded to comments for one month, diff --git a/modules/ROOT/pages/Staying_Close_to_Upstream_Projects.adoc b/modules/ROOT/pages/Staying_Close_to_Upstream_Projects.adoc index 6dcf46b..8e6bd41 100644 --- a/modules/ROOT/pages/Staying_Close_to_Upstream_Projects.adoc +++ b/modules/ROOT/pages/Staying_Close_to_Upstream_Projects.adoc @@ -24,7 +24,7 @@ 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] == What are deviations from upstream? * *Patches*: Patches are the most common and obvious type of change from upstream. @@ -79,7 +79,7 @@ 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] == Why push changes upstream? * *Common Benefit And Reduced Maintenance Burden*: @@ -176,7 +176,7 @@ 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] == Tips On Upstreaming Patches * Talk to upstream. @@ -227,7 +227,7 @@ 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] == Some Examples Of Exceptions * *Severe Security Issues Or Major Bug Fixes*: diff --git a/modules/ROOT/pages/Upstream_Release_Monitoring.adoc b/modules/ROOT/pages/Upstream_Release_Monitoring.adoc index baefe44..f1c778b 100644 --- a/modules/ROOT/pages/Upstream_Release_Monitoring.adoc +++ b/modules/ROOT/pages/Upstream_Release_Monitoring.adoc @@ -3,7 +3,7 @@ = Upstream Release Monitoring :toc: -[[tldr_get_packages_monitored]] +[#tldr_get_packages_monitored] == TLDR; Get Packages Monitored Get bug reports for a project's releases in Fedora's Bugzilla with three steps: @@ -12,7 +12,7 @@ Get bug reports for a project's releases in Fedora's Bugzilla with three steps: . 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] == 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] @@ -48,14 +48,14 @@ 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] === 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] === The-New-Hotness https://github.com/fedora-infra/the-new-hotness/[The-new-hotness] is an application that listens to the fedmsg bus @@ -84,7 +84,7 @@ 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] == Related Projects * http://github.com/tannewt/open-source-watershed[OSWatershed] - Monitors several distributions at once diff --git a/modules/ROOT/pages/Using_the_Koji_Build_System.adoc b/modules/ROOT/pages/Using_the_Koji_Build_System.adoc index 948e4bd..d8cf134 100644 --- a/modules/ROOT/pages/Using_the_Koji_Build_System.adoc +++ b/modules/ROOT/pages/Using_the_Koji_Build_System.adoc @@ -3,7 +3,7 @@ = Using the Koji build system :toc: -[[using_koji_in_fedora]] +[#using_koji_in_fedora] == Using Koji in Fedora The https://fedoraproject.org/wiki/Koji[Koji Build System] is Fedora's RPM buildsystem. @@ -14,10 +14,10 @@ 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] === Installing Koji -[[koji_setup]] +[#koji_setup] ==== Koji Setup Before using Koji to build packages, @@ -42,7 +42,7 @@ to determine the FAS username. For more information, see https://fedoraproject.org/wiki/Infrastructure/Kerberos[Kerberos setup]. -[[koji_config]] +[#koji_config] ==== Koji Config The global-local client configuration file for koji is `/etc/koji.conf`. @@ -55,7 +55,7 @@ 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] === Building with fedpkg targets When building with `fedpkg` within a git repository, @@ -80,7 +80,7 @@ use the following: fedpkg build --target 'dist-f14-python' .... -[[chained_builds]] +[#chained_builds] ==== Chained builds WARNING: chain-builds only work when building on rawhide. To chain-build packages to update a released OS version, @@ -119,7 +119,7 @@ If a build fails, following builds are canceled, but the builds that already succeeded are pushed to the repository. -[[scratch_builds]] +[#scratch_builds] === Scratch Builds Sometimes it is useful to be able to build a package against the buildroot @@ -169,7 +169,7 @@ fedpkg scratch-build --target TARGET Run `fedpkg scratch-build --help` or `koji build --help` for more information. -[[build_failures]] +[#build_failures] === Build Failures If your package fails to build, you get an error, for example: @@ -193,7 +193,7 @@ 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] === Advanced use of Koji We've tried to make Koji self-documenting wherever possible. @@ -226,7 +226,7 @@ options: [...] .... -[[using_koji_to_generate_a_mock_config_to_replicate_a_buildroot]] +[#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. @@ -261,7 +261,7 @@ koji mock-config --tag dist-f12-build --arch=x86_64 --topurl=http://kojipkgs.fed 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] ==== Using Koji to control tasks List tasks: @@ -282,7 +282,7 @@ requeue an already-processed task (general syntax is: `koji resubmit [options] t koji resubmit 3 .... -[[building_a_package_with_the_command_line_tool]] +[#building_a_package_with_the_command_line_tool] ==== Building a Package with the command-line tool Instead of using the `fedpkg` target, @@ -308,7 +308,7 @@ 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] === Koji tags and packages organization ==== Terminology @@ -333,7 +333,7 @@ For example: kernel-2.6.9-34.EL, glibc-2.3.4-2.19. 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] ==== Tags and targets Koji organizes packages using tags. @@ -349,7 +349,7 @@ 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] ==== Koji commands for tags ===== Targets @@ -399,7 +399,7 @@ 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] ===== Latest Builds To see the latest builds for a tag, use the `latest-pkg` command: diff --git a/modules/ROOT/pages/index.adoc b/modules/ROOT/pages/index.adoc index 84dcb43..3146719 100644 --- a/modules/ROOT/pages/index.adoc +++ b/modules/ROOT/pages/index.adoc @@ -6,10 +6,10 @@ Fedora Packages are maintained collectively by a community of both Red Hat members and volunteers. -[useful_links_for_package_maintainers] +[#useful_links_for_package_maintainers] == Useful links for Package Maintainers -[get_involved] +[#get_involved] === Get Involved * xref:Joining_the_Package_Maintainers.adoc[Joining the Package Maintainers] @@ -23,14 +23,14 @@ by a community of both Red Hat members and volunteers. * https://fedoraproject.org/wiki/EPEL[EPEL] — Rebuild of Fedora packages for RHEL or compatible derivatives -[packaging_guidelines] +[#packaging_guidelines] === Packaging Guidelines The https://fedoraproject.org/wiki/Packaging_Committee[Packaging Committee] handles the rules and https://docs.fedoraproject.org/en-US/packaging-guidelines[Packaging Guidelines] for writing SPEC files for software in Fedora. -[introduction_to_packaging] +[#introduction_to_packaging] === Introduction to packaging * http://rpm.org/max-rpm-snapshot/[Maximum RPM Book] @@ -39,7 +39,7 @@ for writing SPEC files for software in Fedora. * http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/RPM_Guide/index.html[RPM Guide] — an in-depth guide to RPM. -[procedures_policies_and_guides] +[#procedures_policies_and_guides] === Procedures, Policies and Guides * https://fedoraproject.org/wiki/Using_Mock_to_test_package_builds[Using Mock to test package builds] @@ -53,7 +53,7 @@ for writing SPEC files for software in Fedora. — information on the Fedora development process, particularly various freeze dates and such -[resources_for_fedora_package_collection_contributors] +[#resources_for_fedora_package_collection_contributors] === Resources for Fedora Package Collection contributors * https://fedoraproject.org/wiki/Category:SIGs?rd=SIGs[SIGs] — Fedora Special Interest Groups @@ -70,7 +70,7 @@ particularly various freeze dates and such * https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers[Test Machines] — Contributed servers for test, mock build, compile or debug packages before submitting to koji -[important_mailing_lists] +[#important_mailing_lists] === Important Mailing Lists * https://lists.fedoraproject.org/admin/lists/devel-announce@lists.fedoraproject.org/[devel-announce] is a low traffic, announcements only list @@ -88,7 +88,7 @@ for packages you (co-)maintain. * https://lists.fedoraproject.org/admin/lists/packaging@lists.fedoraproject.org/[packaging] is the mailing list of the https://fedoraproject.org/wiki/Packaging_Committee[Fedora Packaging Committee], who determine the official packaging guidelines for Fedora projects. -[fesco] +[#fesco] === Fedora Engineering Steering Committee (FESCo) Fedora technical management is organized by the https://docs.fedoraproject.org/en-US/fesco/[Fedora Engineering Steering Committee (FESCo)].