From a8613d3ea5be4b51c1412e648a90f340bdd9c258 Mon Sep 17 00:00:00 2001
From: Otto Liljalaakso <otto.liljalaakso@iki.fi>
Date: Jan 03 2023 21:00:30 +0000
Subject: Use xref instead of linking to docs.fp.o


The recommended way of linking to other Fedora Docs pages
is to use Asciidoc xref: instead of urls, see:
https://docs.fedoraproject.org/en-US/fedora-docs/contributing-docs/asciidoc-markup/#external-antora-link

Convert all such urls to xrefs.

---

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 a4b047c..5b0b98c 100644
--- a/modules/ROOT/pages/How_to_Sponsor_a_New_Contributor.adoc
+++ b/modules/ROOT/pages/How_to_Sponsor_a_New_Contributor.adoc
@@ -67,7 +67,7 @@ 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],
+If it looks reasonable and it seems that the comply with the xref:packaging-guidelines::index.adoc[Packaging Guidelines],
 then they are probably a good candidate to be sponsored.
 
 Add any comment for changes to the review request on Bugzilla
@@ -87,7 +87,7 @@ 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]
+until he applies to become a xref:fesco::Provenpackager_policy.adoc[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.
@@ -107,12 +107,12 @@ 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].
+xref:fesco::Packager_sponsor_policy.adoc[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.
+xref:fesco::Provenpackager_policy.adoc[Provenpackagers] have access to most packages.
 FESCo members should forward requests for provenpackagers
 to the sponsors mailing list
 where sponsors can give their advice
@@ -134,7 +134,7 @@ 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.
+See the xref:fesco::Provenpackager_policy.adoc[provenpackager description] for more information.
 
 [#welcome_note]
 == Welcome Note
diff --git a/modules/ROOT/pages/Joining_the_Package_Maintainers.adoc b/modules/ROOT/pages/Joining_the_Package_Maintainers.adoc
index 8d37bd9..ad2c7d8 100644
--- a/modules/ROOT/pages/Joining_the_Package_Maintainers.adoc
+++ b/modules/ROOT/pages/Joining_the_Package_Maintainers.adoc
@@ -24,7 +24,7 @@ you are prepared for it.
 If you do not know how to create an RPM package,
 refer to xref:Packaging_Tutorial_GNU_Hello.adoc[Packaging Tutorial: GNU Hello].
 
-Read the https://docs.fedoraproject.org/en-US/packaging-guidelines/[Packaging Guidelines].
+Read the xref:packaging-guidelines::index.adoc[Packaging Guidelines].
 You need to be thoroughly familiar with these.
 They govern all package submissions.
 If you have questions, ask on the Fedora List.
@@ -114,9 +114,9 @@ need to be fixed in a timely manner.
 As a Fedora package maintainer,
 it is your primary responsibility to ensure this.
 
-* Understand https://docs.fedoraproject.org/en-US/fesco/Package_maintainer_responsibilities/[Package Maintainer Responsibilities].
+* Understand xref:fesco::Package_maintainer_responsibilities.adoc[Package Maintainer Responsibilities].
 
-* Get familiar with https://docs.fedoraproject.org/en-US/fesco/Policy_for_encouraging_comaintainers_of_packages/[Policy for Encouraging Comaintainers of Packages].
+* Get familiar with xref:fesco::Policy_for_encouraging_comaintainers_of_packages.adoc[Policy for Encouraging Comaintainers of Packages].
 
 * Do not be afraid to seek the help of the Fedora community
 via the development mailing list
diff --git a/modules/ROOT/pages/New_Package_Process_for_Existing_Contributors.adoc b/modules/ROOT/pages/New_Package_Process_for_Existing_Contributors.adoc
index 488a671..12e8ad0 100644
--- a/modules/ROOT/pages/New_Package_Process_for_Existing_Contributors.adoc
+++ b/modules/ROOT/pages/New_Package_Process_for_Existing_Contributors.adoc
@@ -3,8 +3,8 @@
 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].
+. Read the xref:packaging-guidelines::index.adoc[Packaging Guidelines]
+and xref:packaging-guidelines::Naming.adoc[Package Naming Guidelines].
 Really.
 Be comfortable with them.
 
@@ -15,11 +15,11 @@ A list of existing packages in Fedora Packages is here: https://src.fedoraprojec
 
 ** Some information on how to create an RPM package is in xref:Packaging_Tutorial_GNU_Hello.adoc[Packaging Tutorial: GNU Hello].
 
-** 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]
+** Make sure that your package meets the xref:packaging-guidelines::index.adoc[Packaging Guidelines]
+and xref:packaging-guidelines::Naming.adoc[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].
+and xref:packaging-guidelines::ReviewGuidelines.adoc[Package Review Guidelines].
 They will be used during the package review.
 
 . Upload your SRPM and SPEC files onto the internet somewhere.
@@ -40,7 +40,7 @@ along with a very brief summary of what it is
 (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].
+** The review process is described in detail in xref:packaging-guidelines::ReviewGuidelines.adoc[Package Review Guidelines].
 
 . Watch the review request in Bugzilla.
 Fix any blockers that the reviewer(s) point out.
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 be34e95..abaf696 100644
--- a/modules/ROOT/pages/New_Package_Process_for_New_Contributors.adoc
+++ b/modules/ROOT/pages/New_Package_Process_for_New_Contributors.adoc
@@ -37,9 +37,9 @@ for packages under review.
 * If you don't know how to create an RPM package,
 see the xref:Packaging_Tutorial_GNU_Hello.adoc[Packaging Tutorial: GNU Hello].
 
-* 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].
+* Make sure that your package meets the xref:packaging-guidelines::index.adoc[Packaging Guidelines] and xref:packaging-guidelines::Naming.adoc[Package Naming Guidelines].
 
-* Be aware of the https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/[Package Review Guidelines]
+* Be aware of the xref:packaging-guidelines::ReviewGuidelines.adoc[Package Review Guidelines]
 (they will be used during the package review).
 
 * Make sure your package builds.
diff --git a/modules/ROOT/pages/Package_Maintenance_Guide.adoc b/modules/ROOT/pages/Package_Maintenance_Guide.adoc
index 6c119ee..edf3bdd 100644
--- a/modules/ROOT/pages/Package_Maintenance_Guide.adoc
+++ b/modules/ROOT/pages/Package_Maintenance_Guide.adoc
@@ -15,7 +15,7 @@ In fact, Fedora packaging can be a relatively painless introduction to it.
 You may have been looking for, or also be interested in:
 
 * xref:Packaging_Tutorial_GNU_Hello.adoc[Packaging Tutorial: GNU Hello]
-* https://docs.fedoraproject.org/en-US/packaging-guidelines/[Packaging Guidelines]
+* xref:packaging-guidelines::index.adoc[Packaging Guidelines]
 
 [#installing_fedpkg_and_doing_initial_setup]
 == Installing Packager Tools
@@ -312,7 +312,7 @@ 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).
+(so long as you always stay within the xref:fesco::Updates_Policy.adoc[Updates Policy] requirements).
 However, git provides us with several handy tools for working with branches.
 Here's an example:
 
@@ -335,7 +335,7 @@ 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],
+after xref:fesco::Updates_Policy.adoc#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.
 
@@ -531,7 +531,7 @@ 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]
+out to the main xref:quick-docs::repositories.adoc[repository]
 without further gating).
 This could happen in a situation
 where a bug or issue is found in your package
diff --git a/modules/ROOT/pages/Package_Orphaning_Process.adoc b/modules/ROOT/pages/Package_Orphaning_Process.adoc
index 3b895a2..5025e9f 100644
--- a/modules/ROOT/pages/Package_Orphaning_Process.adoc
+++ b/modules/ROOT/pages/Package_Orphaning_Process.adoc
@@ -1,7 +1,7 @@
 = Package Orphaning Process
 
 This page contains instructions for working with orphan packages
-as specified in https://docs.fedoraproject.org/en-US/fesco/Policy_for_orphan_and_retired_packages/[Policy for Orphan and Retired Packages]. 
+as specified in xref:fesco::Policy_for_orphan_and_retired_packages.adoc[Policy for Orphan and Retired Packages]. 
 
 [#orphaning_procedure]
 == Orphaning Procedure
diff --git a/modules/ROOT/pages/Package_Renaming_Process.adoc b/modules/ROOT/pages/Package_Renaming_Process.adoc
index d8a64a0..1750dc8 100644
--- a/modules/ROOT/pages/Package_Renaming_Process.adoc
+++ b/modules/ROOT/pages/Package_Renaming_Process.adoc
@@ -16,7 +16,7 @@ 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.)
+(see xref:packaging-guidelines::index.adoc#renaming-or-replacing-existing-packages[relevant Packaging Guidelines] for more information.)
 They *MUST* document in the review request that they have done so.
 
 [#after_the_review]
diff --git a/modules/ROOT/pages/Package_Retirement_Process.adoc b/modules/ROOT/pages/Package_Retirement_Process.adoc
index 515510a..2c81316 100644
--- a/modules/ROOT/pages/Package_Retirement_Process.adoc
+++ b/modules/ROOT/pages/Package_Retirement_Process.adoc
@@ -5,7 +5,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://docs.fedoraproject.org/en-US/fesco/Policy_for_orphan_and_retired_packages/[Policy for Orphan and Retired Packages].
+The process is governed by xref:fesco::Policy_for_orphan_and_retired_packages.adoc[Policy for Orphan and Retired Packages].
 
 [#what_can_be_retired]
 == What can be retired ==
@@ -16,7 +16,7 @@ Packages can normally only be retired in the following branches:
 * Rawhide
 * EPEL branches (`epel7`, `epel8`, `epel9`, and the corresponding `-next`
   branches) - see
-  https://docs.fedoraproject.org/en-US/epel/epel-policy-retirement/[EPEL
+  xref:epel::epel-policy-retirement.adoc/[EPEL
   Retirement Policy] for additional requirements
 
 == Procedure
@@ -27,7 +27,7 @@ Please execute the following steps in the order indicated.
 
 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].
+as specified in xref:packaging-guidelines::index.adoc#renaming-or-replacing-existing-packages[Renaming/Replacing Guidelines].
 
 === Git
 
@@ -165,7 +165,7 @@ becoming increasingly outdated.
 Please consider adding your package to https://src.fedoraproject.org/rpms/fedora-obsolete-packages/[fedora-obsolete-packages]
 if there are upgrade path issues or security concerns.
 
-Please follow https://docs.fedoraproject.org/en-US/packaging-guidelines/#renaming-or-replacing-existing-packages[the relevant packaging guidelines]
+Please follow xref:packaging-guidelines::index.adoc#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
diff --git a/modules/ROOT/pages/Package_Review_Process.adoc b/modules/ROOT/pages/Package_Review_Process.adoc
index a6234f5..7668e6b 100644
--- a/modules/ROOT/pages/Package_Review_Process.adoc
+++ b/modules/ROOT/pages/Package_Review_Process.adoc
@@ -4,7 +4,7 @@ include::{partialsdir}/attributes.adoc[]
 
 In order for a new package to be added to Fedora,
 the package must first undertake a formal review.
-The process is governed by the FESCo approved https://docs.fedoraproject.org/en-US/fesco/Package_review_policy/[Package Review Policy].
+The process is governed by the FESCo approved xref:fesco::Package_review_policy.adoc[Package Review Policy].
 
 [#review_process]
 == Review Process
@@ -17,7 +17,7 @@ This document presents both perspectives.
 === Exemptions
 
 Certain packages are exempted from the review process
-as described in the https://docs.fedoraproject.org/en-US/fesco/Package_review_policy/#what[Applicability section of Package Review Policy].
+as described in the xref:fesco::Package_review_policy.adoc#what[Applicability section of Package Review Policy].
 If an exemption is warranted,
 the contributor can directly request a repository for the package.
 The request to create a repo should include the `--exception` flag
@@ -35,7 +35,7 @@ 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/[Packaging Guidelines]
+which adheres to the xref:packaging-guidelines::index.adoc[Packaging Guidelines]
 and does not contain any https://fedoraproject.org/wiki/Forbidden_items[Forbidden Items].
 
 When you're happy with your spec file,
@@ -199,9 +199,9 @@ 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 MUST items listed in xref:packaging-guidelines::ReviewGuidelines.adoc[Review Guidelines] .
 
-** Go through the SHOULD items in https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/[Review Guidelines] .
+** Go through the SHOULD items in xref:packaging-guidelines::ReviewGuidelines.adoc[Review Guidelines] .
 
 ** The https://pagure.io/FedoraReview[FedoraReview] tool
 (packaged as `fedora-review`)
@@ -304,7 +304,7 @@ and a link to a scratch build is included.
 * 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.
+which are taken directly from the xref:packaging-guidelines::Scriptlets.adoc[Scriptlets] page.
 
 * The package contains no daemons.
 
diff --git a/modules/ROOT/pages/Package_Update_Guide.adoc b/modules/ROOT/pages/Package_Update_Guide.adoc
index 36790a6..486a7e2 100644
--- a/modules/ROOT/pages/Package_Update_Guide.adoc
+++ b/modules/ROOT/pages/Package_Update_Guide.adoc
@@ -10,7 +10,7 @@ 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].
+refer to the xref:fesco::Updates_Policy.adoc[Updates Policy].
 
 == Overview
 
@@ -22,7 +22,7 @@ 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].
+and https://fedoraproject.org/wiki/Releases/Branched[Branched] up to the xref:fesco::Updates_Policy.adoc#updates-testing-activation[Updates-testing Activation].
 
 * Branched releases after Updates-testing Activation,
 and stable releases.
@@ -80,16 +80,16 @@ with `fedpkg update`,
 the https://bodhi.fedoraproject.org/[Bodhi web interface],
 or the `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.
+to the xref:quick-docs::repositories.adoc#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]
+. After the update meets the criteria in the xref:fesco::Updates_Policy.adoc[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]
+submit the update to xref:quick-docs::repositories.adoc#stable-is-not-a-repository[stable]
 with `bodhi updates request <update_id> stable`
 or the web interface.
 
@@ -164,7 +164,7 @@ 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].
+For more details, see xref:quick-docs::repositories.adoc[Repositories].
 
 When a release is in stable state,
 the _updates-testing_ repository is disabled by default,
@@ -239,7 +239,7 @@ 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].
+once it meets the other requirements of the xref:fesco::Updates_Policy.adoc[Updates Policy].
 
 [#waive_the_absence_of_a_result]
 ==== Waive the absence of a result
@@ -304,7 +304,7 @@ 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 https://docs.fedoraproject.org/en-US/quick-docs/repositories/#the-fedora-repository-in-branched-releases[fedora] repository is frozen.
+the stable xref:quick-docs::repositories.adoc#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.
diff --git a/modules/ROOT/pages/Reporting_Issues.adoc b/modules/ROOT/pages/Reporting_Issues.adoc
index 5404f81..bc58940 100644
--- a/modules/ROOT/pages/Reporting_Issues.adoc
+++ b/modules/ROOT/pages/Reporting_Issues.adoc
@@ -17,7 +17,7 @@ https://pagure.io/fedora-infrastructure/issues[Fedora Infrastructure issue track
 This would include frozen or failing build systems.
 
 For issues within packages, see
-https://docs.fedoraproject.org/en-US/quick-docs/howto-file-a-bug/[How to File a Bug].
+xref:quick-docs::howto-file-a-bug.adoc[How to File a Bug].
 This would include typical build errors.
 
 Any questions about policy or processes should be reported to the
diff --git a/modules/ROOT/pages/Staying_Close_to_Upstream_Projects.adoc b/modules/ROOT/pages/Staying_Close_to_Upstream_Projects.adoc
index c3dbcc7..d3bb9e0 100644
--- a/modules/ROOT/pages/Staying_Close_to_Upstream_Projects.adoc
+++ b/modules/ROOT/pages/Staying_Close_to_Upstream_Projects.adoc
@@ -151,7 +151,7 @@ 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.
+Refer to xref:fesco::Updates_Policy.adoc[Updates Policy] for more details.
 
 * *ABI or API Deviations*:
 Patches that introduce a new application binary interface (ABI)
@@ -247,7 +247,7 @@ 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]
+such software does not meet the xref:packaging-guidelines::LicensingGuidelines.adoc[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
@@ -290,12 +290,12 @@ 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.
+Refer to the xref:packaging-guidelines::index.adoc#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://docs.fedoraproject.org/en-US/packaging-guidelines/#_all_patches_should_have_an_upstream_bug_link_or_comment
+* xref:packaging-guidelines::index.adoc#_all_patches_should_have_an_upstream_bug_link_or_comment[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/index.adoc b/modules/ROOT/pages/index.adoc
index 9d87ba1..a05050a 100644
--- a/modules/ROOT/pages/index.adoc
+++ b/modules/ROOT/pages/index.adoc
@@ -29,7 +29,7 @@ as well as tutorials, guides and howtos.
 === 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]
+and xref:packaging-guidelines::index.adoc[Packaging Guidelines]
 for writing SPEC files for software in Fedora.
 
 [#introduction_to_packaging]