From 4bfe6f3e45e0716c4cccb6e16c1088613e539ba8 Mon Sep 17 00:00:00 2001 From: Nic Volanschi Date: Thu, 22 Sep 2022 09:28:05 +0200 Subject: [PATCH 01/12] doc: link to update instruction in releases/v14 --- docs/releases/version-14.rst | 2 ++ 1 file changed, 2 insertions(+) diff --git a/docs/releases/version-14.rst b/docs/releases/version-14.rst index 45876779fc29..6b7bce73c319 100644 --- a/docs/releases/version-14.rst +++ b/docs/releases/version-14.rst @@ -61,6 +61,8 @@ To update from sources:: If you are using Docker instead, use the ``v14.1`` Docker images of Tezos. +If you are using other forms of Octez distributions (e.g. binary packages), check the update instructions at the end of the corresponding section in :doc:`../introduction/howtoget`. + Changelog --------- -- GitLab From 1bbb11f27145412eb456e9d183581af47e8566aa Mon Sep 17 00:00:00 2001 From: Danny Willems Date: Mon, 26 Sep 2022 09:29:30 +0200 Subject: [PATCH 02/12] Doc: typo in JavaScript section --- docs/developer/javascript.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/developer/javascript.rst b/docs/developer/javascript.rst index eee709db45bd..bad96f415f12 100644 --- a/docs/developer/javascript.rst +++ b/docs/developer/javascript.rst @@ -38,7 +38,7 @@ commands to install ``nvm`` and ``node``: :: curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.0/install.sh | bash - scripts/install_builld_deps.js.sh + scripts/install_build_deps.js.sh ``scripts/install_build_deps.js.sh`` will also install JavaScript dependencies required for running tests in JS. If you install node @@ -50,7 +50,7 @@ Running tests ------------- One can run JavaScript tests with ``make test-js`` in the project root -or directly using dune with ``dune builld @SOME-PATH/runtest_js``. +or directly using dune with ``dune build @SOME-PATH/runtest_js``. Adding tests -- GitLab From 758a56f97c671059c57774763e9803d95408d425 Mon Sep 17 00:00:00 2001 From: Nic Volanschi Date: Thu, 29 Sep 2022 15:55:01 +0300 Subject: [PATCH 03/12] doc: typos in snapshots.rst --- docs/user/snapshots.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/user/snapshots.rst b/docs/user/snapshots.rst index c4a5fd9e9e5c..24c78f33e396 100644 --- a/docs/user/snapshots.rst +++ b/docs/user/snapshots.rst @@ -172,7 +172,7 @@ distributing snapshots through `IPFS `_. Export capabilities ~~~~~~~~~~~~~~~~~~~ -The following table recapitulate the different kind of snapshot that +The following table recapitulates the different kinds of snapshots that can be exported from a given history mode node. +---------+---------------+-----------------+ -- GitLab From 41a28c5ce3f4ff071219f994c33fdcf8d5e10190 Mon Sep 17 00:00:00 2001 From: Nic Volanschi Date: Mon, 3 Oct 2022 17:40:49 +0300 Subject: [PATCH 04/12] doc: fix banner on smartphones --- docs/_templates/page.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/_templates/page.html b/docs/_templates/page.html index 135ceabf6a64..853b51dcbc11 100644 --- a/docs/_templates/page.html +++ b/docs/_templates/page.html @@ -1,6 +1,6 @@ {% block header %}
-

+

Starting from Octez release 15.0, the names of the Octez binaries will start with "octez-" and will not include any protocol number (e.g. "octez-client", "octez-node", "octez-baker-PtKathma" instead of "tezos-client", "tezos-node", "tezos-baker-015-PtKathma"). These renamings are already in place on the "master" branch. The legacy names ("tezos-*") are still used in the documentation for now and will be supported through symbolic links until the majority of users will upgrade to releases >= 15.0. -- GitLab From 2f4574360818342d4070162a89b83e31425256bc Mon Sep 17 00:00:00 2001 From: Nicolas Ayache Date: Tue, 4 Oct 2022 13:35:49 +0200 Subject: [PATCH 05/12] doc: typo in Michelson --- docs/alpha/michelson.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/alpha/michelson.rst b/docs/alpha/michelson.rst index bfadf2f4222f..b20f2a5f52bd 100644 --- a/docs/alpha/michelson.rst +++ b/docs/alpha/michelson.rst @@ -3014,7 +3014,7 @@ annotations will see only their top-most stack type elements annotated. :: - UNPAIR @fist @second + UNPAIR @first @second :: pair 'a 'b : 'S -> @first 'a : @second 'b : 'S -- GitLab From d45427d28b35a846b97085ed24f18819b877d4d7 Mon Sep 17 00:00:00 2001 From: Nic Volanschi Date: Tue, 4 Oct 2022 14:01:59 +0200 Subject: [PATCH 06/12] doc: eliminate links to Giganode, whiched ceased operation --- docs/developer/proposal_testing.rst | 15 ++++++--------- docs/user/snapshots.rst | 2 +- 2 files changed, 7 insertions(+), 10 deletions(-) diff --git a/docs/developer/proposal_testing.rst b/docs/developer/proposal_testing.rst index 314e442f82b5..d12193025469 100644 --- a/docs/developer/proposal_testing.rst +++ b/docs/developer/proposal_testing.rst @@ -177,21 +177,20 @@ mistake `snapshot a protocol`, like in step 1 above, with `snapshot a node`, which results in a snapshot file like in here) that contains the real status of a Mainnet's node at a particular moment in time. Such a snapshot file can be downloaded from several sites on the internet (see :doc:`../user/snapshots`). -For instance, the site `Giganode `_ stores +Such websites store daily snapshot files from both Mainnet and Testnet, in both ``full`` and ``rolling`` mode (see :doc:`../user/history_modes`). For the purposes of testing the migration, a snapshot file in ``rolling`` mode is enough. It is important to use a snapshot file that is recent enough as to contain the predecessor of the Alpha protocol. It is also important to note down the level at which the snapshot file was taken, which determines at which level we want to trigger the -migration. The `Giganode snapshots page `_ -conveniently indicates the date and the level (the `block`) at which each +migration. The snapshots websites +conveniently indicate the date and the level (the `block`) at which each snapshot file was taken. In our example we will use a snapshot file ``~/snapshot-mainnet.rolling`` -that was downloaded from `Giganode `_ -and which was taken at level ``1617344``. +which was taken at level ``1617344``. The next subsections explain each of the individual steps 1--7. @@ -357,8 +356,7 @@ If we wish to test the migration in a realistic scenario, we need to import a context from a Mainnet's snapshot file. As explained in the beginning of Section `Prepare the migration`_, in our example we will use a snapshot file ``~/snapshot-mainnet.rolling`` -that was downloaded from `Giganode `_ -and which was taken at level ``1617344``. +which was taken at level ``1617344``. We also need to generate a node identity, which we will keep in the folder that contains the history of the node. Since importing a node from a snapshot file is @@ -378,8 +376,7 @@ The ``./tezos-node snapshot import`` command accepts an option ``--block `` that instructs the command to check that the hash of the last block in the imported chain is ````. This mechanism helps the developer to check that the imported chain contains blocks that are part of -the current main chain of the Tezos network. The -`Giganode `_ provides +the current main chain of the Tezos network. The snapshots websites normally provide the hash of the last block in a given snapshot file. Although we will not be using the ``--block`` option in this tutorial, the developer is encouraged to check that this prefix corresponds to the hash of a real block in Mainnet. diff --git a/docs/user/snapshots.rst b/docs/user/snapshots.rst index 24c78f33e396..0301ce6e06da 100644 --- a/docs/user/snapshots.rst +++ b/docs/user/snapshots.rst @@ -192,6 +192,6 @@ There are several services providing node snapshots. They create snapshots of their nodes on a regular basis (usually daily) and make them available for download. These include: -* `Giga Node `_ * `XTZ-Shots `_ * `Lambs on acid `_ +* `Marigold snapshots `_ -- GitLab From 00c3651a342122bf570ada10f42bf18cd789c012 Mon Sep 17 00:00:00 2001 From: Nic Volanschi Date: Tue, 4 Oct 2022 16:44:49 +0200 Subject: [PATCH 07/12] doc: fix some redirected links to gitlab docs --- docs/developer/testing.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/developer/testing.rst b/docs/developer/testing.rst index 58cbbbb62c88..991e51012cb4 100644 --- a/docs/developer/testing.rst +++ b/docs/developer/testing.rst @@ -510,7 +510,7 @@ The results of the test suite on terminated pipelines is presented on the details of the merge request page corresponding to the pipeline's branch (if any). For more information, see the `GitLab documentation on Unit test reports -`__. +`__. By default, the ``test`` of the CI runs the tests as a set of independent jobs that cluster the tests with a varying grain. This strikes a balance between exploiting GitLab @@ -589,7 +589,7 @@ The summary report gives the merge request an overall test coverage percentage Additionally, using ``bisect-ppx-report cobertura``, we produce and upload a Cobertura artifact activating the `test coverage visualization -`_ +`_ in GitLab: .. image:: images/testing-coverage-markers.png -- GitLab From 4493b1f8e5d2d0dcb01a56c159f61c26d8a40c95 Mon Sep 17 00:00:00 2001 From: Nic Volanschi Date: Wed, 5 Oct 2022 12:26:23 +0200 Subject: [PATCH 08/12] doc: add link from get_troubleshooting to support --- docs/introduction/get_troubleshooting.rst | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/docs/introduction/get_troubleshooting.rst b/docs/introduction/get_troubleshooting.rst index fc71c79490f7..83750dc3de65 100644 --- a/docs/introduction/get_troubleshooting.rst +++ b/docs/introduction/get_troubleshooting.rst @@ -4,6 +4,10 @@ Installation troubleshooting This page groups information about known problems when installing Tezos (more precisely, the "Octez" implementation of Tezos software). The different issues and their solutions are grouped per installation method, except for generic issues concerning all installation scenarios. +This page lists only the most frequent problems. +If you don't find your problem in this page, chances are that the problem is too specific. +Consult the :doc:`./support` sources (e.g. the Tezos Stack Exchange), to see if others have encountered a similar problem, and whether a solution is known. + Generic issues -------------- -- GitLab From 7151a1a6b8247aa05daf6f0718edc78e0da0ba4a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Rapha=C3=ABl=20Cauderlier?= Date: Wed, 5 Oct 2022 17:50:04 +0200 Subject: [PATCH 09/12] doc: fix a typo in Lima changelog --- docs/protocols/015_lima.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/protocols/015_lima.rst b/docs/protocols/015_lima.rst index fbb94ef2f163..e4832417a562 100644 --- a/docs/protocols/015_lima.rst +++ b/docs/protocols/015_lima.rst @@ -28,7 +28,7 @@ It requires protocol environment V7, compared to V6 for Kathmandu. protocol (MR :gl:`!6042`) - Introduce a module Q, making a subset of Zarith.Q available to the - protocol (MR :gl:`!6042`) + protocol (MR :gl:`!6092`) - Generalise the Bounded module to support more datatypes. (MR :gl:`!6076`) -- GitLab From a65bacfcb32ec7330c4e951355a0288c7374d0d1 Mon Sep 17 00:00:00 2001 From: daniel_nomadic Date: Thu, 6 Oct 2022 17:39:17 +0200 Subject: [PATCH 10/12] changing 0x00 by 0x03. 0x00 is not supported --- docs/user/key-management.rst | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/docs/user/key-management.rst b/docs/user/key-management.rst index 78ca9a125d8c..31de53ffacf3 100644 --- a/docs/user/key-management.rst +++ b/docs/user/key-management.rst @@ -145,7 +145,7 @@ of the signer. home~$ tezos-signer launch socket signer -a home vps~$ tezos-client import secret key alice tcp://home:7732/tz1abc... - vps~$ tezos-client sign bytes 0x00 for alice + vps~$ tezos-client sign bytes 0x03 for alice Every time the client on *vps* needs to sign an operation for *alice*, it sends a signature request to the remote signer on @@ -156,29 +156,29 @@ Consequently, if we ever have to move the signer to another machine or access it A more flexible method is to only register a key as being remote, and separately supply the address of the signer uisng the `-R` option:: vps~$ tezos-client -R 'tcp://home:7732' import secret key alice remote:tz1abc... - vps~$ tezos-client -R 'tcp://home:7732' sign bytes 0x00 for alice + vps~$ tezos-client -R 'tcp://home:7732' sign bytes 0x03 for alice Alternatively, the address of the signer can be recorded in environment variables:: vps~$ export TEZOS_SIGNER_TCP_HOST=home vps~$ export TEZOS_SIGNER_TCP_PORT=7732 vps~$ tezos-client import secret key alice remote:tz1abc... - vps~$ tezos-client sign bytes 0x00 for alice + vps~$ tezos-client sign bytes 0x03 for alice All the above methods can be retargeted to the other signing schemes, for instance, ``http``:: home~$ tezos-signer launch http signer -a home vps~$ tezos-client import secret key alice http://home:7732/tz1abc... - vps~$ tezos-client sign bytes 0x00 for alice + vps~$ tezos-client sign bytes 0x03 for alice vps~$ tezos-client -R 'http://home:7732' import secret key alice remote:tz1abc... - vps~$ tezos-client -R 'http://home:7732' sign bytes 0x00 for alice + vps~$ tezos-client -R 'http://home:7732' sign bytes 0x03 for alice vps~$ export TEZOS_SIGNER_HTTP_HOST=home vps~$ export TEZOS_SIGNER_HTTP_PORT=7732 vps~$ tezos-client import secret key alice remote:tz1abc... - vps~$ tezos-client sign bytes 0x00 for alice + vps~$ tezos-client sign bytes 0x03 for alice The complete list of environment variables for connecting to the remote signer is: -- GitLab From bdbaf6cbf5bccd63de9c8742f81d3fd7c0301454 Mon Sep 17 00:00:00 2001 From: "sol.lederer" Date: Fri, 7 Oct 2022 11:27:45 -0400 Subject: [PATCH 11/12] doc: fixing docker sectioning --- docs/introduction/howtoget.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/introduction/howtoget.rst b/docs/introduction/howtoget.rst index 4d46fabfdfc7..1539fc0049bc 100644 --- a/docs/introduction/howtoget.rst +++ b/docs/introduction/howtoget.rst @@ -176,7 +176,7 @@ The node's RPC interface will be available on localhost and can be queried with docker exec node-alpha tezos-client rpc list Building Docker Images Locally ------------------------------- +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The docker image used throughout the docker-compose files is fetched from upstream, but you can also build one locally and reference it. Run the following commands to build the image: @@ -194,7 +194,7 @@ And then update the docker-compose file (e.g., ``alpha.yml``) with the docker ta ... Docker Image Configuration --------------------------- +~~~~~~~~~~~~~~~~~~~~~~~~~~ Lastly, the entrypoint script (:src:`scripts/docker/entrypoint.sh`) provides the following configurable environment variables: -- GitLab From 1be2fc21a93d8e91443ab003a95e20c736939826 Mon Sep 17 00:00:00 2001 From: Nic Volanschi Date: Tue, 11 Oct 2022 18:34:13 +0200 Subject: [PATCH 12/12] doc: update banner to v15_rc --- docs/_templates/page.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/_templates/page.html b/docs/_templates/page.html index 853b51dcbc11..5c21e26afed0 100644 --- a/docs/_templates/page.html +++ b/docs/_templates/page.html @@ -2,7 +2,7 @@

Starting from Octez release 15.0, the names of the Octez binaries will start with "octez-" and will not include any protocol number (e.g. "octez-client", "octez-node", "octez-baker-PtKathma" instead of "tezos-client", "tezos-node", "tezos-baker-015-PtKathma"). - These renamings are already in place on the "master" branch. + These renamings are already in place on the "master" branch and in the v15_rc release candidate(s). The legacy names ("tezos-*") are still used in the documentation for now and will be supported through symbolic links until the majority of users will upgrade to releases >= 15.0.

-- GitLab