Projects | Chevdor's Blog

PRDoc

Thu, 17 Aug 2023 15:52:12 +0000

prdoc is a tool designed to help generating, checking and loading .prdoc files. .prdoc files are YAML files adhering to defined JSON schema and helping with code change documentation.

It allows structuring the documentation per project, checking contributions for adherence to the structure, validating the content, and generating better quality release notes.

It is used by the Polkadot-sdk repository.

1. Features

Generate Documentation: Automatically generate documentation files based on your project’s codebase.
Check Documentation: Validate existing documentation files against a predefined JSON schema to ensure consistency and correctness.
Load Documentation: Easily load and parse .prdoc files for use in your projects.

Install with cargo

cargo install prdoc

More on the project can be found on the GitHub repository.

subrpc

Wed, 30 Nov 2022 15:52:12 +0000

Ever experienced issues with a RPC endpoint and needed to find an alternate one ? Did you favorite RPC endpoints provider just went down ? What now ?

subrpc is a tool designed to help users manage their RPC endpoints on the Polkadot network. Managing your list of JSON RPC endpoints and picking the best endpoint for YOU can be challenging.

subrpc can tap into mutiple repositories of known endpoints and helps you query them, filter them and pick the best one for you. Those repositories can be maintained by you, your company, the community, the RPC endpoint providers, or a mix of all of that. subrpc also helps with sharing private RPC endpoints.

Depending on your beliefs and preferences, you may also esclude some endpoints or providers from your list.

Visit the subrpc GitHub repository for more information and to get started with subrpc.

cargo-crate

Mon, 30 May 2022 15:52:12 +0000

In a nutshell cargo-crate allows:

search for crates passing a pattern
fetching information about one or several crates, including the owners
opening crate(s) in crates.io
opening crates' documentation directly
opening crates' repository directly
opening crates' homepage directly

Visit the cargo-crate GitHub repository for more information and to get started with cargo-crate.

tera-cli

Sat, 01 May 2021 15:52:12 +0000

tera-cli is a very fast command line utility written in Rust to process data via tera templates. It is especially useful to generate text, markdown or HTML to render raw data from json or yaml. It also supports loading data from files, stdin or the user’s ENV.

tera-cli is used internally by srtool and offers a great option to render prdoc data.

More on the project can be found on the GitHub repository.

Minikube Proxy

Tue, 09 Feb 2021 15:52:12 +0000

As featured in this article, the Minikube proxy allows reaching a Kubernetes minikube Api Server remotely.

You can find the project at: https://gitlab.com/chevdor/docker-nginx-minuke-proxy

Subwasm

Tue, 09 Feb 2021 15:52:12 +0000

subwasm is an essential utility for Substrate developers and users. It allows inspecting any Substrate WASM runttime. A WASM Blob is by nature not very readable. Prior the development of subwasm, a running node was required to inspect a runtime.

subwasm voids this requirements. It is a Rust utility that allows inspecting a Substrate WASM runtime without having to run a node. It can be used to extract metadata, call some of the functions, and inspect the storage of a Substrate runtime and would not even require an internet connection (assuming you already have a runtime locally).

subwasm is used within srtool to extract metadata from a runtime that was just built.

subwasm allows knowing exaxctly the content of a runtime without the need to run a node. It is a great tool for users and for automation.

You may install subwasm using homebrew or cargo or build it yourself:

Homebrew

brew tap chevdor/subwasm https://github.com/chevdor/subwasm
brew install subwasm

Cargo

cargo install --locked --git https://github.com/chevdor/subwasm

You may then use it to inspect a runtime. subwasm can also fetch a runtime from a chain. Wondering what is the current runtime version ?

subwasm version --chain dot

will fetch the metadata of the Polkadot runtime, then show you the runtime version:

specifications : polkadot v1003004
implementation : parity-polkadot v0
transaction    : v26
authoring      : v0

You can find the project at: https://github.com/chevdor/subwasm and see how to list pallets, query the details of a specific pallet, retrieve the entire metadata in various formats and much more.

srtool

Thu, 05 Mar 2020 15:52:12 +0000

srtool is a collection of dockerized tools helping with Substrate & Polkadot Runtime development.

It especially helps with building and verifying WASM Runtime Blobs. You may read more about it here.

The Docker image is chevdor/srtool. You can find it at https://hub.docker.com/r/chevdor/srtool.

1. Install

1.1. Pull image

    docker pull chevdor/srtool:<version> # (1)

where <version> is the rustc version you want to use.

…or just skip that step, the right image will be fetched at first run.

1.2. Using an alias

Creating an alias helps hiding the docker complexity behind one simple command. We will see more powerful options but this one is simple enough.

    export RUSTC_VERSION=nightly-2020-03-12; export PACKAGE=kusama-runtime; alias srtool='docker run --rm -it -e PACKAGE=$PACKAGE -v $PWD:/build -v /tmp/cargo:/cargo-home chevdor/srtool:$RUSTC_VERSION'

Note	Note that defining the alias as done above will hardcode the runtime. Using `kusama-runtime` as show above means you will always check the kusama runtime. If you need more, check the next chapter.

Note	If you want to check what your alias is, use `type srtool`

The command to invoke a build will then be srtool build.

1.3. Power users

If you want flexibility, using a function is slightly more complex but more flexible.

If you already defined an alias (you can check with type srtool), you should first unset it with unlias srtool.

Note	You cannot use both an alias and a function but you could make a function called fsrtool for instance for the function…

1.3.1. Hardcoded compiler version

This option should be enough most of the time.

    function srtool() { docker run --rm -it -e PACKAGE=$1 -v $PWD:/build -v /tmp/cargo:/cargo-home chevdor/srtool:nightly-2020-03-12 $2; }

The commands to use srtool are then:

    srtool kusama-runtime build

Note	The <kusama-runtime> keyword above specifies we will check the kusama runtime. If your runtime is called xyz-runtime, swap accordingly.

1.3.2. Parametric compiler version

Using this version is more powerful if you know what you are doing but also requires more typing.

    function srtool() { docker run --rm -it -e PACKAGE=$1 -v $PWD:/build -v /tmp/cargo:/cargo-home chevdor/srtool:$2 $3; }

The command to invoke a build will then be srtool <package> <rust_version> build. For instance:

    srtool my-super-runtime nightly-2020-03-12 build
    srtool polkadot-runtime nightly-2019-12-05 build

WRNING: The second example is only there to illustrate how it works. If you try it today, it will likely not work as I did not build a container for this version yet.

You likely want to make this persistent with:

    echo "export RUSTC_VERSION=nightly-2020-03-12; export PACKAGE=polkadot-runtime; alias srtool='docker run --rm -it -e PACKAGE=$PACKAGE -v $PWD:/build -v /tmp/cargo:/cargo-home chevdor/srtool:$RUSTC_VERSION'" >> ~/.bash_profile && source ~/.bash_profile

If you wish to see more (it takes a little longer), you may set the VERBOSE ENV variable:

    export RUSTC_VERSION=nightly-2020-03-12; export PACKAGE=polkadot-runtime; alias srtool='docker run --rm -it -e PACKAGE=$PACKAGE -e VERBOSE=1 -v $PWD:/build -v /tmp/cargo:/cargo-home chevdor/srtool:$RUSTC_VERSION'

Note	The part `-v /tmp/cargo:/cargo-home` exposes the docker container’s cargo cache on your local machine. This helps making subsequent builds faster.

2. Use

Now that you defined the srtool alias, you can use it as shown below:

See the help

srtool help

Build the runtime

srtool build

Typical run

Invoking srtool build with:

srtool build

Will output something that looks like this:

    🧰 Substrate Runtime Toolbox 🧰
    🏗  Building polkadot-runtime as release
    ⏳ That can take a little while, be patient... Subsequent builds will be faster.
        Finished release [optimized] target(s) in 37.43s

    real	0m37.931s
    user	0m1.560s
    sys	0m3.220s
    ✨ Your Substrate WASM Runtime is ready! ✨
    Summary:
    Used rustc nightly-2020-03-12 (4560ea788 2019-11-04)
    Wasm     : ./srtool/release/wbuild/polkadot-runtime/polkadot_runtime.compact.wasm
    Content  : 0x0061736d0100000001a4022b60037f7f...3435663020323031392d31322d303429
    Size     : 1.1M
    Proposal : 0x5931690e71e9d3d9f04a43d8c15e45e0968e563858dd87ad6485b2368a286a8f
    SHA256   : d5930520676994fc55a29c547f0159ea860cb46edd710a5be35e62565af1ad8b

JSON output

If you prefer a json output, srtool has you covered:

$ srtool build --json

Will give you such an output:

{
  "gen": "srtool",
  "rustc": "rustc 1.41.0-nightly (ae1b871cc 2019-12-06)",
  "wasm": "./target/srtool/release/wbuild/kusama-runtime/kusama_runtime.compact.wasm",
  "size": "1205052",
  "pkg": "kusama-runtime",
  "prop": "0x5931690e71e9d3d9f04a43d8c15e45e0968e563858dd87ad6485b2368a286a8f",
  "sha256": "d93126c814f8366b651e425e34390212a98f8e77a8b73f9e1d2b07fc229a25f1",
  "tmsp": "2020-01-14T10:15:28Z"
}

3. Proposal field

What is important in the output of srtool is the Proposal field:

    🧰 Substrate Runtime Toolbox 🧰
    ... Bla bla ...
    Proposal : 0x5931690e71e9d3d9f04a43d8c15e45e0968e563858dd87ad6485b2368a286a8f
    ... more blabla ...

The Proposal field value should should match the value of the proposal you can see in the Polkadot UI.

Advanced usage

if you feel fancy, you may also:

srtool bash

and look around the /srtool folder

4. Build the Docker image

While you don’t have to build the image yourself, you still may!

First you may want to double check what rustc versions are available as you will HAVE to build an image for a given version:

rustup check

So say you want to build a builder for rustc nightly-2020-03-12:

    RUSTC_VERSION=nightly-2020-03-12 && docker build --build-arg RUSTC_VERSION=$RUSTC_VERSION -t chevdor/srtool:$RUSTC_VERSION .

confmgr

Thu, 05 Mar 2020 15:52:12 +0600

Why another one?

confmgr brings interesting features that are not available in libs. While focusing on ease of use, it brings features that no longer need to be part of your app such as:

Features at a glance

type conversion (variables from ENV are always strings, confmgr converts them for you)
mandatory values: If you miss a value, confmgr will tell you before your app explodes…
default values: confmrg handles default values for you
regular expressions: confmgr allows you defining a regexp that will allow checking the validity of the loaded config
masked variables: handy for your secrets, read below

Helper functions

After getting your config object with GetConfig(), you can simple use it with config['MYAPP_MYMODULE_VAR1'] or use some of the helper methods attached to your config.

confmgr brings a set of handy methods such as Print() that will display the content of your config while ensuring that your secrets do NOT show up in any log or output.

Printing your config may use colors or not. Here is an example with color coming from running config.Print():

===> TS_SAMPLE_MODULE_01 ENV:
✅ PARAM1: some param1
    value: 12
✅ PARAM2: some param2
    value: 44
✅ SECRET: some secret
    value: *****                                <---- Notice how this value has been masked
✅ REGEXP: some regexp
    regexp: ^\d{2}_\d{2}
    value: 68_77
✅ MANDAT_WITH_DEF: some optional param
    value: 42
❌ MANDAT_NO_DEF: some optional param           <----- It looks like we forgot to pass a value
    value: undefined

Note	If you are using a custom logger, you may also pass it to the `Print()` method so the output gets nicely integrated to your logs while NOT revealing any of your secrets.

You can read more about it at https://gitlab.com/chevdor/confmgr

substrate-runtime-hasher

Thu, 05 Mar 2020 15:52:12 +0600

Registrar #1

Sat, 21 Dec 2019 15:52:12 +0600

Before the introduction of srtool in 2020, there was no way for anyone to verify that a new WASM Runtime proposed on-chain was really built using a given version of the code. Back then, governance did rely on trust based on the submitter. This is however assuming that you can identify and trust who is behind a given account.

Any user can set any identity on any account so relying on the sole identity was clearly not enough.

Registrar #1 was introduced to verify the identity of users requesting it. It set the standard for how identities can be verified and many if not all the subsequent registrars kept on following a very similar process, if not exactly the same.

Over the time, the Registrar #1 started operating on other (para)chains, bringing the list to:

Westend
Kusama
Polkadot
Moonbeam
Moonriver

You can find the registrar page at https://registrar.d11d.net/ and you may read more about it here.

Polkabot

Tue, 08 Oct 2019 14:51:12 +0600

Polkadot is a platform that allows diverse blockchains to transfer messages, including value, in a trust-free fashion; sharing their unique features while pooling their security. In brief, Polkadot is a scalable, heterogeneous, multi-chain technology.

Monitoring the Polkadot network can mean either staring at charts the whole day until something happens…

…or asking PolkaBot to take care of the watching. It doesn’t sleep!

#Polkabot has been launched today. Its job is to monitor the @polkadotnetwork and alert when interesting events occur.

You can see it in action in the following @matrixdotorg
room using @RiotChat
: https://t.co/hAvsYCOjXw #Blockchain #polkadot @web3foundation pic.twitter.com/zpsLATNjtk
— Chevdor (@chevdor) August 29, 2018

Polkadot - what’s it good for?

The Polkadot network is dynamic in that it can be upgraded via on-chain governance, while operators of the network can be added or removed according to their behavior. Thus participants of the network need to monitor how the network is performing and adjust accordingly. Polkabot helps with this by keeping participants in the network informed, providing updates on new governance proposals and network stalls.

The Polkadot network is based on Proof Of Stake (PoS), which requires the network’s validators (or miners) to verify transactions and be online 24 hours a day with no downtime.

If a validator runs properly, the network rewards that account with DOTs, the native token of the Polkadot platform. If a validator does not run properly (or not at all), it will get slashed, losing some or all of the DOTs at stake. A validator may even be kicked out of the validators pool.

Another innovative aspect of Polkadot is its on-chain governance system for upgrading the Polkadot software. Unlike many of the currently existing blockchains, the code defining the rules of the Polkadot network (or runtime) is not stored into the program you download and install on your computer. Instead, the runtime is stored in the blockchain itself.

Modifying this code is possible only after enough users agree to the change. Upgrades to the runtime does not require users to install new software to their clients, but instead is similar to existing operating systems in that upgrades occur automatically.

Matrix.org

Matrix.org is an open network for secure, decentralized communication. It allows users (or bots) to communicate with each other. Real-facetime discussion around Polkadot and Substrate occur on Riot, an app built on Matrix.

Clients like Riot make Matrix.org available to many users whether from their computer, laptop or smart phone.

The Matrix.org API allows programmatically interacting with the network. That makes it a tool of choice to alert users and lets them take actions on the go with what is probably the only tool they carry around everywhere: their smartphone.

Introducing Polkabot

Polkabot is an extensible chatbot who knows how to speak both on the Matrix.org and Polkadot networks.

Join the Polkabot room to receive real-time updates on how Polkadot is performing: https://matrix.to/#/#polkadot-network-status:matrix.org

You can also find the code for Polkabot here.

Polkabot is being optimised to issue as few critical alerts as possible so that the important information stands out.

Polkabot currently packages a few plugins:

Blocthday: A demo plugin that wishes Polkadot a happy blocthday every nth block.
BlockStats: A plugin that monitors the network and posts statistics if some metrics are atypical.
StallWatcher: Polkadot PoC-2 is still in its early days and the network is currently supported by a small number of validators (roughly 20). Being alerted early is key to keeping the network running. StallWatcher posts an alert if the last block was seen greater than X seconds ago.
Reporter: A must for any good Polkadot citizen who is interested in the on-chain governance capabilities that Polkadot offers. The Reporter plugin constantly watches the Polkadot network and informs its citizen of new proposals and referenda, as soon as they are proposed for a vote.
Validators: This plugin watches changes in the Validator list, informs of validators coming in and out, and warns validators as soon have they may have been slashed.

More plugins are still being implemented and will be seamlessly added, including direct communication with Polkabot.

About the author

Will is also writing articles for Base58.de where Blockchain news are decrypted and explained in German. Find other Polkadot related articles translated to German at https://base58.de/tag/polkadot/

References & links

Polkadot Network: https://polkadot.network/
Polkadot repository on Github: https://github.com/paritytech/polkadot
Polkadot Wiki: https://github.com/w3f/Web3-wiki/wiki/Polkadot
Polkabot repo: https://gitlab.com/Polkabot/
Polkabot news: https://twitter.com/hashtag/Polkabot
Meet the community on Riot: https://riot.im/app/#/room/#polkadot-watercooler:matrix.org

Docker Image for Polkadot

Tue, 24 Jul 2018 14:51:12 +0600

ethup

Wed, 04 Apr 2018 14:51:12 +0600

In order to interact with the Ethereum Blockchain and the best levels of security, one need to first have a running node that is fully synchronised. With the increasing traffic on Ethereum, this is becoming more and more difficult for regular users to stay in sync. This article introduces ethup, a simple tool that aims at doing just that.

Figure 1. Console output while synchronising the Ethereum Blockchain using parity

ethup can be found on github at: https://github.com/chevdor/ethup and has been published on npm.

Server vs Casual User

Initially, Ethereum nodes such as geth or parity have been design to run 24/7 and never… ever… stop. For such a piece of software to never break is not an easy task and passionate developers work hard everyday to ensure the stability of your favourite Ethereum client.

Before going any further, let’s give a short definition for what I call casual user. The casual user is using Ethereum from time to time but not all the time. The casual user is using a standard computer and may turn it on and off from time to time. As much as nodes running 24/7 on servers, the casual user is a key element to a successful Blockchain as it its main user.

Until about last year, synchronising the Ethereum blockchain as a casual user was rather easy. You just had to start your favourite client, let it spin a few minutes or an hour at most to catch up with the latest blocks from a week or two.

This has changed. Synchronising weeks of the Ethereum blockchain takes a long time. On a good laptop (with SSD drive) with a good internet connect and a killer internet connection, you should get a speed of 3~5 blocks a second. During that time, new blocks are created every ~15s on the fundation network and and you also need to catch up with those.

Developers feel this issue ever harder as they often synchronise several chains such as the “testnet” chains (ie: kovan, rinkeby, ropsten). Those are very similar to the official Ethereum Blockchain but offer different properties such as different consensus algorithms, faster block generation and most important Ether has no value on those chains.

The issue is known and the developers of Ethereum clients are working hard to improve the situation. Their work includes:

the ability to reduce the amount of data stored locally
speed up the synchronisation using frequent snapshots that client can securely share among them
compress the data going over the network
to support ‘light’ clients that can work without downloading the full blockchain
splitting clients and UI

Most of those improvements are barely noticed by users but often the result of very clever optimisations.

Light clients

Some improvements however are real tradeoffs. Using a light client for instance, means that you no longer have the entire blockchain locally and your node will need to fetch some of the data, when needed, from trusted sources.

ethup

I wrote ethup in order to help synchronising nodes using parity or geth with the various chains they support. ethup lets you start your client and reads its console output. When ethup thinks the chain has been entirely synchronised, it will stop the node.

Since I started this article, I also opened issues for both clients. You can find them at:

The ability to stop the node after it bas been synchronised means that you can then start synchronising another chain without changing the configuration or the ports being used.

I am personally using an alias I call ethupall to synchronise all my chains: alias ethupall=’time ethup -c “parity --chain kovan”; time ethup -c “parity --chain ropsten”; ethup -c “parity”; time ethup -c “geth --rinkeby”’

Since the issues mentioned above have been opened, some interesting discussions started. While geth does not seem to have a feature allowing to stop the node once the chain has been synced, the proposal for this change has been positively welcomed and seems to be being implemented.

As far as parity is concerned, a similar feature seems to exist already but I could not get it to work. If you follow the discussion, you will however find some interesting tricks from @5chdn showing how you can start several parity nodes in parallel as long as you shift their ports to prevent conflicts. This may be a good option if you only use parity nodes.

Installation

Installing ethup is easy (you need NodeJS/npm) and you can find the full documentation at: https://github.com/chevdor/ethup

$ npm install -g ethup

You can then immediately use it:

ethup -c "parity --chain kovan" && ethup -c "geth --rinkeby"

When the command above exits, both your kovan and rinkeby chains will be in sync.

You can now start every day in sync!

replay-safe-split-v2

Wed, 04 Apr 2018 14:51:12 +0600

In a recent post , Vitalik Buterin mentioned the need to ‘split’ Ether funds in order to prevent replay attacks and pointed to a splitter contract.

While this splitter contract has been verified and works fine, it leaves room for user errors as some unfortunately discovered by loosing some of their funds. I feel very sorry for the users who ran into this issue and I decided to improve the existing solution. If you did not split yet, read on as the new contract may help you stay safe.

At first, the issues may not be obvious unless you double check both chains. Your funds may go to the expected address on one fork and go to the dreaded 0x00000000000… address on the other fork. A fix is mandatory.

The ReplaySafeSplit-v2 smart contract has been processing over 710,651 transactions from 2016 to 2021 and over 42 billion worth of USD.

Solidity Snippets

Tue, 18 Apr 2017 14:51:12 +0600

Use Control Package to install.

This package requires the great package from davidhq: https://github.com/davidhq/SublimeEthereum to recognize solidity code.

To get started, create a .sol file. SublimeText will then recognize your file as an Ethereum Solidity file and activate the syntax coloriring as well as the snippets.

To see the list of available snippets, open the Panel (Shift+Command+P) and type 'solidity'.

Note	All snippets are triggered by their Solidity name so they should come up automagically as you type.

See the project’S repo at https://github.com/chevdor/EthereumSoliditySnippets

Generator EthApp

Fri, 24 Mar 2017 14:51:12 +0600

Getting Started

Read on a give a try.

What is Yeoman?

Trick question. It’s not a thing. It’s this guy:

Basically, he wears a top hat, lives in your computer, and waits for you to tell him what kind of application you wish to create.

Not every new computer comes with a Yeoman pre-installed. He lives in the [npm](https://npmjs.org) package repository. You only have to ask for him once, then he packs up and moves into your hard drive. Make sure you clean up, he likes new and shiny things.

npm install -g yo

Yeoman Generators

Yeoman travels light. He didn’t pack any generators when he moved in. You can think of a generator like a plug-in. You get to choose what type of application you wish to create, such as a Backbone application or even a Chrome extension.

To install generator-ethdapp from npm, run:

npm install -g generator-ethdapp

Finally, initiate the generator:

yo ethdapp

Getting To Know Yeoman

Yeoman has a heart of gold. He’s a person with feelings and opinions, but he’s very easy to work with. If you think he’s too opinionated, he can be easily convinced.

If you’d like to get to know Yeoman better and meet some of his friends, [Grunt](http://gruntjs.com) and [Bower](http://bower.io), check out the complete [Getting Started Guide](https://github.com/yeoman/yeoman/wiki/Getting-Started).

Generating your Dapp

For a generic Dapp:

yo ethdapp

For a Dapp taylored to Parity:

yo ethdapp:parity

Then answer the questions. Once you are done, run the deploy script:

./deploy.sh

Then (re)start Parity:

parity ui

You will see your app listed there:

Click on that link and you will see your DAPP:

License

MIT

https://github.com/chevdor/generator-ethdapp

Ethereum Chocolatey

Fri, 27 Mar 2015 02:34:12 +0100

You can visit the project page on GitHub.

The Github project for AlethZero is located at here.

You can find the list of available packages on chocolatey.org or read more about chocolatey.

Warning

The latest version changes very often. The package downloads the latest. It means that unlike the chocolatey package may suggest, you are not installing THE version x.y.z but the current candidate for this version. The official versions will not be flagged with -pre

(Un)Installation

First ensure you have installed chocolatey: https://chocolatey.org/. You will find a one-liner on the site to install it.

Note	At the moment, AlethZero is still a beta, so is the chocolatey package, so dont´t forget the -pre flag!

To find the latest package:

clist -pre alethzero-stable

To install AlethZero:

cinst -pre alethzero-stable

To install the latest version if you already have a version installed:

cinst -pre -force alethzero-stable

To uninstall AlethZero:

cuninst alethzero-stable

What is the package doing on my machine?

Install

Download the latest build from the official repo
Store the file into your temp folder
Unzip it in your %ProgramFiles%\AlethZero-stable
Delete the temp file

Uninstall

Wipe the install folder %ProgramFiles%\AlethZero
Delete the registry keys related to AlethZero

Note	AlethZero is a subkey of Ethereum in the registry. The uninstall process does not remove the ethereum key.

Can I trust it?

No! Never trust. Check it yourself!

You can find the scripts here:

Install: chocolateyInstall.ps1
Uninstall: chocolateyUninstall.ps1

You can also see the script on the chocolatey.org website.

Finally, you may download the package and open it locally using NuGET Package Explorer and look at the scripts before executing anything.

Known issues

If you install the package from powershell, the installer will throw you in the install folder at the end of the install. If you run from a regular shell, it will not do that and leave you where you are.
The uninstall does not remove the ethereum registry entry. This is wanted as more software may come under this key in the future and that would be a bad idea to be so aggressive.
Make sure to open your command prompt as Admin unless UAC is disabled. Otherwise you won´t be able to create a new folder in "Program Files" and the install will fail.

How to contribute or build the package yourself?

You are very welcome to clone this repository and submit pull requests. You can also easily build the package yourself using the "chocolatey pack" command:

cpack

The local install then goes with:

cinst -pre alethzero-stable -source %cd%

https://github.com/chevdor/ethereum-chocolatey