Add patch fixing docs build
This commit is contained in:
Cole Robinson
parent
160bf4b4d5
commit
e0a72f8f2d
|
|
@ -0,0 +1,274 @@
|
|||
From f5068276729f5c3288ebd9cc29f18e9e04f643c9 Mon Sep 17 00:00:00 2001
|
||||
From: John Snow <jsnow@redhat.com>
|
||||
Date: Wed, 10 Jul 2019 15:08:07 -0400
|
||||
Subject: [PATCH] docs/bitmaps: use QMP lexer instead of json
|
||||
|
||||
The annotated style json we use in QMP documentation is not strict json
|
||||
and depending on the version of Sphinx (2.0+) or Pygments installed,
|
||||
might cause the build to fail.
|
||||
|
||||
Use the new QMP lexer.
|
||||
|
||||
Further, some versions of Sphinx can not apply custom lexers to "code"
|
||||
directives and require the use of "code-block" directives instead, so
|
||||
make that change at this time as well.
|
||||
|
||||
Tested under:
|
||||
- Sphinx 1.3.6 and Pygments 2.4
|
||||
- Sphinx 1.7.6 and Pygments 2.2 (Fedora 29 packages)
|
||||
- Sphinx 2.0.1 and Pygments 2.4
|
||||
- Sphinx 3.0.0+/f396b3a783 and Pygments 2.4 (From Sphinx git c4f44bdd)
|
||||
|
||||
Reported-by: Aarushi Mehta <mehta.aaru20@gmail.com>
|
||||
Signed-off-by: John Snow <jsnow@redhat.com>
|
||||
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
|
||||
Message-id: 20190603214653.29369-4-jsnow@redhat.com
|
||||
Signed-off-by: John Snow <jsnow@redhat.com>
|
||||
(cherry picked from commit a7786bfb0effe0b4b0fc61d8a8cd307c0b739ed7)
|
||||
---
|
||||
docs/interop/bitmaps.rst | 54 ++++++++++++++++++++--------------------
|
||||
1 file changed, 27 insertions(+), 27 deletions(-)
|
||||
|
||||
diff --git a/docs/interop/bitmaps.rst b/docs/interop/bitmaps.rst
|
||||
index 510e8809a9..cf308f197b 100644
|
||||
--- a/docs/interop/bitmaps.rst
|
||||
+++ b/docs/interop/bitmaps.rst
|
||||
@@ -199,7 +199,7 @@ persistence, and recording state can be adjusted at creation time.
|
||||
|
||||
to create a new, actively recording persistent bitmap:
|
||||
|
||||
- .. code:: json
|
||||
+ .. code-block:: QMP
|
||||
|
||||
-> { "execute": "block-dirty-bitmap-add",
|
||||
"arguments": {
|
||||
@@ -220,7 +220,7 @@ persistence, and recording state can be adjusted at creation time.
|
||||
To create a new, disabled (``-recording``), transient bitmap that tracks
|
||||
changes in 32KiB segments:
|
||||
|
||||
- .. code:: json
|
||||
+ .. code-block:: QMP
|
||||
|
||||
-> { "execute": "block-dirty-bitmap-add",
|
||||
"arguments": {
|
||||
@@ -254,7 +254,7 @@ Deletes a bitmap. Bitmaps that are ``+busy`` cannot be removed.
|
||||
|
||||
Remove a bitmap named ``bitmap0`` from node ``drive0``:
|
||||
|
||||
- .. code:: json
|
||||
+ .. code-block:: QMP
|
||||
|
||||
-> { "execute": "block-dirty-bitmap-remove",
|
||||
"arguments": {
|
||||
@@ -280,7 +280,7 @@ Clears all dirty bits from a bitmap. ``+busy`` bitmaps cannot be cleared.
|
||||
|
||||
Clear all dirty bits from bitmap ``bitmap0`` on node ``drive0``:
|
||||
|
||||
- .. code:: json
|
||||
+ .. code-block:: QMP
|
||||
|
||||
-> { "execute": "block-dirty-bitmap-clear",
|
||||
"arguments": {
|
||||
@@ -309,7 +309,7 @@ begin being recorded. ``+busy`` bitmaps cannot be enabled.
|
||||
|
||||
To set ``+recording`` on bitmap ``bitmap0`` on node ``drive0``:
|
||||
|
||||
- .. code:: json
|
||||
+ .. code-block:: QMP
|
||||
|
||||
-> { "execute": "block-dirty-bitmap-enable",
|
||||
"arguments": {
|
||||
@@ -347,7 +347,7 @@ writes to begin being ignored. ``+busy`` bitmaps cannot be disabled.
|
||||
|
||||
To set ``-recording`` on bitmap ``bitmap0`` on node ``drive0``:
|
||||
|
||||
- .. code:: json
|
||||
+ .. code-block:: QMP
|
||||
|
||||
-> { "execute": "block-dirty-bitmap-disable",
|
||||
"arguments": {
|
||||
@@ -393,7 +393,7 @@ in any one source bitmap, the target bitmap will mark that segment dirty.
|
||||
``drive0``. If ``new_bitmap`` was empty prior to this command, this achieves
|
||||
a copy.
|
||||
|
||||
- .. code:: json
|
||||
+ .. code-block:: QMP
|
||||
|
||||
-> { "execute": "block-dirty-bitmap-merge",
|
||||
"arguments": {
|
||||
@@ -424,7 +424,7 @@ attached to nodes serving as the root for guest devices.
|
||||
API. This result highlights a bitmap ``bitmap0`` attached to the root node of
|
||||
device ``drive0``.
|
||||
|
||||
- .. code:: json
|
||||
+ .. code-block:: QMP
|
||||
|
||||
-> {
|
||||
"execute": "query-block",
|
||||
@@ -562,7 +562,7 @@ new, empty bitmap that records writes from this point in time forward.
|
||||
destination. These writes will be recorded in the bitmap
|
||||
accordingly.
|
||||
|
||||
-.. code:: json
|
||||
+.. code-block:: QMP
|
||||
|
||||
-> {
|
||||
"execute": "transaction",
|
||||
@@ -650,7 +650,7 @@ Example: Resetting an Incremental Backup Anchor Point
|
||||
If we want to start a new backup chain with an existing bitmap, we can also
|
||||
use a transaction to reset the bitmap while making a new full backup:
|
||||
|
||||
-.. code:: json
|
||||
+.. code-block:: QMP
|
||||
|
||||
-> {
|
||||
"execute": "transaction",
|
||||
@@ -730,7 +730,7 @@ Example: First Incremental Backup
|
||||
|
||||
#. Issue an incremental backup command:
|
||||
|
||||
- .. code:: json
|
||||
+ .. code-block:: QMP
|
||||
|
||||
-> {
|
||||
"execute": "drive-backup",
|
||||
@@ -788,7 +788,7 @@ Example: Second Incremental Backup
|
||||
#. Issue a new incremental backup command. The only difference here is that we
|
||||
have changed the target image below.
|
||||
|
||||
- .. code:: json
|
||||
+ .. code-block:: QMP
|
||||
|
||||
-> {
|
||||
"execute": "drive-backup",
|
||||
@@ -869,7 +869,7 @@ image:
|
||||
#. Issue a new incremental backup command. Apart from the new destination
|
||||
image, there is no difference from the last two examples.
|
||||
|
||||
- .. code:: json
|
||||
+ .. code-block:: QMP
|
||||
|
||||
-> {
|
||||
"execute": "drive-backup",
|
||||
@@ -932,7 +932,7 @@ point in time.
|
||||
|
||||
#. Create a full (anchor) backup for each drive, with accompanying bitmaps:
|
||||
|
||||
- .. code:: json
|
||||
+ .. code-block:: QMP
|
||||
|
||||
-> {
|
||||
"execute": "transaction",
|
||||
@@ -1018,7 +1018,7 @@ point in time.
|
||||
|
||||
#. Issue a multi-drive incremental push backup transaction:
|
||||
|
||||
- .. code:: json
|
||||
+ .. code-block:: QMP
|
||||
|
||||
-> {
|
||||
"execute": "transaction",
|
||||
@@ -1121,7 +1121,7 @@ described above. This example demonstrates the single-job failure case:
|
||||
|
||||
#. Attempt to create an incremental backup via QMP:
|
||||
|
||||
- .. code:: json
|
||||
+ .. code-block:: QMP
|
||||
|
||||
-> {
|
||||
"execute": "drive-backup",
|
||||
@@ -1139,7 +1139,7 @@ described above. This example demonstrates the single-job failure case:
|
||||
|
||||
#. Receive a pair of events indicating failure:
|
||||
|
||||
- .. code:: json
|
||||
+ .. code-block:: QMP
|
||||
|
||||
<- {
|
||||
"timestamp": {...},
|
||||
@@ -1175,7 +1175,7 @@ described above. This example demonstrates the single-job failure case:
|
||||
#. Retry the command after fixing the underlying problem, such as
|
||||
freeing up space on the backup volume:
|
||||
|
||||
- .. code:: json
|
||||
+ .. code-block:: QMP
|
||||
|
||||
-> {
|
||||
"execute": "drive-backup",
|
||||
@@ -1193,7 +1193,7 @@ described above. This example demonstrates the single-job failure case:
|
||||
|
||||
#. Receive confirmation that the job completed successfully:
|
||||
|
||||
- .. code:: json
|
||||
+ .. code-block:: QMP
|
||||
|
||||
<- {
|
||||
"timestamp": {...},
|
||||
@@ -1233,7 +1233,7 @@ and one succeeds:
|
||||
|
||||
#. Issue the transaction to start a backup of both drives.
|
||||
|
||||
- .. code:: json
|
||||
+ .. code-block:: QMP
|
||||
|
||||
-> {
|
||||
"execute": "transaction",
|
||||
@@ -1267,13 +1267,13 @@ and one succeeds:
|
||||
#. Receive notice that the Transaction was accepted, and jobs were
|
||||
launched:
|
||||
|
||||
- .. code:: json
|
||||
+ .. code-block:: QMP
|
||||
|
||||
<- { "return": {} }
|
||||
|
||||
#. Receive notice that the first job has completed:
|
||||
|
||||
- .. code:: json
|
||||
+ .. code-block:: QMP
|
||||
|
||||
<- {
|
||||
"timestamp": {...},
|
||||
@@ -1289,7 +1289,7 @@ and one succeeds:
|
||||
|
||||
#. Receive notice that the second job has failed:
|
||||
|
||||
- .. code:: json
|
||||
+ .. code-block:: QMP
|
||||
|
||||
<- {
|
||||
"timestamp": {...},
|
||||
@@ -1365,7 +1365,7 @@ applied:
|
||||
|
||||
#. Issue the multi-drive incremental backup transaction:
|
||||
|
||||
- .. code:: json
|
||||
+ .. code-block:: QMP
|
||||
|
||||
-> {
|
||||
"execute": "transaction",
|
||||
@@ -1401,13 +1401,13 @@ applied:
|
||||
|
||||
#. Receive notice that the Transaction was accepted, and jobs were launched:
|
||||
|
||||
- .. code:: json
|
||||
+ .. code-block:: QMP
|
||||
|
||||
<- { "return": {} }
|
||||
|
||||
#. Receive notification that the backup job for ``drive1`` has failed:
|
||||
|
||||
- .. code:: json
|
||||
+ .. code-block:: QMP
|
||||
|
||||
<- {
|
||||
"timestamp": {...},
|
||||
@@ -1434,7 +1434,7 @@ applied:
|
||||
|
||||
#. Receive notification that the job for ``drive0`` has been cancelled:
|
||||
|
||||
- .. code:: json
|
||||
+ .. code-block:: QMP
|
||||
|
||||
<- {
|
||||
"timestamp": {...}
|
||||
|
|
@ -175,6 +175,8 @@ Source21: 95-kvm-ppc64-memlock.conf
|
|||
# Fix rawhide build (bz #1718926)
|
||||
# Not upstream, some mailing list patches have been proposed
|
||||
Patch0001: 0001-NOT-UPSTREAM-Build-fix-with-latest-kernel.patch
|
||||
# Fix for docs building
|
||||
Patch0002: 0002-docs-bitmaps-use-QMP-lexer-instead-of-json.patch
|
||||
|
||||
# documentation deps
|
||||
BuildRequires: texinfo
|
||||
|
|
|
|||
Loading…
Reference in New Issue