Pour la fonctionnalité de partage de liens sur ce blog, j'ai développé un script qui récupére le contenu d'une page et analyse ses balises pour identifier ses données Open Graph.

Dans un autre contexte, j'ai rencontré un bug dans Wallabag qui l'empêche de récupérer le contenu de plusieurs pages web que je désirait lire plus tard. Avec la volonté de créer un rapport de bug, la documentation m'a amené sur la piste du projet Graby utilisé par Wallabag.

Pour comprendre et peut-être proposer un correctif, j'ai joué avec Graby et ça m'a amené à réaliser une API pour remplacer le script utilisé par le blog, en combinent Graby et fusonic/opengraph. L'objectif de l'API est donc de retourner des données générées par Graby et OpenGraph au format JSON.

Voici à quoi ressemble un retour d'appel à l'API avec les données Open Graph :

Le projet est dépendant de PHP 7.3 et c'est libre. Le code source est dispo ici.

Original post of Simon Vieille.Votez pour ce billet sur Planet Libre.

Si vous provisionnez vos VM VirtualBox avec Vagrant, vous avez sans doute eu l’idée d’automatiser le provisionning des machines virtuelles. Dans mon cas une VM GNU/Linux basée sur Debian 9.

Pour cela, soit vous faite tout manuellement et après les mises à jour deviennent fastidieuses, soit vous appliquez un script shell au démarrage de vagrant, soit vous utilisez Ansible.

Ansible est un outil opensource permettant d’automatiser le provisionning et la mise à jour des environnements à distance (via SSH). L’avantage par rapport à des outils tels que Puppet, est qu’il ne nécessite pas l’installation d’agent.

Je vais essayer de vous montrer comment mettre en place le provisionning via Ansible pour VirtualBox.

Configuration de Vagrant

Dans le fichier Vagrantfile, on active le provisionning via Ansible:

config.vm.provision "ansible_local" do |ansible|
ansible.playbook = "site.yml"
ansible.install_mode = "pip"
ansible.version = "2.7.10"
end

Cette configuration fait référence à un fichier « playbook » site.yml. C’est la configuration qui sera appliqué lors du provisionning . Que ça soit à la création ou pour les mises à jour.

Voici un exemple de contenu:

- name: VirtualBox
hosts: all
become: yes
become_user: "root"
become_method: "sudo"
roles:
- common
vars_files:
- vars/environment.yml

Ce fichier est la racine de notre configuration Ansible. On y référence les rôles appliqués et les fichiers d’ environnement. Voici un exemple de rôle:

- name: "Remove useless packages from the cache"
apt:
autoclean: yes
force_apt_get: yes

- name: "Remove dependencies that are no longer required"
apt:
autoremove: yes
force_apt_get: yes

- name: "Update and upgrade apt packages (may take a while)"
become: true
apt:
upgrade: dist
update_cache: yes
force_apt_get: yes

- name: "Install useful packages"
  become: true
  apt: 
    name:
      - gcc
      - g++
 ...
      - zsh
      - firewalld
    state: present
    update_cache: no 

- name: ansible create directory example
file:
path: "{{ home }}/.m2"
state: directory
owner: "{{ username }}"
group: "{{ username }}"

- name: Install Maven settings.xml
copy: 
src: settings.xml
dest: "{{ home }}/.m2/settings.xml"
owner: "{{ username }}"
group: "{{ username }}"

- name: "Install Maven"
raw: "curl -sL \\"http://mirror.ibcp.fr/pub/apache/maven/maven-3/{{ maven_version }}/binaries/apache-maven-{{ maven_version }}-bin.tar.gz\\" -o /opt/apache-maven.tar.gz && tar -zxf /opt/apache-maven.tar.gz -C /opt"
become: true
become_user: root
become_method: sudo

- name: "Change Maven Rights"
file:
path: /opt/*
state: touch
modification_time: "preserve"
access_time: "preserve"
owner: "{{ username }}"
group: "{{ username }}"

Les variables d’environnement permettent de variabiliser certains champs de vos rôles. On peut trouver par exemple les versions de certains outils déployés

maven_version: 3.5.4
username: vagrant
home: /home/vagrant
docker_compose_version: 1.22.0

Il y a une quantité impressionnante de modules Ansible que l’on peut utiliser. Que ça soit pour lancer des commandes shell ou lancer des services. Contrairement à la création d’un script shell qui pourrait faire les mêmes actions à la création, on peut facilement gérer la mise à jour de la VM car Ansible détecte les modifications lors de son exécution.

Configuration spécifique pour VirtualBox

Pour VirtualBox, j’ai ajouté deux fichiers de configuration supplémentaires à la racine:

ansible.cfg

[defaults]
hostfile = hosts

hosts

[local]
localhost ansible_connection=local

Provisionning

A la création

le provisionning peut se faire au lancement de vagrant via la commande:

vagrant up

Pour faire une mise à jour

Directement dans la box, vous pouvez lancer les commandes suivantes :

sudo mount -t vboxsf vagrant /vagrant

Puis, vous pouvez lancer les commandes suivantes dans la box:

su -
cd /vagrant
export ANSIBLE_CONFIG=/vagrant
ansible-playbook site.yml

 

Original post of Littlewing.Votez pour ce billet sur Planet Libre.

Cela fait longtemps que nous l’attendions, la fondation a annoncée aujourd’hui la sortie de la nouvelle version de son micro-ordinateur, la Raspberry Pi 4 !

Alors que la fondation disait encore il y a quelques temps ne pas avoir prévu de nouvelle version avant au moins un an, la surprise viens de tomber !

RAM augmentée, processeur plus rapide, port Ethernet Gigabit, vidéo 4K, voyons ensemble les nouveautés au rendez-vous !

Voir les prix chez Kubii.fr

Jusqu’à 4 Go de RAM, une énorme amélioration

Premier point qui frappe avec cette nouvelle Raspberry Pi 4, la mémoire vive (RAM) a été considérablement augmentée, passant de 1 Go en DDR3 pour la B3+ à jusqu’à 4 Go en DDR4 pour la Pi 4 !

Cette augmentation de la RAM est la très bienvenue et devrait permettre à la Raspberry Pi de faire tourner de plus nombreuses applications en parallèle et de mieux gérer les programmes à forte consommation de mémoire, comme la vidéo ou le traitement d’images.

Si ce point est le plus marquant, il était également le plus prévisible, de nombreux concurrents de la Raspberry Pi proposant déjà ce type de caractéristiques depuis longtemps.

Point inédit jusque là, la Raspberry Pi 4 proposera plusieurs versions avec au choix 1 Go, 2 Go ou 4 Go de mémoire. Reste à voir l’impact que cela aura sur le prix.

Un nouveau processeur Cortex A72 plus puissant

Toujours dans l’optique d’améliorer la puissance de la machine, la Raspberry Pi 4 offre également un nouveau processeur. Exit le Cortex A53 des précédentes générations, la Raspberry Pi 4 sera doté d’un Cortex A72.

Cadencé à 1500 Mhz contre 1400 Mhz pour les version précédentes, ce processeur devrait également être un peu moins énergivore.

Comme précédemment, on reste bien-sur sur un processeur ARM, et plus spécifiquement un ARMv8-A en mode 64 bits.

Si ce processeur devrait ajouter un peu de peps à la Raspberry Pi 4 quand il s’agit d’effectuer des calculs, c’est surtout sur la partie vidéo qu’il apporte une énorme nouveauté !

Un nouveau GPU VideoCore VI permettant la vidéo en 4K !

En effet, plus qu’une simple augmentation de la puissance de calcul, c’est bien la partie GPU embarqué, c’est à dire la partie « carte graphique » du processeur qui change avec l’arrivé du A72 !

En effet, si le Cortex A53 embarque un GPU VideoCore IV, c’est bien un VideoCore VI qui est présent dans le nouveau Cortex A72 !

Mais alors, quelles conséquences ? Et bien là ou les précédents modèles de processeurs, et donc de Raspberry Pi, ne supportaient que la vidéo en Full HD mono-écran, la nouvelle Raspberry Pi 4 supportera la vidéo en 4K, et sur deux écrans !!!

Le support d’OpenGL 3.0 est également ajouté, ce qui devrait là aussi améliorer largement les performances de la Pi en matière de rendu graphique, et notamment d’accélération vidéo.

Concrètement, cela signifie que la Raspberry Pi devrait définitivement s’imposer comme la solution de référence pour créer des media-centers, des consoles de rétro-gaming, et toutes autres activités nécessitant du calcul graphique !

À notre sens, cette modification est clairement la plus importante puisque le traitement graphique était vraiment le plus gros point faible de la Raspberry Pi par rapport à ses concurrents !

Meilleur Ethernet, USB et HDMI !

Dernier point d’amélioration, les connectiques ont été revues et augmentées !

Ainsi, la Raspberry Pi 4 se dote d’un port Ethernet 1 Gigabit qui était attendu depuis longtemps et devrait là aussi améliorer l’usage de la Raspberry Pi en matière de multimédia, mais également pour l’utilisation comme serveur ou flux vidéo via internet.

Les ports USB ont également été revus, et deux d’entre eux sont désormais des ports USB3. Là encore, les amoureux du multimédias vont être heureux.

Le port HDMI traditionnel évolue lui aussi et laisse sa place à deux ports Mini-HDMI, permettant donc l’utilisation de la Raspberry Pi en double écran, ce que nous attendions depuis longtemps !

Enfin, même si cela est plus anecdotique, le Bluetooth passe en version 5.0 contre 4.2 pour les versions précédentes.

À noter également, si les ports GPIO restent les même, il sera désormais possible de gérer quelques ports séries supplémentaires, une bonne nouvelle pour les fans d’électronique.

Au final, combien coûte la Raspberry Pi 4 et ou l’acheter ?

Devant toutes ces nouveautés et améliorations, la question est bien entendu celle du prix. À quoi devons nous nous attendre ici ?

Comme nous pouvions nous y attendre, la fondation reste fidèle à son habitude avec un prix d’appel toujours maintenue à 35€ pour la version 1 Go de RAM.

En revanche, les autres versions de la Raspberry Pi 4, voient leur prix légèrement augmenter, à 45€ pour 2 Go de RAM, et 55€ pour 4 Go de RAM.

Alors certes, le prix augmente pour les versions « hautes gammes », mais nous profitons néanmoins de toutes les améliorations autres que la RAM sur le modèle à 1 Go, avec un prix maintenu à 35€ !

Pour l’instant là Raspberry Pi 4 n’est disponible en France que chez notre parteniaire kubii.fr.

Voir les prix chez Kubii.fr

Conclusion, une super Raspberry Pi 4 !

Au final cette nouvelle Raspberry Pi 4 s’annonce comme une excellente version porteuse de très nombreuses améliorations.

La Raspberry Pi 4 s’annonce dors et déjà comme très adaptée pour toutes les utilisations multimédias et devrait très rapidement trouver son publique.

Là fondation a su nous surprendre en donnant un gros coup de jeune à son produit phare qui commençait un peu à tourner en rond et accuser un certain retard face à ses concurrents, retard maintenant largement rattrapé !

Vous l’aurez compris, de notre coté, nous sommes ravis !

Lire l'article complet : Nouvelle Raspberry Pi 4, quelles nouveautés, quel prix, ou l’acheter ?

Original post of RaspbianFrance.Votez pour ce billet sur Planet Libre.

Pour continuer dans cette série sur comment débuter avec Git, nous avions vu dans le précédent article précisément ce que sont les branches Git. Nous allons aujourd’hui présenter pourquoi fusionner des branches et comment s’y prendre.

Mise en place

Pour cet article nous créons un dépôt distant sur notre Gitlab (comme expliqué dans la partie 1), puis nous le clonons sur notre machine locale.

$ git clone https://gitlab.com/chaica/merge-branches.git
Cloning into 'merge-branches'…
remote: Enumerating objects: 3, done.
remote: Counting objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
$ cd merge-branches/
$ ls
README.md

Notre dépôt initial contient simplement un fichier README.md, créé par Gitlab, contenant un titre en langage Markdown

$ cat README.md
# merge-branch

Nous allons maintenant ajouter un sous-titre à ce fichier pour un prochain exemple.

$ echo -e "\\n## sous-titre" >> README.md 
$ git commit README.md -m "add first subtitle"
[master 2059805] add first subtitle
 1 file changed, 2 insertions(+)

À ce niveau, nous avons donc deux commits qui constituent notre branche master, comme nous l’indique la commande git log.

$ git log
commit 20598053fb2c3e55f95e2521dfa804739abd7d8a
Author: Carl Chenet chaica@ohmytux.com
Date:   Fri Jun 21 10:22:00 2019 +0200

 add first subtitle

commit 11cb68a24bed5236972138a1211d189adb4512a8 (origin/master, origin/HEAD)
Author: Carl Chenet chaica@ohmytux.com
Date:   Fri Jun 21 08:18:56 2019 +0000

 Initial commit

Mise en place un peu longue, mais qui nous a permis de réviser quelques commandes fondamentales. Nous entrons dans le vif du sujet.

Création d’une nouvelle branche

Un client nous demande une évolution du code. Afin de ne pas toucher à la branche master qui contient le code de référence courant, nous allons compliquer maintenant un peu les choses en créant une nouvelle branche nommée branch-with-foo. Cette étape a déjà été expliquée dans la partie 4 plus en détail.

$ git checkout -b branch-with-foo
Switched to a new branch 'branch-with-foo'

Nous créons immédiatement un fichier nommé foo dans cette branche que nous ajoutons et enregistrons dans la foulée.

$ echo "this is a foo file" > foo
$ git add foo && git commit foo -m "add foo file"
[branch-with-foo d9afaa2] add foo file
 1 file changed, 1 insertion(+)
 create mode 100644 foo

Divergence des branches

Nous revenons maintenant sur master et nous créons un fichier bar que nous enregistrons aussi dans la foulée.

$ git checkout master
$ echo "this is a bar file" > bar
$ git add bar && git commit bar -m "add bar file"
[master 222c618] add bar file
 1 file changed, 1 insertion(+)
 create mode 100644 bar

Faisons une pause, nous venons de créer notre première divergence entre nos branches, nous avons créé un embranchement dans l’historique de nos commits, les deux derniers commits n’appartenant plus aux mêmes branches.

Le schéma présente la divergence entre la branche master et la branche branch-with-foo. La première contient un fichier bar, la seconde un fichier foo. Bien, il est temps de passer aux choses sérieuses.

Fuuuuuuuuuusion

Le besoin que nous avions de créer une nouvelle branche a disparu, le client a annulé le projet.

Bon, nous allons réintégrer les modifications de cette branche dans la branche master. Nous nous positionnons dans la branche master, ou d’une manière générale la branche à laquelle nous souhaitons réintégrer les modifications d’une autre, et nous passons la commande suivante :

$ git checkout master
$ git merge branch-with-foo -m "Merge branch 'branch-with-foo'"
Merge made by the 'recursive' strategy.
  foo | 1 +
  1 file changed, 1 insertion(+)
  create mode 100644 foo

La sortie de la commande nous précise ce qui s’est passé : un fichier foo (celui de la branche branch-with-foo) a été créé dans la branche courante master.

Jetons un oeil à l’historique avec la commande git log avec l’option –graph qui va nous présenter une représentation graphique de notre historique et l’option –oneline afin de rendre la commande moins verbeuse.

$ git log --graph --oneline
* 69fa060 (HEAD -> master) Merge branch 'branch-with-foo'
|\\  
| * d9afaa2 (branch-with-foo) add foo file
* |222c618 add bar file
|/  
* 2059805 add first subtitle
* 11cb68a (origin/master, origin/HEAD) Initial commit 

Cette représentation est très parlante. Au niveau de l’histoire elle va de haut en bas, le haut étant le commit le plus récent et le plus bas le plus vieux. Une étoile (*) est un commit, avec son message à droite , et le nom de la branche s’il y ambiguité.

Nous reprenons notre dessin précédent et le faisons évoluer.

Nous avons bien fusionné la branche branch-with-foo dans master. Fusion réussie.

Sauver son code et ses branches

Avant de s’arrêter aujourd’hui, n’oublions pas de pousser tout ce que nous avons fait vers notre dépôt Gitlab distant. Nous commençons par la branche master.

$ git push 
Enumerating objects: 13, done.
Counting objects: 100% (13/13), done.
Delta compression using up to 8 threads
Compressing objects: 100% (7/7), done.
Writing objects: 100% (11/11), 975 bytes | 975.00 KiB/s, done.
Total 11 (delta 2), reused 0 (delta 0)
To https://gitlab.com/chaica/merge-branches.git
   11cb68a..69fa060  master -> master

La dernière ligne indique bien que nous avons poussé depuis notre branche master locale vers notre branche master distante présent sur notre Gitlab.

Passons à la branche branch-with-foo, qui, même si elle a été fusionnée dans master, existe toujours. Pourquoi ? Car le nom de la branche branch-with-foo est un pointeur, un indicateur qui désigne le dernier commit connu de cette branche. Rien de plus.

Pour changer un peu nous varions la syntaxe de notre commande git push en utilisant l’option –all afin de pousser toutes les branches locales vers le dépot distant. Nous n’en avons qu’une ici, branch-with-foo.

$ git push --all
Total 0 (delta 0), reused 0 (delta 0)
remote: 
remote: To create a merge request for branch-with-foo, visit:
remote:   https://gitlab.com/chaica/merge-branches/merge_requests/new?merge_request%5Bsource_branch%5D=branch-with-foo
remote: 
To https://gitlab.com/chaica/merge-branches.git
[new branch]      branch-with-foo -> branch-with-foo 

Point très intéressant, nous voyons que les lignes commençant par remote: proviennent du Gitlab, qui nous indiquent comment créer une demande de fusion (Merge Request). Inutile, nous avons déjà fusionné. Mais ce sera intéressant dans le cadre du travail collaboratif. Ce sera pour un prochain article.

La dernière ligne nous confirme que nous avons bien poussé la branche locale branch-with-foo vers la branche du dépôt Gitlab distant nommée également branch-with-foo.

Conclusion

Nous avons vu aujourd’hui la fusion de branches Git. Cette opération permet de récupérer le travail réalisé dans une autre branche, en divergence du code “principal” que nous conservons – comme bonne pratique dans l’industrie en général – dans la branche master. C’est le cas le plus courant.

Vous devriez quasi systématiquement commencer par créer une nouvelle branche quand vous envisagez d’introduire du nouveau code dans un dépôt Git, afin de ne pas travailler directement vous-même dans master. Pourquoi pas ? C’est ce que nous verrons dans le prochain article de cette série.

Me suivre sur les réseaux sociaux

N’hésitez pas à me suivre directement sur les différents sociaux pour suivre au jour le jour mes différentes projets dans le Logiciel Libre :

• Mastodon : @carlchenet
• Diaspora :  @carlchenet
• Twitter : @carl_chenet

Suivre l’actualité du Logiciel Libre et Open Source francophone

Abonnez-vous au Courrier du hacker, une newsletter hebdomadaire résumant le meilleur de l’actualité francophone du Logiciel Libre et Open Source. Déjà plus de 90 numéros et 2000 abonnés.

E-mail S'abonner

The post Débuter avec Git partie 5 : fusionner des branches appeared first on Carl Chenet's Blog.

Original post of Carl Chenet.Votez pour ce billet sur Planet Libre.

Pour la 25ème semaine de l'année 2019, voici 10 liens intéressants que vous avez peut-être ratés, relayés par le Journal du hacker, votre source d’informations pour le Logiciel Libre francophone !

• Rachat de Github par Microsoft une année de flottement, mais pas pour Gitlab
• J'ai fouillé dans les données que Google conserve sur moi depuis treize ans (et rien ne lui échappe
• L’enjeu de la bataille du Libre : la réappropriation des savoirs-faire
• Nouvelle version stable de Debian "Buster" le 6 juillet 2019
• En faire plus avec la Console Javascript - Il n'y a pas que le console.log() !
• Jamendo, pour fêter la "fête de la musique" avec de la musique libre
• Jamments, l’API de commentaires pour votre site statique
• La version 2.0 de HAProxy est publiée avec de nouvelles fonctionnalités, telles que la prise en charge des environnements cloud
• Mes stats dans Hugo sans Google Analytics (Matomo)
• Faciliter la configuration d'un ordinateur portable (ou fixe) sous Debian GNU/Linux 10 (Buster)

Pour ne plus rater aucun article de la communauté francophone, voici :

• Le flux RSS du Journal du hacker
• Le compte Twitter du Journal du hacker
• Le compte Diaspora* du Journal du hacker
• Le compte Mastodon du Journal du hacker

De plus le site web du Journal du hacker est « adaptatif (responsive) ». N’hésitez pas à le consulter depuis votre smartphone ou votre tablette !

Le Journal du hacker fonctionne de manière collaborative, grâce à la participation de ses membres. Rejoignez-nous pour proposer vos contenus à partager avec la communauté du Logiciel Libre francophone et faire connaître vos projets !

Et vous ? Qu’avez-vous pensé de ces articles ? N’hésitez pas à réagir directement dans les commentaires de l’article sur le Journal du hacker :)

Original post of Journal du hacker.Votez pour ce billet sur Planet Libre.