florian.richer/portfolio_hugo
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

Compare commits

base: florian.richer:b5be0e4099de762a097fce42ab26d6dc2fafd858
Branches Tags
florian.richer:main
...
compare: florian.richer:5aa73f345ac972c701ecb9e3b71384afc2a84a44
Branches Tags
florian.richer:main

2 commits
b5be0e4099 ... 5aa73f345a

Author SHA1 Message Date
Florian RICHER
5aa73f345a Improve pmbootstrap post
All checks were successful
deploy / docker (push) Successful in 1m22s
Details
2024-10-06 00:03:38 +02:00
Florian RICHER
5b4f569312 Improvement 2024-10-05 23:26:18 +02:00
10 changed files with 224 additions and 244 deletions
Show stats Expand all files Collapse all files

10
assets/icons/linkedin.svg
View file

@ -1,8 +1,4 @@
<?xml version="1.0" encoding="utf-8"?>
<!-- Uploaded to: SVG Repo, www.svgrepo.com, Generator: SVG Repo Mixer Tools -->
<svg width="800px" height="800px" viewBox="0 0 24 24" xmlns="http://www.w3.org/2000/svg">
<g>
<path fill="currentColor" d="M12 9.55C12.917 8.613 14.111 8 15.5 8a5.5 5.5 0 0 1 5.5 5.5V21h-2v-7.5a3.5 3.5 0 0 0-7 0V21h-2V8.5h2v1.05zM5 6.5a1.5 1.5 0 1 1 0-3 1.5 1.5 0 0 1 0 3zm-1 2h2V21H4V8.5z"/>
</g>
<?xml version="1.0" encoding="utf-8"?><!-- Uploaded to: SVG Repo, www.svgrepo.com, Generator: SVG Repo Mixer Tools -->
<svg fill="currentColor" width="800px" height="800px" viewBox="0 0 256 256" id="Flat" xmlns="http://www.w3.org/2000/svg">
<path d="M96,80a8,8,0,1,1-8-8A7.99993,7.99993,0,0,1,96,80Zm-8,28.001a4,4,0,0,0-4,4v64a4,4,0,1,0,8,0v-64A4,4,0,0,0,88,108.001Zm60,0a31.92463,31.92463,0,0,0-24,10.86767V112.001a4,4,0,0,0-8,0v64a4,4,0,1,0,8,0v-36a24,24,0,0,1,48,0v36a4,4,0,1,0,8,0v-36A32.03619,32.03619,0,0,0,148,108.001ZM224,44V212a12.01375,12.01375,0,0,1-12,12H44a12.01375,12.01375,0,0,1-12-12V44A12.01359,12.01359,0,0,1,44,32H212A12.01359,12.01359,0,0,1,224,44Zm-8,0a4.00458,4.00458,0,0,0-4-4H44a4.00458,4.00458,0,0,0-4,4V212a4.00458,4.00458,0,0,0,4,4H212a4.00458,4.00458,0,0,0,4-4Z"/>
</svg>
Side by side Swipe Overlay

Before

Width:  |  Height:  |  Size: 448 B

After

Width:  |  Height:  |  Size: 804 B

3
assets/scss/custom.scss
View file

@ -1,3 +1,6 @@
/*
You can add your own custom styles here.
*/
.menu-social svg {
color: var(--body-text-color);
}

2
config/_default/params.yml
View file

@ -2,7 +2,7 @@ mainSections:
- post
rssFullContent: true
favicon: /favicon.png
favicon: /favicon.ico
article:
headingAnchor: false

2
content/page/archives/index.md
View file

@ -5,7 +5,7 @@ layout: "archives"
slug: "archives"
menu:
main:
weight: 2
weight: 3
params:
icon: archives
---

33
content/page/links/index.md
View file

@ -1,33 +0,0 @@
---
title: Links
links:
- title: GitHub
description: GitHub is the world's largest software development platform.
website: https://github.com
image: https://github.githubassets.com/images/modules/logos_page/GitHub-Mark.png
menu:
main:
weight: 4
params:
icon: link
comments: false
---
To use this feature, add `links` section to frontmatter.
This page's frontmatter:
```yaml
links:
- title: GitHub
description: GitHub is the world's largest software development platform.
website: https://github.com
image: https://github.githubassets.com/images/modules/logos_page/GitHub-Mark.png
- title: TypeScript
description: TypeScript is a typed superset of JavaScript that compiles to plain JavaScript.
website: https://www.typescriptlang.org
image: ts-logo-128.jpg
```
`image` field accepts both local and external images.

2
content/page/search/index.md
View file

@ -7,7 +7,7 @@ outputs:
- json
menu:
main:
weight: 3
weight: 4
params:
icon: search
---

303
content/post/nix_flake/index.md
View file

@ -1,6 +1,6 @@
---
title: Découverte de Nix et de Flake
description: Installation de pmbootstrap et compilation d'un paquet Postmarket OS
description: Explication du langage Nix et de Flake, mais aussi comment les utiliser pour créer ses propres environnements de travail.
slug: nix-flake
date: 2024-10-04 00:00:00+0000
categories:
@ -8,19 +8,21 @@ categories:
tags:
- Nix
- Flake
weight: 1 # You can add weight to some posts to override the default sorting (date descending)
weight: 1
---
---
## Introduction
> Avant de commencer, je tiens à dire que j'ai fait ce post en partie pour l'entreprise [Unova](https://unova.fr/) où je travaillais. Je tiens à les remercier pour m'avoir autorisé à réutiliser le contenu sur mon site.
Nix est un gestionnaire de paquets basé sur le langage Nix. Il permet de gérer facilement une configuration système, d'un projet ou même d'un package (logiciel) et surtout de s'assurer de la reproductibilité de la configuration. Cependant, par défaut, Nix ne permet pas de "lock" la version de la configuration sur l'ensemble des machines. C'est pour cela que les développeurs développent Flake.
Flake est une feature experimentale qui permet de lock les dépendances sur une version très précise.
Un peu comme le Gemfile.lock ou même le package-lock.json.
Grâce au coté déclaratif de Nix, on peut par exemple facilement tester un outils sans l'installer de manière permanente sur sa machine avec :
Grâce au coté déclaratif de Nix, on peut par exemple facilement tester un outils sans devoir l'installer de manière permanente sur sa machine avec :
```bash
nix run nixpkgs#cowsay Salut # Lance directement la commande cowsay avec l'argument Salut
@ -37,23 +39,84 @@ Ou même configurer son shell existant pour pouvoir développer sur un logiciel
```bash
nix develop nixpkgs#cowsay # Prépare le shell actuel avec toutes les dépendances nécessaires pour compiler et exécuter cowsay
```
> **Attention: Ne clone pas les sources**
> **Attention: Il créer un shell avec les outils nécessaires pour travailler dessus, mais ne récupère pas le projet en lui-même.**
## Lexique
## Le langage Nix
Nix est un langage de programmation dédié pour la configuration d'une machine ou compilation de programme donc il peut être compliqué à prendre en main.
Il est différent des langages traditionnels, on peut le voir comme un language de construction d'un `attribut set` qui sera utilisé ensuite.
> Un `attribut set` peut-être vu comme un objet JS.
> ```nix
> { a = 12; b = 14; }
> ```
Je ferrais surement un post pour expliquer plus en détail le langage car il est assez complexe. J'ai rajouté quelques liens utiles [ici](#liens-utiles)
- `attribute set` => Fonctionne un peu comme un Hash en Ruby ou un object en JS
- `package` => Représente un logiciel, binaire, script, librairies installable sur le système.
- `derivation` => Représentation d'un package en Nix. Les fonctions `mkShell`, `writeScriptBin`, `buildGoModule`, `buildNpmPackage`, `buildRustPackage`, ... sont juste une surcouche pour faciliter la construction d'une dérivation. Derrière, ils appelent tous la fonctions `mkDerivation`. (Ex pour `buildGoPackage` https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/go/module.nix )
- `nix` => Gestionnaire de package et le language de programmation
- `flake` => Configuration reproductible localisé sur un repo git (projet).
> Attention: Le flake.nix ou flake.lock doit-être ajouté dans git avec un `git add flake.nix flake.lock` car sinon vous ne pourrait pas utiliser le Flake.
## Structure d'un Flake
### Introduction
### Partie `inputs`
On va ce baser sur cette exemple ci-dessous pour expliquer chaque partie du Flake.
```nix
inputs = {
nixpkgs.url = "github:nixos/nixpkgs/nixpkgs-unstable";
flake-utils.url = "github:numtide/flake-utils";
};
```
Dans cette exemple, on peut voir que j'ai rajouté les dépendances `nixpkgs` et `flake-utils`.
La dépendance `nixpkgs` correspond au repo [github nixpkgs](https://github.com/NixOS/nixpkgs). En général, on l'utilise pour récupérer des packages ou utiliser les outils mis à disposition par les contributeurs de NixOS.
On peut retrouver dans le repo.
- `/nixos` Contiens la configuration pour nixos (La distribution basée sur Nix)
- `/pkgs` Contiens tous les packages (ex: ruby_3_3)
> Les nouveaux packages doivent être mis dans le sous-dossier `by-name`. C'est un nouveau standard du projet. Les packages déjà existants migrent dessus petit à petit. Si un package manque, n'hésitez surtout pas à contribuer au projet.
- `lib` Contiens plein d'outils pratiques comme `makeLibraryPath` ou `makeIncludePath`
- `doc` Contiens la doc ^^
- `maintainers` Contiens la liste de tous les mainteneurs des packages.
La dépendance `flake-utils` contient des helpers pour faciliter la configuration pour un ensemble de systèmes (`x86_64-linux`, `x86_64-darwin`, ...).
> `darwin` Correspond au système Mac OS
### Partie `outputs`
Outputs est une fonction qui prend en paramètre un `attribute set` avec pour attributs self et les dépendances déclarées dans la partie `inputs`.
Dans le cas ou l'on a les dépendances suivantes:
```nix
inputs = {
nixpkgs.url = "github:nixos/nixpkgs/nixpkgs-unstable";
flake-utils.url = "github:numtide/flake-utils";
mon-input-custom.url = "github:mongithub/monprojet";
};
```
On aura les entrées suivantes dans `outputs`:
```nix
outputs = { self, nixpkgs, flake-utils, mon-input-custom }:
# ^^^^^^^ ^^^^^^^^^^^ ^^^^^^^^^^^^^^^^
# Doit avoir le même nom que dans les inputs
{
devShells.x86_64-linux.default = {...};
packages.x86_64-linux.default = {...};
nixosConfigurations.x86_64-linux.default = {...};
}
```
Les attributs que l'on peut retrouver dans `outputs` sont:
- `devShells` Des environnements de développement.
- `nixosConfigurations` Des configurations de NixOS (La distribution Linux)
- `darwinConfigurations` Des configurations pour Mac OS [En savoir plus](https://github.com/LnL7/nix-darwin)
- `packages` Des packages (Docker, ruby, go, rust, ...)
- `[...]`
### Exemple de flake
Dans cette example, j'ai déclaré un environnement de travail utilisable avec la commande `nix develop`.
J'ai rajouté en dépendances la librairie `openssl`, la commande `redis` et un script au lancement du shell.
```nix
{
@ -73,7 +136,7 @@ On va ce baser sur cette exemple ci-dessous pour expliquer chaque partie du Flak
devShells = rec {
default = pkgs.mkShell {
inputsFrom = with pkgs; [openssl];
packages = with pkgs; [redis minio];
packages = with pkgs; [redis];
shellHook = ''
echo "Votre shell est configuré"
'';
@ -83,79 +146,7 @@ On va ce baser sur cette exemple ci-dessous pour expliquer chaque partie du Flak
}
```
### Partie `inputs`
Dans ce flake, on peut trouver tout d'abord la partie `inputs`, elle correspond aux dépendances de notre flake.
La dépendance (inputs) `nixpkgs` correspond au repo [github nixpkgs](https://github.com/NixOS/nixpkgs). En général, on l'utilise pour récupérer des packages ou utiliser les outils mis à disposition par les contributeurs de NixOS.
On peut retrouver dans le repo.
- `/nixos` Contiens la configuration pour nixos (La distribution basée sur Nix)
- `/pkgs` Contiens tous les packages (ex: ruby_3_3)
> Les nouveaux packages doivent être mis dans le sous-dossier `by-name`. C'est un nouveau standard du projet. Les packages déjà existants migrent dessus petit à petit. Si un package manque, n'hésitez surtout pas à faire des PR sur github.
- `lib` Contiens plein d'outils pratiques comme `makeLibraryPath` ou `makeIncludePath`
- `doc` Contiens la doc ^^
- `maintainers` Contiens la liste de tous les mainteneurs des packages.
La dépendance (inputs) `flake-utils` contient des helpers pour faciliter de la configuration pour un ensemble de systèmes (`x86_64-linux`, `x86_64-darwin`, ...).
> darwin => Mac OS
### Partie `outputs`
Outputs prend une fonction qui prend en paramètre un `attribute set` avec pour attributs self et les inputs déclarés dans la partie `inputs`.
Dans le cas ou l'on a les inputs suivants:
```nix
inputs = {
nixpkgs.url = "github:nixos/nixpkgs/nixpkgs-unstable";
flake-utils.url = "github:numtide/flake-utils";
mon-input-custom.url = "github:mongithub/monprojet";
};
```
On aura les attributs suivants dans `outputs`:
```nix
outputs = { self, nixpkgs, flake-utils, mon-input-custom }:
{
...
}
```
Elle correspond aux configurations disponibles pour un flake pour chaque système.
```nix
outputs = { self, nixpkgs }:
{
devShells.x86_64-linux.default = {...};
packages.x86_64-linux.default = {...};
nixosConfigurations.x86_64-linux.default = {...};
};
```
> Rappel Nix
>
> `add = a: b: a + b`
>
> Créer une fonction avec le nom `add` qui prend en paramètre `a` et `b` et qui renvoie l'addition des deux. On déclare un paramètre avec la syntaxe `[nom du paramètre]:`
>
> `add 1 2` renvoie `3`
>
> On peut également faire des variantes.
>
> `add3N = add 3`
>
> `add3N 10` renvoie `13`
>
> Car `add 3` renvoie une fonction avec le premier paramètre a = 3
Les attributs que l'on peut retrouver dans `outputs` sont :
- `devShells` Des environnements de développement.
- `nixosConfigurations` Des configurations de NixOS (La distribution Linux)
- `darwinConfigurations` Des configurations pour Mac OS [En savoir plus](https://github.com/LnL7/nix-darwin)
- `packages` Des packages (Docker, ruby, go, rust, ...)
- `[...]`
## Comment mettre à jour le `flake.lock`
## Mettre à jour le `flake.lock`
Le flake.nix vient avec un fichier flake.lock qui permet de vérrouiller la version de chaque input. Si on souhaite mettre à jour nos packages pour notre projet. Il est nécessaire de le mettre à jour.
@ -163,7 +154,7 @@ On retrouve deux commandes:
- `nix flake update` Mets à jour tous les inputs
- `nix flake lock --update-input <input>` Mets à jour uniquement un input en particulier
### Comment débugger sa configuration avec la console nix
## Débugger sa configuration avec la console nix
Il existe une console depuis la version expérimentale de nix `nix-command`. On peut y accéder avec la commande `nix repl`.
@ -188,11 +179,14 @@ Added 13 variables.
Une fois chargé, on peut accéder aux outputs avec `outputs.<type de conf>.<system>.<nom>`
> Tips : Vous pouvez appuyer deux fois sur Tab pour avoir de l'aide.
>
> Vous pouvez aussi facilement vérifier votre configuration nix avec la commande `nix flake check .`
> Vous pouvez aussi facilement vérifier votre configuration nix avec la commande
> ```bash
> nix flake check .
> ```
### Fonctionnement des environnements de développement
## Fonctionnement des environnements de développement
#### Comment utiliser un devShell
### Utiliser un devShell
Les devShells permettent de configurer des environnements par défaut.
On peut y accéder avec l'aide de la commande `nix develop [path du flake]#[nom de l'environnement]`.
@ -204,79 +198,86 @@ Ex: `nix develop .#default`
On peut accéder aux environnements utilisés pour développer n'importe quel package nix. Par exemple, si l'on souhaite aider au développement de ruby. On peut lancer une console de développement avec la commande `nix develop nixpkgs#ruby` ou même voir la configuration d'un package avec `nix edit nixpkgs#ruby`
> On remarquera qu'ici j'utilise `nixpkgs` et pas le path du flake. Ça permet d'utiliser la configuration d'un package depuis nixpkgs directement.
>
> **Attention**
> Pour des logiciels compilés, en général, il faut d'abord configurer le compilateur via les `phases` du logiciel. ex: `configurePhase` et ensuite compiler le logiciel ex: `buildPhase` . Les phases peuvent varier en fonction du logiciel.
#### Comment configurer un devShell
### Configurer son propre devShell
Voici une configuration de shell avec des commentaires pour expliquer le fonctionnement.
```nix
outputs = { self, nixpkgs, flake-utils }:
// Génère une configuration avec l'ensemble des systèmes par défaut
// aarch64-linux => ARM sur Linux
// aarch64-darwin => M1, M2, M3, ... sur MacOS
// x86_64-linux => AMD et Intel sur Linux
// x86_64-darwin => Intel sur MacOS
//
// Pour configurer avec une liste précise de systèmes, vous pouvez utiliser cette fonction
// flake-utils.lib.eachSystem ["aarch64-linux" " x86_64-darwin"] (system: [...])
// Voir plus https://github.com/numtide/flake-utils
//
// Les éléments d'un tableau ne sont pas séparés par une virgule ex: [ 12 14 ]
flake-utils.lib.eachDefaultSystem (system:
let
// Importe les packages pour le système.
// Le mot clef inherit équivaut à import nixpkgs { system = system };
// On peut aussi inherit depuis autre chose
// { inherit (pkgs.ruby) pname; } renverra { pname = "ruby" }
pkgs = import nixpkgs { inherit system; };
in
{
// rec Permet d'utiliser les variables dans le même attributs set
// Exemple:
// { a = 12; b = a + 2; } => error: undefined variable 'a'
// rec { a = 12; b = a + 2; } => { a = 12; b = 14; }
//
// Attention, car parfois, on peut faire des infinites recurse par accident.
// Exemple:
// rec { a = b + 2; b = a + 2; } => error: infinite recursion encountered
// a dépend de b pour fonctionner, mais b dépend également de a
devShells = rec {
default = pkgs.mkShell {
// with pkgs permet d'éviter de faire [ pkgs.redis pkgs.minio ]
inputsFrom = with pkgs; [ openssl ]; // Rajoute des dépendances pour la compilation comme les librairies
packages = with pkgs; [ redis minio ]; // Rajoute des binaires ou des librairies pour l'execution
# Génère une configuration avec l'ensemble des systèmes par défaut
# aarch64-linux => ARM sur Linux
# aarch64-darwin => M1, M2, M3, ... sur MacOS
# x86_64-linux => AMD et Intel sur Linux
# x86_64-darwin => Intel sur MacOS
#
# Pour configurer avec une liste précise de systèmes, vous pouvez utiliser cette fonction
# flake-utils.lib.eachSystem ["aarch64-linux" " x86_64-darwin"] (system: [...])
# Voir plus https://github.com/numtide/flake-utils
#
# Les éléments d'un tableau ne sont pas séparés par une virgule ex: [ 12 14 ]
flake-utils.lib.eachDefaultSystem (system:
let
# Importe les packages pour le système.
pkgs = import nixpkgs { inherit system; };
# Le mot clef inherit équivaut à import nixpkgs { system = system };
# On peut aussi inherit depuis autre chose
# { inherit (pkgs.ruby) pname; } renverra { pname = "ruby" }
in
{
devShells = rec {
# rec Permet d'utiliser les variables dans le même attributs set
# Exemple:
# { a = 12; b = a + 2; } => error: undefined variable 'a'
# rec { a = 12; b = a + 2; } => { a = 12; b = 14; }
#
# Attention, car parfois, on peut faire des infinites recurse par accident.
#
# Exemple:
# rec { a = b + 2; b = a + 2; } => error: infinite recursion encountered
#
# Car a dépend de b pour fonctionner, mais b dépend également de a
MY_CUSTOM_ENV_VAR = "test";
# On utilise la fonction pkgs.mkShell qui contient tout ce qui nous faut pour créer notre environnement de travail
default = pkgs.mkShell {
# On rajoute des dépendances pour la compilation comme les librairies
inputsFrom = with pkgs; [ openssl ];
# On rajoute des binaires ou des librairies pour l'execution
packages = with pkgs; [ redis minio ];
# with pkgs permet d'éviter de faire [ pkgs.redis pkgs.minio ]
// Parfois nécessaire pour lancer des projets avec des librairies comme Ruby par exemple.
// *_LIBRARY_PATH permet de dire à l'OS ou chercher les librairies.
// Il faut le rajouter par exemple si on rencontre le soucis `Could not open library 'libsodium.so.23'`
// LD_LIBRARY_PATH => Linux
// DYLD_LIBRARY_PATH => MacOS
LD_LIBRARY_PATH = pkgs.lib.makeLibraryPath(with pkgs; [libsodium]);
DYLD_LIBRARY_PATH = pkgs.lib.makeLibraryPath(with pkgs; [libsodium]);
# On créer une variable d'environnement
MY_CUSTOM_ENV_VAR = "test";
// Parfois nécessaire pour configurer des projets comme Ruby avec bundle
// Certaines gems Ruby génèrent un fichier .c avec du code en dure et surtout un `#include <malib.h>` dedans.
// Sauf qu'ils utilisent pas les outils de configuration du compilateur fournis par les OS. Donc, il faut créer des variables d'environnements pour dire au compilateur ou chercher les fichiers requis.
// C_INCLUDE_PATH => Pour le language C
// CPLUS_INCLUDE_PATH => Pour le language C++
C_INCLUDE_PATH = pkgs.lib.makeIncludePath(with pkgs; [libsodium]);
CPLUS_INCLUDE_PATH = pkgs.lib.makeIncludePath(with pkgs; [libsodium]);
# Parfois nécessaire pour lancer des projets avec des librairies comme Ruby par exemple.
# *_LIBRARY_PATH permet de dire à l'OS ou chercher les librairies.
# Il faut le rajouter par exemple si on rencontre le soucis `Could not open library 'libsodium.so.23'`
# LD_LIBRARY_PATH => Linux
# DYLD_LIBRARY_PATH => MacOS
LD_LIBRARY_PATH = pkgs.lib.makeLibraryPath(with pkgs; [libsodium]);
DYLD_LIBRARY_PATH = pkgs.lib.makeLibraryPath(with pkgs; [libsodium]);
// Le shellHook est un script lancé au lancement du shell
shellHook = ''
echo "Votre shell est configuré avec MY_CUSTOM_ENV_VAR = $MY_CUSTOM_ENV_VAR"
'';
};
# Parfois nécessaire pour configurer des projets comme Ruby avec bundle
# Certaines gems Ruby génèrent un fichier .c avec du code en dure et surtout un `#include <malib.h>` dedans.
# Sauf qu'ils utilisent pas les outils de configuration du compilateur fournis par les OS. Donc, il faut créer des variables d'environnements pour dire au compilateur ou chercher les fichiers requis.
# C_INCLUDE_PATH => Pour le language C
# CPLUS_INCLUDE_PATH => Pour le language C++
C_INCLUDE_PATH = pkgs.lib.makeIncludePath(with pkgs; [libsodium]);
CPLUS_INCLUDE_PATH = pkgs.lib.makeIncludePath(with pkgs; [libsodium]);
# Le shellHook est un script lancé au lancement du shell
shellHook = ''
echo "Votre shell est configuré avec MY_CUSTOM_ENV_VAR = $MY_CUSTOM_ENV_VAR"
'';
};
});
};
});
```
[docs](https://ryantm.github.io/nixpkgs/builders/special/mkshell/)
### Liens utiles
## Liens utiles
**Pour apprendre nix**
- https://nixcloud.io/tour/?id=introduction/nix

113
content/post/pmbootstrap_custom_build/index.md
View file

@ -1,6 +1,6 @@
---
title: Compiler un paquet Postmarket OS
description: Installation de pmbootstrap et compilation d'un paquet Postmarket OS
description: Installation de pmbootstrap pour la compilation d'un paquet Postmarket OS. OS basé sur Alpine pour téléphone mobile.
slug: pmbootstrap-own-paquet
date: 2024-02-18 00:00:00+0000
categories:
@ -22,11 +22,13 @@ On peut aussi l'utiliser pour compiler son propre paquet et l'installer sur son
Avant de pouvoir l'utiliser, il faut d'abord l'installer depuis ce [lien](https://wiki.postmarketos.org/wiki/Pmbootstrap).
Une fois installé et configuré, il faut d'abord préparer son environnement de travail.
Il est parfois nécessaire de mettre à jour le repository pmaports en local.
On peut le faire assez facilement avec la commande :
_Met à jour le repository [pmaports.git](https://wiki.postmarketos.org/wiki/Pmaports.git) cloné en local._
```bash
pmbootstrap pull
```
_Met à jour le repository [pmaports.git](https://wiki.postmarketos.org/wiki/Pmaports.git) cloné en local._
> Le repo pmaports.git stocke tous les paquets Alpine avec le fichier `APKBUILD` utilisé par le serveur de compilation.
>
> Le fonctionnement est similaire à `PKGBUILD` pour les utilisateurs de [Archlinux](https://archlinux.org/)
@ -35,28 +37,24 @@ pmbootstrap pull
> ainsi que la procédure pour vérifier si le paquet fonctionne correctement.
> Généralement on utilise les tests du projet comme les tests unitaires ou les tests fonctionnels.
_Met à jour le cache de la commande APK depuis l'environnement de travail_
On peut également mettre à jour le cache de la commande `apk` même si c'est pas forcément obligatoire.
```bash
pmbootstrap update
```
_Met à jour le cache de la commande APK depuis l'environnement de travail_
> L'environnement de travail se situe par défaut dans le dossier `$HOME/.local/var/pmbootstrap/`
_Supprime le dossier de la commande chroot_
Si on a déjà un environnement de travail en cours et qu'il contient du cache ou un travail en cours, on peut le réinitialiser assez facilement avec la commande :
```bash
pmbootstrap zap
```
_Supprime le dossier de la commande chroot pour repartir de 0_
> La commande chroot permet de changer la racine Linux.
> Par exemple, on peut faire `chroot $HOME/mon_dossier` et à partir de ce moment-là, `/` pointera vers `$HOME/mon_dossier` dans notre shell actuel.
>
> C'est très utilisé par pmbootstrap pour configurer le système Alpine.
> Ça évite de devoir faire une VM ou un container Linux juste pour changer quelque fichier.
>
> Dans notre cas, il correspond au système de notre téléphone pour le configuré avant de l'installer ou de le tester sur notre appareil.
>
> Par défaut, il se situe dans le dossier `$HOME/.local/var/pmbootstrap/cache_git/pmaports/`
_[Optionnel] Changer la branche du repo [pmaports.git](https://wiki.postmarketos.org/wiki/Pmaports.git)_
Pour ceux qui veulent utiliser une autre branche, on peut également changer la branche disponible sur le repository.
```bash
git -C $workdir checkout [branch]
```
@ -66,57 +64,72 @@ git -C $workdir checkout [branch]
## Compilation de notre paquet Alpine
Pour compiler le paquet, on utilise la commande `pmbootstrap build [paquet_name]`.
> Avant de compiler depuis le repository Nightly, il faut d'abord rajouter la clef de signature
>
> `wget https://nightly.postmarketos.org/plasma-mobile/pmos@local-662fcd2f.rsa.pub`
>
> `mv pmos@local-662fcd2f.rsa.pub $(pmbootstrap config work)/config_apk_keys/`
>
> Source : https://wiki.postmarketos.org/wiki/Nightly
Maintenant, on va pouvoir compiler n'importe quel paquet avec la commande.
```bash
pmbootstrap build [nom_du_paquet]
```
Par exemple, on peut compiler plasma-mobile (Attention le paquet est long à compiler)
```bash
pmbootstrap build plasma-mobile
```
Par défaut, pmbootstrap va recompiler l'intégralité des dépendances du projet pour s'assurer que notre test sera reproductible.
Cependant, lorsque l'on souhaite juste tester un truc, ça peut-être ultra long.
On peut donc utiliser deux options pour nous aider:
* `-i` Permet de dire de compiler uniquement les dépendances du paquet défini dans le fichier `APKBUILD`
* `-n` Permet d'éviter de compiler les dépendances du paquet défini dans le fichier `APKBUILD`
Avec le combot des deux options, ça nous évite de tout recompiler.
On a aussi l'option `-mp` qui peut-être pratique pour changer de mirroir si le téléchargement est lent ou si l'on souhaite télécharger des paquets nightly.
> Un mirroir est un serveur utilisé pour télécharger les dépendances
On utilise cette option de cette manière:
```bash
pmbootstrap \
-mp https://nightly.postmarketos.org/plasma-mobile/packages/ \
-mp http://mirror.postmarketos.org/postmarketos/
```
On a aussi d'autres options comme:
* `--details-to-stdout` : Affiche le fichier de log dans la console
* `-j N` : Défini le nombre de core CPU utilisé pour la compilation
* `-t [En seconde]` : Le nombre de secondes sans nouveau log dans le fichier avant d'abandonner la compilation
* `--src` : Change les sources du paquet. Par défaut ce sont les sources définies dans le fichier `APKBUILD`
* `--arch [arch]` : L'architecture CPU du téléphone
Un exemple concret d'une commande que j'ai utilisé pour recompiler ma version de plasma-mobile avec mes changements.
_Exemple de commande_
```bash
pmbootstrap \
-mp https://nightly.postmarketos.org/plasma-mobile/packages/ \
-mp http://mirror.postmarketos.org/postmarketos/ \
--details-to-stdout \
-j 32 \
-t 3600 -v \
-j 32 \ # Pour utiliser toute la puissance de mon CPU
-t 3600 -v \ # La compilation est ultra longue donc pmbootstrap abandonne la build avant la fin de la compilation
build plasma-mobile \
--src $home/plasma-mobile/ \
--arch aarch64 \
--arch aarch64 \ # Mon téléphone utilise l'architecture aarch64 (ARM64)
-i \
-n
```
Dans cet exemple, j'ai utilisé les arguments suivants:
> **Attention**
>
> Avant de compiler depuis le repository Nightly, il faut d'abord rajouter la clef de signature
>
> ```bash
> wget https://nightly.postmarketos.org/plasma-mobile/pmos@local-662fcd2f.rsa.pub
> mv pmos@local-662fcd2f.rsa.pub $(pmbootstrap config work)/config_apk_keys/
> ```
>
> Source : https://wiki.postmarketos.org/wiki/Nightly
* `-mp` : Permet de définir un repository Alpine pour installer les paquets.
> Dans l'exemple, j'utilise deux repos
>
> `https://nightly.postmarketos.org/plasma-mobile/packages/` : Contient la version en cours de développement de KDE Plasma Mobile
>
> `http://mirror.postmarketos.org/postmarketos/` : Le miroir officiel de Postmarket OS
* `--details-to-stdout` : Affiche les logs stocké dans le fichier dans la console
* `-j N` : Défini le nombre core utilisé pour la compilation
> Dans mon cas, 32 core sur mon CPU.
* `-t [En seconde]` : Le nombre de secondes sans nouveau log dans le fichier avant d'abandonner la compilation
> Changé par 3600 secondes, car plasma-mobile est assez long à compilé et il ne génère aucun log.
* `-v` : Mode verbeux pour les logs dans le fichier
* `--src` : Change les sources du paquet. Par défaut ce sont les sources définies dans le fichier `APKBUILD`
> Pour ma part, je souhaite utiliser mon propre code pour tester
* `--arch [arch]` : L'architecture CPU du téléphone
> Pour ma part, mon téléphone est en arm64v8 donc `aarch64`
* `-n` : Permet d'éviter de compiler les dépendances du paquet.
> En général, ce n'est pas recommandé par Alpine, mais dans mon cas, je souhaite utiliser les dépendances depuis le repo
> miroir officiel de Postmarket OS.
* `-i` : Permet de dire de compiler uniquement les dépendances du paquet défini dans le fichier `APKBUILD`
> Dans mon cas, il vient en complément de l'option `-n`, ça me permet de m'assurer de ne rien build.
> Sans cette option, il risque de compiler les sous-dépendances du paquet comme le noyau Linux.
Pour plus d'informations, il suffit de taper la commande
Si vous souhaitez avoir plus d'informations, il suffit de taper la commande
```bash
pmbootstrap build --help
@ -128,7 +141,7 @@ Et pour avoir les arguments généraux
pmbootstrap --help
```
## Envoie du paquet sur le téléphone
## Envoie du paquet compilé sur le téléphone
Une fois le paquet compilé, il suffit de demander à `pmbootstrap` de l'envoyer sur notre téléphone via la connexion SSH.
Avec `pmbootstrap`, on utilise la commande `sideload` comme dans l'exemple ci-dessous.

BIN
static/favicon.ico Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 21 KiB

BIN
static/favicon.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 639 B