Project abstract This project is packaging the Ethereum clients for Debian-based systems while providing additional packages that make installing and running nodes much easier. Running a node is hard, one-click installation through a command line or similar should be a norm. In-depth configuration should be an option and not a requirement. Creating Debian packages is quite challenging if the official Debian way is followed. This project also extends official packaging without altering it by adding reusable specification files and building a system to hide the complexities of packaging. This project is trying to adhere to Ethereum philosophy of sandwich complexity and hide many aspects of complexities: node running

Writing Makefile that automates the process of packaging Patching if needed offer built packages in the repository (through building them) Week 15 On week 15 I have finished the build system that allows to build any client based on simple command line argument. As I have detailed this in the previous week, we have 6 steps that we want to make sure happens Have the specification files ready (hard requirement) Generate the /debian dir based from specification file which will be stored in the gihtub repo along with the specifaction file and all versions of how to build that client. Download the source from .tar.gz and extract it. Rename it according to debian naming convention.

Week 12 This week, I've been working on improving the documentation over on HackMD about debcrafter. I wanted to make sure Debcrafter options were well-documented and easy to understand, before diving into using it. However, I realized that the initial documentation wasn't up to par, so I took the initiative to rewrite and clarify the options. You can check out the updated documentation here: HackMD Debcrafter SPS Options. What I found interesting is that the format generation by AI system was actually pretty good. (Disclaimer: I was using AI for generating sentences, and sentence structures, most of the work was collecting, organizing and understanding as much as possible what should go into the documentation) The problem I have encountered was my own understanding of Debcrafter options, which at many case were incorrect. The documentation still need further improvement, I will come back to it after having packages ready. Week 13 Unfortunately, this week wasn't as productive as I'd hoped. I've been under the weather due to what seems like a case of food poisoning. As a result, I couldn't make as much progress on the tasks as I would have liked.

.sps - "smart package specification" - defines how individual packages look and behave. There are three kinds of sps files: Basic - most often contains just binaries or dumb data. Service - defines a service launched with the system (e.g. bitcoind) and the corresponding package. These are often parametrised over bitcoin network (mainnet, regtest) Configuration extensions - define packages that control configuration. These are used for settings that need to be enforced by the depending packages. The main idea is to avoid conflicting configuration and other issues.

debcrafter is a tool that simplifies the process of creating Debian packages. Creating a binary package with debcrafter - QUICK version Creating a binary package with debcrafter - LONG version SRS - smart repository specification - reference SPS - smart packaging specification - reference SSS - smart source specification - reference TODO - Debian packaging fields reference TODO - Creating a configuration package with debcrafter

In this tutorial, we will explore how to use debcrafter, that simplifies the process of creating Debian packages. By following the steps outlined in this walkthrough, you will be able to create a Debian package. Prerequisite You need to be on debian 10 to run debcrafter. cd workspace git clone https://github.com/Kixunil/debcrafter.git cargo install --path . You also need to install the required dependencies

Development updates Delving into interpreters, debcrafter, a tool for defining a language for intelligent, dependent packaging, required an in-depth exploration of its internals. I was waiting for mentor to discuss debcrafter, to grasp the nuances of configuration and service packages, a previously challenging aspect for me. This two weeks, was quite boring but at the same time very hard. Compilers are very interesting, but it takes a lot of time if building from stratch to really understand the process. I have the feeling that this two week of research was excessive, but I as I'm writing this note later, I think it made a lot of sense to understand the theory in more detail. Crafting interpreters, of how transpiling works - https://github.com/eenagy/craftinginterpreters

Development updates Engaged in a mentorship call where I received a comprehensive walkthrough of various options and learned how to effectively utilize debcrafter, especially since many of its available options are not yet documented. I'm going to work on this documentation, as it is both needed for my work and future maintainers for the eth deb repository. Started working on the documentation for debcrafter, aiming to provide valuable resources for future eth deb maintainers based on my newfound understanding. Progressing on the development of initial packages using debcrafter through an iterative approach, and document my progress as I go along. I don't have built packages yet, I'm quite behind based on my best case schedule, but I'm still also ahead of my normal schedule that I have provided in my proposal. I have given a pessimistic schedule, as I know there are always things that are not foreseeable. Link to documentation How to package with debcrafter: https://hackmd.io/@eenagy/Bk6GUZEe6 Debcrafter documentation - https://hackmd.io/@eenagy/S14twXNg6 Crafting interpreters, of how transpiling works - https://github.com/eenagy/craftinginterpreters

Creating single source # Used for all in control file maintainer = "John Doe <johndoe@example.com>" # Each source defines a different source directory [sources.hello-world] # Upstream version version = "0.1" section = "net" # Packages available within the source

.sss - "smart source specification" - defines basics of the source package.

This two week was dedicated to go-packaging and diving into debcrafter and gathering information about what the configuration packaging should contain, also how to utilize or not to utilize debmake. I finished my proposal and submitted it. I will be presenting it on week 8, as time didn't allow for everyone to do so. I have asked for vm on aws which was setup to host the debian repository, currently only available in unstable version. This week were also where I left the virtualbox and docker container for building packages and moved to digitalocean droplet as both virtualbox and docker were limited when it came to reproducible builds. Notes on reprepro Setting up nginx apt-get update apt-get install nginx mv /etc/nginx/sites-available/default /etc/nginx/sites-available/default.bak

During this period, I was formulating user stories that aligned with my program objectives. Simultaneously, I've been dedicating time to studying security resources and configuration packages. Over the past two weeks, I initially considered automating the packaging process through a pipeline. However, upon further reflection in subsequent weeks and following a call, I've realized that this approach is not suitable. It seems excessive for the current task at hand and diverts from the optimal path forward. Instead, I've come to understand that focusing on configuration and service packages should be the primary area of attention. I discovered reprepro which makes repository management much more easier. User stories As a node runner I want to use apt-get to dowload the software So I can save time and cognitive resources

TODO

Note: Process in week 2 meant the process related to packaging best practices for multiple github repository and was meant for coordination. That process were replaced by the internal process of how to create debian packages. Note: The process of creating debian packages are very flexible and upto each maintainer. Debian offers best practices and policies that must be followed, but there is no one way to do it. So for new maintainers is the biggest challange to overcome. The bellow guide is based on following mainstream debian best practices, and were picked for simplicity and reproducibility in mind. Creating debian packages process overview Prerequisites Setup docker container for creating/modifying deb package

TLDR Week 2 update, combined with week 1, as I didn't share it yet (due to that, I could not work as much on week 1 and had to push the work from week 1 to week 2): I'm working on setting up the deb repository for ethereum related nodes/toolchains I have been working on setting up the nodes locally with scripts I'm writing and seeing how the various components would work through the package manager when deb packages are used instead of binaries. I will share the scripts repo when it is usable for other platforms and contains enough configuration options for usability; right now, it's nothing more than an implementation done for understanding. I have been collecting questions as I still familiarized myself with the process. And now, I have a good grasp of the different elements this project will entail. I have created a skeleton of the project tasks I will work on in the following months. Though, this might change at this point. Tasks I'm doing Familiarize myself with Debian-based distros and especially the Linux toolchain

Plan [ ] Go through suggested readings and create flashcards [ ] Notes on suggested readings and grade suggested project on interests and affinity with my skills [ ] prepare questions for projects Readings Favorite pieces Ethereum in 30 minutes Ethereum Design Rationale

NOTE: work in progress, submitted as unfinished, for the finished article please check the linked source. This will be left as it was submitted. Motivations for Building a Blockchain from Scratch: Understanding Explaining to non-technical people why blockchain development takes so much time (abstraction layers) Explaining to technical people Planned parts of this series PART 1 - Building the vm

Why is Chiang Mai the best place to host Devcon VII? Convince us 🙂 Chiang Mai, Thailand's 2nd largest city, with a population of over 200,000, is a vibrant city with an International airport that retains the culture, art, and architecture from the days when Chiang Mai was the Capital of the ancient Kingdom of Lanna. Today, Chiang Mai serves as the gateway to Northern Thailand. Located 700km north of Bangkok, Chiang Mai has become a significant destination for Thai and foreign visitors. Modern Chiang Mai, built on the banks of the Ping River, nestles between fertile rice fields and is surrounded by some of Thailand's highest mountains. Chiang Mai's tropical climate is tempered by its elevation, which keeps temperatures and humidity slightly lower than in most other parts of Thailand. Chiang Mai means the "new city," over 600 years old, the perfect melting point of new and old, not just in name but in reality. Chiang Mai is a top nomad destination, a tourist paradise, a crypto city, a healing center, a food paradise, and so much more. It's one of the most beloved cities on Earth. Thailand is known as "The Land of a Thousand Smiles.", and Chiang Mai will be adding a pinch more, as it has a tighter community compared to the capital city, Bangkok, and lovely surrounded by lovely mountains offering an escape to nature.