diff --git a/docs/_templates/page.html b/docs/_templates/page.html index 135ceabf6a641e07e5d7bf5f8a006ec0734c565a..5c21e26afed0b272debdf874744fbef02a023779 100644 --- a/docs/_templates/page.html +++ b/docs/_templates/page.html @@ -1,8 +1,8 @@ {% 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. + 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.

diff --git a/docs/alpha/michelson.rst b/docs/alpha/michelson.rst index bfadf2f4222fc368a08093db89ed3053ca37a3ca..b20f2a5f52bdd8ba5766c924f4b3a29ec8519b9f 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 diff --git a/docs/developer/javascript.rst b/docs/developer/javascript.rst index eee709db45bd257794068a90181fa09b8128589f..bad96f415f12e0356fd474d487228bfc784ca134 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 diff --git a/docs/developer/proposal_testing.rst b/docs/developer/proposal_testing.rst index 314e442f82b5760c4ae8cdcb138631905c360311..d12193025469b1471dda4c1e17430a458b230b18 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/developer/testing.rst b/docs/developer/testing.rst index 58cbbbb62c88d5b81251677972c4684b4e58432d..991e51012cb4fd6ac697f88cd450b0d18a418dea 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 diff --git a/docs/introduction/get_troubleshooting.rst b/docs/introduction/get_troubleshooting.rst index fc71c79490f73891647cddc26bc9478107ea3e53..83750dc3de657256e763105f8288a091ddc14052 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 -------------- diff --git a/docs/introduction/howtoget.rst b/docs/introduction/howtoget.rst index 4d46fabfdfc79830723744abcffe079851024053..1539fc0049bc3b8b4d5982444aa95463115d54f7 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: diff --git a/docs/protocols/015_lima.rst b/docs/protocols/015_lima.rst index fbb94ef2f1636b2c464d2934426661377c87e335..e4832417a56254d261cf76930b4c288bbffdf630 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`) diff --git a/docs/releases/version-14.rst b/docs/releases/version-14.rst index 45876779fc293e7b38d7dfbbe098f9f3de58d12e..6b7bce73c319816c0f06d99b3fbf201a959733d2 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 --------- diff --git a/docs/user/key-management.rst b/docs/user/key-management.rst index 78ca9a125d8cef86e229f692608683ec4d24dbdc..31de53ffacf30be5d974cddc1008d8465823f0d5 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: diff --git a/docs/user/snapshots.rst b/docs/user/snapshots.rst index c4a5fd9e9e5c8db54182009a5d7f2862c0c404a4..0301ce6e06da7e93de812a7cd88be80339e8c5b4 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. +---------+---------------+-----------------+ @@ -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 `_