diff --git a/.gitignore b/.gitignore
index dfcc152..7db113e 100644
--- a/.gitignore
+++ b/.gitignore
@@ -32,3 +32,4 @@
 /qemu-4.0.0-rc3.tar.xz
 /qemu-4.0.0.tar.xz
 /qemu-4.1.0-rc0.tar.xz
+/qemu-4.1.0-rc1.tar.xz
diff --git a/0002-docs-bitmaps-use-QMP-lexer-instead-of-json.patch b/0002-docs-bitmaps-use-QMP-lexer-instead-of-json.patch
deleted file mode 100644
index 24d69d6..0000000
--- a/0002-docs-bitmaps-use-QMP-lexer-instead-of-json.patch
+++ /dev/null
@@ -1,274 +0,0 @@
-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": {...}
diff --git a/qemu.spec b/qemu.spec
index 8bc1c8b..ebdcb1d 100644
--- a/qemu.spec
+++ b/qemu.spec
@@ -138,7 +138,7 @@
 %{obsoletes_block_rbd}
 
 # Release candidate version tracking
-%global rcver rc0
+%global rcver rc1
 %if 0%{?rcver:1}
 %global rcrel .%{rcver}
 %global rcstr -%{rcver}
@@ -175,8 +175,6 @@ 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
@@ -1854,6 +1852,9 @@ getent passwd qemu >/dev/null || \
 
 
 %changelog
+* Wed Jul 17 2019 Cole Robinson <aintdiscole@gmail.com> - 2:4.1.0-0.1.rc1
+- Update to qemu-4.1.0-rc1
+
 * Thu Jul 11 2019 Cole Robinson <aintdiscole@gmail.com> - 2:4.1.0-0.1.rc0
 - Update to qemu-4.1.0-rc0
 
diff --git a/sources b/sources
index 84145f7..dc01eb6 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (qemu-4.1.0-rc0.tar.xz) = 12758acc4a9f9875a566c499751dbff356b5e7f39002dfc6d457483ab6a7f360fc8306ace76d501a80eb5ae4bbece9ae6fa2e81a81668bcbcbe8f95cfa90e4a9
+SHA512 (qemu-4.1.0-rc1.tar.xz) = 3857b392a668923820fb192f30ce32385cf8d6081e6d64b5937c6729af45a852b438622a4a83bbd7e270da906726b339bfeaed3074faa5ff14cfa3039750131f