From 447857123c67b88c0e5c4345766998f2ee57d0a2 Mon Sep 17 00:00:00 2001 From: "sol.lederer" Date: Mon, 7 Nov 2022 16:11:48 -0500 Subject: [PATCH] docs: octez rename sweep 2 --- docs/.gitignore | 16 +++++----- docs/CHANGES.rst | 2 +- docs/Makefile | 9 +++--- docs/alpha/cli-commands.rst | 4 +-- docs/alpha/michelson.rst | 2 +- docs/alpha/sapling.rst | 2 +- docs/alpha/transaction_rollups.rst | 16 +++++----- docs/developer/openmetrics.rst | 2 +- docs/developer/proposal_testing.rst | 42 +++++++++++++------------- docs/developer/testing.rst | 4 +-- docs/introduction/howtoget.rst | 12 ++++---- docs/introduction/howtorun.rst | 6 ++-- docs/introduction/howtouse.rst | 10 +++--- docs/introduction/install-opam.sh | 4 +-- docs/kathmandu/cli-commands.rst | 4 +-- docs/kathmandu/sapling.rst | 2 +- docs/kathmandu/transaction_rollups.rst | 16 +++++----- docs/lima/cli-commands.rst | 4 +-- docs/lima/sapling.rst | 2 +- docs/lima/transaction_rollups.rst | 16 +++++----- docs/protocols/tenderbake.rst | 12 ++++---- docs/releases/version-11.rst | 2 +- docs/user/key-management.rst | 6 ++-- docs/user/light.rst | 2 +- docs/user/logging.rst | 2 +- docs/user/proxy-server.rst | 2 +- 26 files changed, 100 insertions(+), 101 deletions(-) diff --git a/docs/.gitignore b/docs/.gitignore index d63c6f035f4c..6683e75aabc7 100644 --- a/docs/.gitignore +++ b/docs/.gitignore @@ -1,11 +1,11 @@ -tezos-baker.html -tezos-accuser.html -tezos-endorser.html -tezos-client.html -/api/tezos-snoop.html -/api/tezos-codec.html -/api/tezos-admin-client.html -/api/tezos-signer.html +octez-baker.html +octez-accuser.html +octez-endorser.html +octez-client.html +/api/octez-snoop.html +/api/octez-codec.html +/api/octez-admin-client.html +/api/octez-signer.html /alpha/rpc.rst /shell/rpc.rst diff --git a/docs/CHANGES.rst b/docs/CHANGES.rst index e675c4876943..3f1722f4f7d5 100644 --- a/docs/CHANGES.rst +++ b/docs/CHANGES.rst @@ -101,7 +101,7 @@ Node sections: ``validator.chain``, ``validator.peer``, ``prevalidator`` and ``validator.block``. Section ``node.chain_validator`` is merged into ``validator.chain`` for consistency reasons. Those events see - their JSON reprensentation shortened, with no duplicated + their JSON representation shortened, with no duplicated information. e.g. ``validator.peer`` events were named ``validator.peer.v0`` at top-level and had an ``event`` field with a ``name`` field containing the actual event name, for example diff --git a/docs/Makefile b/docs/Makefile index 02e49672be03..7b616b86b4d2 100644 --- a/docs/Makefile +++ b/docs/Makefile @@ -1,9 +1,8 @@ # You can set these variables from the command line. SPHINXOPTS = -j auto -aE -n -W --keep-going SPHINXBUILD = poetry run sphinx-build -SPHINXPROJ = Tezos SOURCEDIR = . -TMPDOCDIR = /tmp/tezosdoc +TMPDOCDIR = /tmp/octezdoc BUILDDIR = _build TOPBUILDDIR = ../_build/default @@ -22,8 +21,8 @@ kathmandu_long = PtKathmankSpLLDALzWw7CGD2j2MtyveTwboEYokqUCP4a1LxMg lima_long = PtLimaPtLMwfNinJi9rCfDPWea8dFgTZ1MeJ9f1m2SRic6ayiwW alpha_long = ProtoALphaALphaALphaALphaALphaALphaALphaALphaDdp3zK -kathmandu_short = 014-PtKathma -lima_short = 015-PtLimaPt +kathmandu_short = PtKathma +lima_short = PtLimaPt alpha_short = alpha SCRIPTSDIR = scripts @@ -203,4 +202,4 @@ lint: pylint pycodestyle lint_black clean: @-rm -Rf "$(BUILDDIR)" linkcheck @-rm -Rf api/errors.rst developer/metrics.csv user/node-config.json alpha/rpc.rst shell/rpc.rst shell/p2p_api.rst user/default-acl.json CHANGES-dev.rst - @-rm -Rf api/tezos-*.html api/tezos-*.txt active/tezos-*.html kathmandu/tezos-*.html lima/tezos-*.html alpha/tezos-*.html + @-rm -Rf api/octez-*.html api/octez-*.txt active/octez-*.html kathmandu/octez-*.html lima/octez-*.html alpha/octez-*.html diff --git a/docs/alpha/cli-commands.rst b/docs/alpha/cli-commands.rst index 4f0763d90f68..38bf04030e04 100644 --- a/docs/alpha/cli-commands.rst +++ b/docs/alpha/cli-commands.rst @@ -3,8 +3,8 @@ Command Line Interface ********************** This document is a prettier output of the documentation produced by -the command ``man`` of the different Tezos binaries. You can obtain similar pages -using shell commands such as (:ref:`indicating the appropriate protocol `): +the command ``man`` of the different Octez binaries. You can obtain similar pages +using shell commands such as (:ref:`indicating the appropriate protocol `): :: diff --git a/docs/alpha/michelson.rst b/docs/alpha/michelson.rst index 1ebe4ed7be79..80a21c5e0714 100644 --- a/docs/alpha/michelson.rst +++ b/docs/alpha/michelson.rst @@ -3394,7 +3394,7 @@ data include not only a description of the action to perform but also the address of the multisig contract and a counter that gets incremented at each successful call to the contract. -The multisig commands of :ref:`Tezos command line client ` +The multisig commands of :ref:`Octez command line client ` use this smart contract. Moreover, `functional correctness of this contract has been verified diff --git a/docs/alpha/sapling.rst b/docs/alpha/sapling.rst index b4a0f3d9b4fe..5854de0371ab 100644 --- a/docs/alpha/sapling.rst +++ b/docs/alpha/sapling.rst @@ -485,7 +485,7 @@ unshielding. # set up the sandbox ./src/bin_node/octez-sandboxed-node.sh 1 --connections 0 & eval `./src/bin_client/octez-init-sandboxed-client.sh 1` - tezos-activate-alpha + octez-activate-alpha # originate the contract with its initial empty sapling storage, # bake a block to include it. diff --git a/docs/alpha/transaction_rollups.rst b/docs/alpha/transaction_rollups.rst index 3bc2278b5d02..1e3e71f1659e 100644 --- a/docs/alpha/transaction_rollups.rst +++ b/docs/alpha/transaction_rollups.rst @@ -598,7 +598,7 @@ rollup node is to prepare its configuration file. .. code:: sh - tezos-tx-rollup-node-alpha init ${mode} config \ + octez-tx-rollup-node-alpha init ${mode} config \ for ${tx_rollup_address_or_name} \ --data-dir ${data_dir} \ --rpc-addr ${rpc_address} \ @@ -669,7 +669,7 @@ For instance, .. code:: sh - tezos-tx-rollup-node-alpha init batcher config for ${rollup} \ + octez-tx-rollup-node-alpha init batcher config for ${rollup} \ --data-dir /tmp/tx-node \ --rpc-addr ${rollup_node_rpc_server_address} \ --batch-signer ${batcher} @@ -685,7 +685,7 @@ Once the configuration is ready, starting the rollup node is as simple as .. code:: sh - tezos-tx-rollup-node-alpha --endpoint ${tezos_node_address} \ + octez-tx-rollup-node-alpha --endpoint ${tezos_node_address} \ run ${mode} for ${rollup_address_or_name} \ --data-dir ${data_dir} \ [--allow-deposit] @@ -825,7 +825,7 @@ the ``get balance`` command can be used. .. code:: sh - tezos-tx-rollup-client-alpha get balance for alice of ${ticket_hash} + octez-tx-rollup-client-alpha get balance for alice of ${ticket_hash} .. note:: @@ -836,7 +836,7 @@ To transfer a ticket to another address on the layer-2, the .. code:: sh - tezos-tx-rollup-client-alpha transfer ${qty} \ + octez-tx-rollup-client-alpha transfer ${qty} \ of ${ticket_hash} \ from ${src} to ${dst} \ [--endpoint ${tx_rollup_node_address}] @@ -854,7 +854,7 @@ block, one can use the following command. .. code:: sh - tezos-tx-rollup-client-alpha get block ${block_id} + octez-tx-rollup-client-alpha get block ${block_id} where ``block_id`` can either be ``head`` (the latest rollup block), a level (0, 1, etc.), or a Tezos block hash. @@ -864,7 +864,7 @@ rollup, and to inject it back in the layer-1. .. code:: sh - tezos-tx-rollup-client-alpha withdraw ${qty} of ${ticket_hash} from ${l2_src} to ${l1_dst} + octez-tx-rollup-client-alpha withdraw ${qty} of ${ticket_hash} from ${l2_src} to ${l1_dst} Similarly to the ``transfer`` command, ``l2_src`` has to be an alias to a BLS pair of keys, while ``l1_dst`` can either be an alias or an @@ -896,7 +896,7 @@ To retrieve the values of ``micheline_contents``, ``ty`` and .. code:: sh - tezos-tx-rollup-client-alpha rpc get "/context/head/tickets/${ticket_hash}" + octez-tx-rollup-client-alpha rpc get "/context/head/tickets/${ticket_hash}" Besides, the entrypoint ``ep`` of ``sc_dst`` needs to expect a ``ticket ty`` as its input. diff --git a/docs/developer/openmetrics.rst b/docs/developer/openmetrics.rst index f5567f5239ce..63dd9272de2a 100644 --- a/docs/developer/openmetrics.rst +++ b/docs/developer/openmetrics.rst @@ -61,7 +61,7 @@ source - using adequate values: :: - - job_name: 'tezos-metrics' + - job_name: 'octez-metrics' scheme: http static_configs: - targets: ['localhost:9091'] diff --git a/docs/developer/proposal_testing.rst b/docs/developer/proposal_testing.rst index 78bbc809f08a..0668ef318c0d 100644 --- a/docs/developer/proposal_testing.rst +++ b/docs/developer/proposal_testing.rst @@ -43,7 +43,7 @@ By default, the sandbox starts from the `genesis` block at level 0, and the sandbox's active protocol is the `Genesis protocol`. Once the sandbox is started, the Alpha protocol can be activated by invoking the command:: - $ tezos-activate-alpha + $ octez-activate-alpha This command inserts a new block after which the active protocol is the Alpha protocol. From this point on, making the chain progress is straightforward @@ -366,11 +366,11 @@ fresh test folder every time we want to perform the migration. For instance, the following commands import a context from the snapshot file ``~/snapshot-mainnet.rolling`` -into the folder ``/tmp/mainnet``, +into the folder ``/tmp/octez-node-mainnet``, and generate an identity in the same folder:: - $ ./octez-node snapshot import ~/snapshot-mainnet.rolling --data-dir /tmp/tezos-node-mainnet - $ ./octez-node identity generate --data-dir /tmp/tezos-node-mainnet + $ ./octez-node snapshot import ~/snapshot-mainnet.rolling --data-dir /tmp/octez-node-mainnet + $ ./octez-node identity generate --data-dir /tmp/octez-node-mainnet The ``./octez-node snapshot import`` command accepts an option ``--block `` that instructs the command to check that the hash of @@ -393,7 +393,7 @@ keys actually encode the same bytes as their corresponding public keys. By adding to the yes-wallet the existing accounts of Mainnet bakers, we would have enough rights to bake blocks at will. We can do so by running:: - $ dune exec devtools/yes_wallet/yes_wallet.exe -- create from context /tmp/tezos-node-mainnet in /tmp/yes-wallet --active-bakers-only + $ dune exec devtools/yes_wallet/yes_wallet.exe -- create from context /tmp/octez-node-mainnet in /tmp/yes-wallet --active-bakers-only This command creates a yes-wallet and places its folder in the system's temp directory (in our example, ``/tmp``) as given by the path argument @@ -407,7 +407,7 @@ power), you can also use the ``--staking-share`` option to provide a limit. For instance, the first largest bakers with an accumulated stake of at least 75 percent can be kept with:: - $ dune exec devtools/yes_wallet/yes_wallet.exe -- create from context /tmp/tezos-node-mainnet in /tmp/yes-wallet --active-bakers-only --staking-share 75 + $ dune exec devtools/yes_wallet/yes_wallet.exe -- create from context /tmp/octez-node-mainnet in /tmp/yes-wallet --active-bakers-only --staking-share 75 .. note:: Prior to switching to the Tenderbake consensus algorithm it was @@ -457,14 +457,14 @@ was taken, we can use:: In the latter case both the context and the yes-wallet folder will be placed in the system's temp directory. In our example the temp directory is ``/tmp``, and the context and yes-wallet would be placed in paths -``/tmp/tezos-node-mainnet`` and ``/tmp/yes-wallet`` +``/tmp/octez-node-mainnet`` and ``/tmp/yes-wallet`` respectively. If the script detects that the yes-wallet folder already exists int ``/tmp``, then it will clean it by removing spurious files ``/tmp/yes-wallet/blocks`` and ``/tmp/yes-wallet/wallet_locks``, and it will not create a new yes-wallet folder. If the script detects that the folder -``/tmp/tezos-node-mainnet`` already exists, or if the developer +``/tmp/octez-node-mainnet`` already exists, or if the developer passes the path of a folder instead of the path of a snapshot file, then the script will use the corresponding folder as the original folder, and will not import a new context. @@ -495,7 +495,7 @@ We can also start the client:: $ eval `./src/bin_client/octez-init-sandboxed-client.sh 1` -Instead of command ``tezos-activate-alpha``, the sandboxed client script +Instead of command ``octez-activate-alpha``, the sandboxed client script ``src/bin_client/octez-init-sandboxed-client.sh`` now accepts a command ``tezos-activate-XXX-`` that activates the predecessor protocol with version number ``XXX`` and short hash ````. In our example, the @@ -543,10 +543,10 @@ unchanged, and every time we want to run the test, we will copy its contents to a fresh test folder. In our example, we can do this by taking advantage of an environment variable ``test-directory`` and the tool ``mktemp`` as follows:: - $ test_directory=$(mktemp -d -t "tezos-node-mainnet-XXXX") && cp -r "/tmp/tezos-node-mainnet/." "$test_directory" + $ test_directory=$(mktemp -d -t "octez-node-mainnet-XXXX") && cp -r "/tmp/octez-node-mainnet/." "$test_directory" This command creates a fresh test folder in the system's temp directory (in our -example ``/tmp``) whose name is ``tezos-node-mainnet-XXXX``, +example ``/tmp``) whose name is ``octez-node-mainnet-XXXX``, where the ``XXXX`` are four random alphanumerical characters, and sets the environment variable ``test-directory`` to the path of the test folder, such that we can run the node in the test folder later. Then it copies the contents @@ -593,7 +593,7 @@ can do this with the following command:: Then we repeat the commands above in order to create a fresh test folder, and to copy the context of the original folder into the test folder. In our example:: - $ test_directory=$(mktemp -d -t "tezos-node-mainnet-XXXX") && cp -r "/tmp/tezos-node-mainnet/." "$test_directory" + $ test_directory=$(mktemp -d -t "octez-node-mainnet-XXXX") && cp -r "/tmp/octez-node-mainnet/." "$test_directory" Now we run the node in the test folder by invoking:: @@ -713,13 +713,13 @@ invoking the following eight commands):: $ ./scripts/user_activated_upgrade.sh src/proto_012_* 1617344 $ ./scripts/patch-yes_node.sh $ make - $ ./octez-node snapshot import ~/mainnet.rolling --data-dir /tmp/tezos-node-mainnet - $ ./octez-node identity generate --data-dir /tmp/tezos-node-mainnet - $ dune exec devtools/yes_wallet/yes_wallet.exe -- create from context /tmp/tezos-node-mainnet in /tmp/yes-wallet --active-bakers-only + $ ./octez-node snapshot import ~/mainnet.rolling --data-dir /tmp/octez-node-mainnet + $ ./octez-node identity generate --data-dir /tmp/octez-node-mainnet + $ dune exec devtools/yes_wallet/yes_wallet.exe -- create from context /tmp/octez-node-mainnet in /tmp/yes-wallet --active-bakers-only Copy original folder into test folder:: - $ test_directory=$(mktemp -d -t "tezos-node-mainnet-XXXX") && cp -r "/tmp/tezos-node-mainnet/." "$test_directory" + $ test_directory=$(mktemp -d -t "octez-node-mainnet-XXXX") && cp -r "/tmp/octez-node-mainnet/." "$test_directory" Run the node`:: @@ -749,7 +749,7 @@ test folder, and by removing files ``/tmp/yes-wallet/wallet_lock`` and ``/tmp/yes-wallet/blocks``:: $ rm -rf "$test_directory" && rm -f /tmp/yes-wallet/{blocks,wallet_lock}; - $ test_directory=$(mktemp -d -t "tezos-node-mainnet-XXXX") && cp -r "/tmp/tezos-node-mainnet/." "$test_directory" + $ test_directory=$(mktemp -d -t "octez-node-mainnet-XXXX") && cp -r "/tmp/octez-node-mainnet/." "$test_directory" Run the node:: @@ -854,14 +854,14 @@ that the option ``-v`` is not required when specifying a log file). Each time the automatic test is run, Tezt creates a temporary folder under the system's temp directory with name ``tezt-XXXXXX``, where the ``XXXXXX`` are six random decimal figures. The content of the original context folder is copied on -the fly in the test folder ``tezt-XXXXXX/tezos-node-test``, and a yes-wallet +the fly in the test folder ``tezt-XXXXXX/octez-node-test``, and a yes-wallet folder is created on the fly in ``tezt-XXXXXX/yes-wallet``. The option ``--keep-temp`` in the command above keeps the temporary folder for the developer to be able to inspect the storage after the migration has been performed. Assume the temporary folder in our example is ``/tmp/tezt-526039``, the developer can start the node with the migrated context by invoking:: - $ ./octez-node run --synchronisation-threshold 0 --connections 0 --data-dir /tmp/tezt-526039/tezos-node-test --rpc-addr localhost & + $ ./octez-node run --synchronisation-threshold 0 --connections 0 --data-dir /tmp/tezt-526039/octez-node-test --rpc-addr localhost & Once the node is up, it is possible to inspect the storage by using the Tezos client and/or the RPCs. New blocks can be baked with any of the accounts @@ -912,7 +912,7 @@ Run the migration test:: Run the resulting node (assuming temp folder ``/tmp/tezt-526039``):: - $ ./octez-node run --synchronisation-threshold 0 --connections 0 --data-dir /tmp/tezt-526039/tezos-node-test --rpc-addr localhost & + $ ./octez-node run --synchronisation-threshold 0 --connections 0 --data-dir /tmp/tezt-526039/octez-node-test --rpc-addr localhost & Use the client, to manually inspect the storage, or for example to bake new blocks with the following command:: @@ -922,7 +922,7 @@ blocks with the following command:: To test again, kill the node:: $ fg - ./octez-node run --synchronisation-threshold 0 --connections 0 --data-dir /tmp/tezt-526039/tezos-node-test --rpc-addr localhost + ./octez-node run --synchronisation-threshold 0 --connections 0 --data-dir /tmp/tezt-526039/octez-node-test --rpc-addr localhost ^C And run the migration test:: diff --git a/docs/developer/testing.rst b/docs/developer/testing.rst index efe91da8479f..d028c2d941ba 100644 --- a/docs/developer/testing.rst +++ b/docs/developer/testing.rst @@ -173,8 +173,8 @@ Python testing and execution framework ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The Tezos project uses `pytest `_, a Python testing -framework, combined with :doc:`tezos-launchers `, a Python wrapper -``octez-node`` and ``octez-client``, to perform integration testing +framework, combined with :doc:`a Python wrapper ` +around ``octez-node`` and ``octez-client``, to perform integration testing of the node, the client, networks of nodes and daemons such as the baker and endorser. diff --git a/docs/introduction/howtoget.rst b/docs/introduction/howtoget.rst index e2fa5df66d2b..9a0cf87f4d44 100644 --- a/docs/introduction/howtoget.rst +++ b/docs/introduction/howtoget.rst @@ -164,16 +164,16 @@ the Alpha protocol. You can open a new shell session and run ``docker ps`` in it, to display all the available containers, e.g.:: - 8f3638fae48c docker.io/tezos/tezos:latest tezos-node 3 minutes ago Up 3 minutes ago 0.0.0.0:8732->8732/tcp, 0.0.0.0:9732->9732/tcp node-alpha - 8ba4d6077e2d docker.io/tezos/tezos:latest tezos-baker --liq... 3 minutes ago Up 31 seconds ago baker-alpha - 3ee7fcbc2158 docker.io/tezos/tezos:latest tezos-accuser 3 minutes ago Up 35 seconds ago accuser-alpha + 8f3638fae48c docker.io/tezos/tezos:latest octez-node 3 minutes ago Up 3 minutes ago 0.0.0.0:8732->8732/tcp, 0.0.0.0:9732->9732/tcp node-alpha + 8ba4d6077e2d docker.io/tezos/tezos:latest octez-baker --liq... 3 minutes ago Up 31 seconds ago baker-alpha + 3ee7fcbc2158 docker.io/tezos/tezos:latest octez-accuser 3 minutes ago Up 35 seconds ago accuser-alpha -The node's RPC interface will be available on localhost and can be queried with ``tezos-client``. +The node's RPC interface will be available on localhost and can be queried with ``octez-client``. :: - docker exec node-alpha tezos-client rpc list + docker exec node-alpha octez-client rpc list Building Docker Images Locally ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -310,7 +310,7 @@ of variable ``$ocaml_version`` in file ``scripts/version.sh``). To get an enviro The command ``eval $(opam env)`` sets up required environment variables. OPAM will suggest to add it in your rc file. If, at any - point, you get an error like ``tezos-something: command not + point, you get an error like ``octez-something: command not found``, first thing to try is to (re)run ``eval $(opam env --switch $ocaml_version)`` (replace ``$ocaml_version`` with its value in ``scripts/version.sh``) to see if it fixes the problem. diff --git a/docs/introduction/howtorun.rst b/docs/introduction/howtorun.rst index 315dea10cb23..afd4d8b784f5 100644 --- a/docs/introduction/howtorun.rst +++ b/docs/introduction/howtorun.rst @@ -221,14 +221,14 @@ If you are running the baker Docker image, you can watch the baker logs with docker ps If your container is running, its name will appear in the last column. -For instance, if the name is ``mainnet_baker-014-PtKathma``, you can +For instance, if the name is ``mainnet_baker-PtKathma``, you can view recent logs with:: - docker logs mainnet_baker-014-PtKathma + docker logs mainnet_baker-PtKathma If you want to keep watching logs, use ``-f``:: - docker logs mainnet_baker-014-PtKathma -f + docker logs mainnet_baker-PtKathma -f This allows you to know if you baked. You should see lines such as:: diff --git a/docs/introduction/howtouse.rst b/docs/introduction/howtouse.rst index 794cb6c234d4..106881d3ec2e 100644 --- a/docs/introduction/howtouse.rst +++ b/docs/introduction/howtouse.rst @@ -29,7 +29,7 @@ After a successful compilation, you should have the following binaries: The daemons other than the node are suffixed with the name of the protocol they are bound to, and up to some version, also by its number. -For instance, ``octez-baker-014-PtKathma`` is the baker +For instance, ``octez-baker-PtKathma`` is the baker for the Kathmandu protocol, and ``octez-baker-alpha`` is the baker of the development protocol. The ``octez-node`` daemon is not suffixed by any protocol name, because it is independent of the economic protocol. See also the `Node's Protocol`_ section below. @@ -38,7 +38,7 @@ The ``octez-node`` daemon is not suffixed by any protocol name, because it is in Read The Manual --------------- -All the Tezos binaries provide the ``--help`` option to display information about their usage, including the available options and the possible parameters. +All the Octez binaries provide the ``--help`` option to display information about their usage, including the available options and the possible parameters. Additionally, most of the above binaries (i.e., all but the node, the validator, and the compiler) provide a textual manual that can be obtained with the command ``man``, whose verbosity can be increased with ``-v``, for example:: @@ -71,7 +71,7 @@ To see the usage of one specific command, you may also type the command without Usage: [...] -.. _tezos_client_protocol: +.. _octez_client_protocol: To get the manual of a client command for a protocol other than that used by the node (or even when not connected to a node), use the option ``--protocol``, e.g.:: @@ -81,7 +81,7 @@ Note that you can get the list of protocols known to the client with:: octez-client list understood protocols -The full command line documentation of the Tezos binaries supporting the ``man`` command is also available +The full command line documentation of the Octez binaries supporting the ``man`` command is also available online: :doc:`../shell/cli-commands`. Node @@ -248,7 +248,7 @@ Putting together all the above instructions, you may want to run a node as follo Client ------ -Tezos client can be used to interact with the node, it can query its +Octez client can be used to interact with the node, it can query its status or ask the node to perform some actions. For example, after starting your node you can check if it has finished synchronizing (see :doc:`../shell/sync`) using:: diff --git a/docs/introduction/install-opam.sh b/docs/introduction/install-opam.sh index 007e5100492d..48967f6f156d 100755 --- a/docs/introduction/install-opam.sh +++ b/docs/introduction/install-opam.sh @@ -28,6 +28,6 @@ eval $(opam env) # depext handling is done directly by opam 2.1 and later opam depext tezos # [install tezos] -opam install tezos +opam install octez # [test executables] -tezos-client --version +octez-client --version diff --git a/docs/kathmandu/cli-commands.rst b/docs/kathmandu/cli-commands.rst index 95e17d8a1c1a..b61a23e2882b 100644 --- a/docs/kathmandu/cli-commands.rst +++ b/docs/kathmandu/cli-commands.rst @@ -3,8 +3,8 @@ Command Line Interface ********************** This document is a prettier output of the documentation produced by -the command ``man`` of the different Tezos binaries. You can obtain similar pages -using shell commands such as (:ref:`indicating the appropriate protocol `): +the command ``man`` of the different Octez binaries. You can obtain similar pages +using shell commands such as (:ref:`indicating the appropriate protocol `): :: diff --git a/docs/kathmandu/sapling.rst b/docs/kathmandu/sapling.rst index 92a7d08a461d..b7c0e475c80c 100644 --- a/docs/kathmandu/sapling.rst +++ b/docs/kathmandu/sapling.rst @@ -485,7 +485,7 @@ unshielding. # set up the sandbox ./src/bin_node/octez-sandboxed-node.sh 1 --connections 0 & eval `./src/bin_client/octez-init-sandboxed-client.sh 1` - tezos-activate-alpha + octez-activate-alpha # originate the contract with its initial empty sapling storage, # bake a block to include it. diff --git a/docs/kathmandu/transaction_rollups.rst b/docs/kathmandu/transaction_rollups.rst index 4cf39120e02b..b83751302797 100644 --- a/docs/kathmandu/transaction_rollups.rst +++ b/docs/kathmandu/transaction_rollups.rst @@ -593,7 +593,7 @@ rollup node is to prepare its configuration file. .. code:: sh - tezos-tx-rollup-node-014-PtKathma init ${mode} config \ + octez-tx-rollup-node-PtKathma init ${mode} config \ for ${tx_rollup_address_or_name} \ --data-dir ${data_dir} \ --rpc-addr ${rpc_address} \ @@ -664,7 +664,7 @@ For instance, .. code:: sh - tezos-tx-rollup-node-014-PtKathma init batcher config for ${rollup} \ + octez-tx-rollup-node-PtKathma init batcher config for ${rollup} \ --data-dir /tmp/tx-node \ --rpc-addr ${rollup_node_rpc_server_address} \ --batch-signer ${batcher} @@ -680,7 +680,7 @@ Once the configuration is ready, starting the rollup node is as simple as .. code:: sh - tezos-tx-rollup-node-014-PtKathma --endpoint ${tezos_node_address} \ + octez-tx-rollup-node-PtKathma --endpoint ${tezos_node_address} \ run ${mode} for ${rollup_address_or_name} \ --data-dir ${data_dir} \ [--allow-deposit] @@ -819,7 +819,7 @@ the ``get balance`` command can be used. .. code:: sh - tezos-tx-rollup-client-014-PtKathma get balance for alice of ${ticket_hash} + octez-tx-rollup-client-PtKathma get balance for alice of ${ticket_hash} .. note:: @@ -830,7 +830,7 @@ To transfer a ticket to another address on the layer-2, the .. code:: sh - tezos-tx-rollup-client-014-PtKathma transfer ${qty} \ + octez-tx-rollup-client-PtKathma transfer ${qty} \ of ${ticket_hash} \ from ${src} to ${dst} \ [--endpoint ${tx_rollup_node_address}] @@ -848,7 +848,7 @@ block, one can use the following command. .. code:: sh - tezos-tx-rollup-client-014-PtKathma get block ${block_id} + octez-tx-rollup-client-PtKathma get block ${block_id} where ``block_id`` can either be ``head`` (the latest rollup block), a level (0, 1, etc.), or a Tezos block hash. @@ -858,7 +858,7 @@ rollup, and to inject it back in the layer-1. .. code:: sh - tezos-tx-rollup-client-014-PtKathma withdraw ${qty} of ${ticket_hash} from ${l2_src} to ${l1_dst} + octez-tx-rollup-client-PtKathma withdraw ${qty} of ${ticket_hash} from ${l2_src} to ${l1_dst} Similarly to the ``transfer`` command, ``l2_src`` has to be an alias to a BLS pair of keys, while ``l1_dst`` can either be an alias or an @@ -890,7 +890,7 @@ To retrieve the values of ``micheline_contents``, ``ty`` and .. code:: sh - tezos-tx-rollup-client-014-PtKathma rpc get "/context/head/tickets/${ticket_hash}" + octez-tx-rollup-client-PtKathma rpc get "/context/head/tickets/${ticket_hash}" Besides, the entrypoint ``ep`` of ``sc_dst`` needs to expect a ``ticket ty`` as its input. diff --git a/docs/lima/cli-commands.rst b/docs/lima/cli-commands.rst index cef4283180f9..05324e738cf2 100644 --- a/docs/lima/cli-commands.rst +++ b/docs/lima/cli-commands.rst @@ -3,8 +3,8 @@ Command Line Interface ********************** This document is a prettier output of the documentation produced by -the command ``man`` of the different Tezos binaries. You can obtain similar pages -using shell commands such as (:ref:`indicating the appropriate protocol `): +the command ``man`` of the different Octez binaries. You can obtain similar pages +using shell commands such as (:ref:`indicating the appropriate protocol `): :: diff --git a/docs/lima/sapling.rst b/docs/lima/sapling.rst index ddc03c08927d..0cbf62103edc 100644 --- a/docs/lima/sapling.rst +++ b/docs/lima/sapling.rst @@ -485,7 +485,7 @@ unshielding. # set up the sandbox ./src/bin_node/octez-sandboxed-node.sh 1 --connections 0 & eval `./src/bin_client/octez-init-sandboxed-client.sh 1` - tezos-activate-alpha + octez-activate-alpha # originate the contract with its initial empty sapling storage, # bake a block to include it. diff --git a/docs/lima/transaction_rollups.rst b/docs/lima/transaction_rollups.rst index c09276365d12..a1c1abdbc26e 100644 --- a/docs/lima/transaction_rollups.rst +++ b/docs/lima/transaction_rollups.rst @@ -598,7 +598,7 @@ rollup node is to prepare its configuration file. .. code:: sh - tezos-tx-rollup-node-alpha init ${mode} config \ + octez-tx-rollup-node-alpha init ${mode} config \ for ${tx_rollup_address_or_name} \ --data-dir ${data_dir} \ --rpc-addr ${rpc_address} \ @@ -669,7 +669,7 @@ For instance, .. code:: sh - tezos-tx-rollup-node-alpha init batcher config for ${rollup} \ + octez-tx-rollup-node-alpha init batcher config for ${rollup} \ --data-dir /tmp/tx-node \ --rpc-addr ${rollup_node_rpc_server_address} \ --batch-signer ${batcher} @@ -685,7 +685,7 @@ Once the configuration is ready, starting the rollup node is as simple as .. code:: sh - tezos-tx-rollup-node-alpha --endpoint ${tezos_node_address} \ + octez-tx-rollup-node-alpha --endpoint ${tezos_node_address} \ run ${mode} for ${rollup_address_or_name} \ --data-dir ${data_dir} \ [--allow-deposit] @@ -825,7 +825,7 @@ the ``get balance`` command can be used. .. code:: sh - tezos-tx-rollup-client-alpha get balance for alice of ${ticket_hash} + octez-tx-rollup-client-alpha get balance for alice of ${ticket_hash} .. note:: @@ -836,7 +836,7 @@ To transfer a ticket to another address on the layer-2, the .. code:: sh - tezos-tx-rollup-client-alpha transfer ${qty} \ + octez-tx-rollup-client-alpha transfer ${qty} \ of ${ticket_hash} \ from ${src} to ${dst} \ [--endpoint ${tx_rollup_node_address}] @@ -854,7 +854,7 @@ block, one can use the following command. .. code:: sh - tezos-tx-rollup-client-alpha get block ${block_id} + octez-tx-rollup-client-alpha get block ${block_id} where ``block_id`` can either be ``head`` (the latest rollup block), a level (0, 1, etc.), or a Tezos block hash. @@ -864,7 +864,7 @@ rollup, and to inject it back in the layer-1. .. code:: sh - tezos-tx-rollup-client-alpha withdraw ${qty} of ${ticket_hash} from ${l2_src} to ${l1_dst} + octez-tx-rollup-client-alpha withdraw ${qty} of ${ticket_hash} from ${l2_src} to ${l1_dst} Similarly to the ``transfer`` command, ``l2_src`` has to be an alias to a BLS pair of keys, while ``l1_dst`` can either be an alias or an @@ -896,7 +896,7 @@ To retrieve the values of ``micheline_contents``, ``ty`` and .. code:: sh - tezos-tx-rollup-client-alpha rpc get "/context/head/tickets/${ticket_hash}" + octez-tx-rollup-client-alpha rpc get "/context/head/tickets/${ticket_hash}" Besides, the entrypoint ``ep`` of ``sc_dst`` needs to expect a ``ticket ty`` as its input. diff --git a/docs/protocols/tenderbake.rst b/docs/protocols/tenderbake.rst index 66f42092440c..39a24c32e713 100644 --- a/docs/protocols/tenderbake.rst +++ b/docs/protocols/tenderbake.rst @@ -275,19 +275,19 @@ The baker daemon takes the same options as in Hangzhou. Client ------ -The command ``tezos-client bake for`` has been changed: +The command ``octez-client bake for`` has been changed: - It takes a (possibly empty) list of delegate references. It then bakes a block and (pre)endorses this block, using the rights of all the specified delegates. When the list is empty is does so for all delegates whose secret keys are known. - It performs a full consensus round: it "proposes" a block (that is, it injects a block candidate), it preendorses the block, and it endorses the block, if possible. The following commands have been added: -- ``tezos-client propose for``: forge and inject a candidate block (a `proposal`). +- ``octez-client propose for``: forge and inject a candidate block (a `proposal`). -- ``tezos-client preendorse for``: forge and inject a preendorsement operation. +- ``octez-client preendorse for``: forge and inject a preendorsement operation. -- ``tezos-client endorse for``: forge and inject an endorsement operation. +- ``octez-client endorse for``: forge and inject an endorsement operation. -- ``tezos-client set deposits limit for to ``: sets the deposits limit for a registered delegate. +- ``octez-client set deposits limit for to ``: sets the deposits limit for a registered delegate. -- ``tezos-client unset deposits limit for ``: remove the deposits limit of a registered delegate. +- ``octez-client unset deposits limit for ``: remove the deposits limit of a registered delegate. diff --git a/docs/releases/version-11.rst b/docs/releases/version-11.rst index bf6aa99209c2..6ab8e82755ea 100644 --- a/docs/releases/version-11.rst +++ b/docs/releases/version-11.rst @@ -31,7 +31,7 @@ To update from sources:: If you are using Docker instead, use the ``v11.1`` Docker images of Tezos. -If you are installing Octez using Opam, note that the required +If you are installing Tezos using Opam, note that the required OCaml version is now 4.12.1. This means that you need to create a new switch with ``opam switch create 4.12.1`` before you run ``opam install tezos``. diff --git a/docs/user/key-management.rst b/docs/user/key-management.rst index 8c309f5e3dac..7fcad5e88af8 100644 --- a/docs/user/key-management.rst +++ b/docs/user/key-management.rst @@ -163,7 +163,7 @@ In our home server we can generate a new key pair (or import one from a :ref:`Ledger`) and launch a signer that signs operations using these keys. To select the ``tcp`` signing scheme, one has to launch ``octez-signer`` with the ``socket`` argument, as shown below. -The new keys are stored by the signer in ``$HOME/.tezos-signer`` in the same format +The new keys are stored by the signer in ``$HOME/.octez-signer`` in the same format as ``octez-client``. On our internet-facing virtual private server, called "vps" here, we can then import a key with the address of the signer. @@ -171,7 +171,7 @@ of the signer. :: home~$ octez-signer gen keys alice - home~$ cat ~/.tezos-signer/public_key_hashs + home~$ cat ~/.octez-signer/public_key_hashs [ { "name": "alice", "value": "tz1abc..." } ] home~$ octez-signer launch socket signer -a home @@ -238,7 +238,7 @@ client to authenticate before signing any operation. First we create a new key on the *vps* and then import it as an authorized key on *home* where it is stored under -``.tezos-signer/authorized_keys`` (similarly to ``ssh``). +``.octez-signer/authorized_keys`` (similarly to ``ssh``). Note that this key is only used to authenticate the client to the signer and it is not used as a Tezos account. diff --git a/docs/user/light.rst b/docs/user/light.rst index f42dda6af5d4..1daef4d64255 100644 --- a/docs/user/light.rst +++ b/docs/user/light.rst @@ -104,7 +104,7 @@ Then upgrade the node to protocol alpha: :: - $ tezos-activate-alpha # Triggers output in terminal of first node + $ octez-activate-alpha # Triggers output in terminal of first node $ octez-client bake for bootstrap1 # Triggers output in terminal of first node To avoid warnings being printed in upcoming commands (optional): diff --git a/docs/user/logging.rst b/docs/user/logging.rst index 1ab6993d42b5..3c3155b91f08 100644 --- a/docs/user/logging.rst +++ b/docs/user/logging.rst @@ -203,7 +203,7 @@ Environment Variables The logging framework can be configured with environment variables before starting the node. Those variables work on all the code using the ``tezos-stdlib-unix`` library as long as ``Internal_event_unix.init`` is -called; this should include *all* the regular ``tezos-*`` binaries. +called; this should include *all* the regular ``octez-*`` binaries. - ``TEZOS_EVENTS_CONFIG`` must be a whitespace-separated list of URIs: diff --git a/docs/user/proxy-server.rst b/docs/user/proxy-server.rst index 1ba8043d7430..f9660ccb7753 100644 --- a/docs/user/proxy-server.rst +++ b/docs/user/proxy-server.rst @@ -78,7 +78,7 @@ Then upgrade the node to protocol alpha: :: - $ tezos-activate-alpha + $ octez-activate-alpha $ octez-client bake for bootstrap1 To avoid warnings being printed in upcoming commands (optional): -- GitLab