Plusieurs comptes sur GitHub

Avant de répondre à la question de Comment gérer plusieurs comptes sur GitHub ? regardons comment GitHub effectue l'authentification.

Note: GitHub propose plusieur reponses à ce problème, mais la solution presenté ci-dessous n'y figure pas.

1) Un seul utilisateur pour tout !

Vous l’avez très certainement remarqué quand vous interagissez avec GitHub vous utilisez toujours le user git. Par exemple :

git clone git@github.com:example/test

 

Pour accéder à des repositories publics ça ne parait pas surprenant, mais c’est aussi le cas quand on clone un repo privé. Comment github fait-il pour savoir si celui qui lance la commande a le droit d’accéder à ce repository ? Comme le user est toujours le même et qu’il n’y a pas de mot de passe, c’est forcément la clé ssh qui sert à la fois pour l’identification et l’authentification.

 

Cela implique qu’une même clé ssh ne peut être associée qu’à un seul profil. Si vous tentez de réutiliser une clé déjà associé à un profil vous aurez ce type d’erreur :

Verify public key failed for Example key is already in use.

 

Il n'est pas possible d'utiliser le même email pour ouvrir plusieurs compte sur GitHub.
Si vous essayer vous obtiendrez:  Email is invalid or already taken

 

Donc:
- Une adresse email ne peut étre liée qu'a un seul compte identifié par un username, ce qui donne une url unique github.com/<username>.
- Ce username peut etre utilisé avec plusieurs clés ssh. Par contre, une clé ssh ne peut etre utilisée que par un seul username.

2) A qui est cette clé ?

Bien sûr il est impossible que quelqu’un d’autre que vous ait la même clé. Si vous avez ce message d'erreur c'est que vous avez un (vieux...) profil qui utilise déjà cette clé. Pour savoir lequel, il suffit d’initier une connexion ssh en ligne de commande en explicitant la clé à utiliser :

ssh -T -ai ~/.ssh/id_rsa git@github.com

Si la clé est connue, la réponse de GitHub sera:

> Hi XXXXXX! You've successfully authenticated,
but GitHub does not provide shell access.

 Où XXXXX est le nom du profil utilisant cette clé.

3) Jongler avec les clés

Il faut donc avoir autant de clés ssh que de profils sur GitHub. Le problème est comment indiquer quand on fait une opération avec git quelle clé doit être utilisée ? Une fois de plus c’est le fichier ~/.ssh/config qui va nous sauver. 

Il faut créer un host fictif pour chaque profil en spécifiant au moins le véritable hostname et la clé à utiliser pour ce host fictif.

cat ~/.ssh/config

Host Expl
    HostName github.com
    User git
    IdentityFile ~/.ssh/example_id_ed25519

Host Demo
    HostName github.com
    User git
    IdentityFile ~/.ssh/demo_id_rsa

 Grace à cela nous pourrons utiliser ces hosts fictifs ainsi :

git clone Expl:example/test
git clone Demo:demonstration/projet-demo

Le host fictif (Expl ou Demo) définit à la fois : le host réel (github.com), le user (git) et la clé à utiliser. Il n’est donc plus nécessaire de spécifier le user (git@Demo ou git@Expl). Il suffira donc de remplacer le classique « git@github.com » par « Expl » ou « Demo » suivant le profil que l’on veut utiliser.

    .ssh/config : Ref-1 , Ref-2

4) Confiez vos clés à un Agent-ssh

Une autre méthode consiste à charger toutes vos clés privées dans un agent ssh et laisser le protocole SSH essayer chaque clé jusqu’à ce que le serveur en accepte une. L'avantage d'un agent ssh est qu'il s'occupe de demander, si nécessaire, les pass-phrases des clés cryptées. Suivant l'agent il peut faire ça au démarrage, ou bien à la première utilisation de la clé.

- Un premier problème est que certains serveurs limitent le nombre de tentatives de connexion. Si vous avez beaucoup de clés chargées par l’agent-ssh vous risquez d’obtenir « too many authentication errors ».
- Le deuxièmes problème est quand vous avez plusieurs profils (donc plusieurs clés) sur GitHub . Comment savoir si la clé acceptée correspond au bon profil ?

Important: Pour que ssh interroge l'agent ssh il ne faut pas utiliser l'option  IdentitiesOnly dans .ssh/config

    Windows PuTTY/Pageant : Ref-1 , Ref-2 , Ref-3 
    Linux ssh-add et ssh-agent : Ref-4 , Ref-5

Résumons

Il y a trois sources possibles pour une clé privée:

a)     La clé par défaut id_rsa (ou id_ecdsa ou id_ed25519 etc…) venant du répertoire .ssh/
(méthode utilisable si on a une seule clé pour tout)

Dans les logs de  « ssh –T –v git@github.com » on trouvera cette paire de lignes Offering/Accepted :

Offering public key: C:\\Users\\bibi\\.ssh\\id_rsa RSA SHA256:GwKTTsGLCTlq…Ug
Server accepts  key: C:\\Users\\bibi\\.ssh\\id_rsa RSA SHA256:GwKTTsGLCTlq…Ug

b)     La clé associée explicitement au host fictif dans le fichier  .ssh/config
(méthode utilisable quand on doit associer une clé spécifique à certains host ou user@host)

Dans les logs de  « ssh –T –v example » on trouvera cette paire de lignes :
(rappel: example est une host fictif définit dans .ssh/config)

Offering public key: C:\\path\\to\\file RSA SHA256:GwKTTsGLCTlq…Ug explicit
Server accepts  key: C:\\path\\to\\file RSA SHA256:GwKTTsGLCTlq…Ug explicit

Notez le ‘explicit’ en fin de ligne.

c)     La clé proposée (parmi d’autres) par l’agent ssh :

Dans les logs de « ssh –T –v git@github.com » on trouvera cette paire de lignes :

Offering public key: nom_clé RSA SHA256:GwKTTsGLCTlq…Ug agent
Server accepts  key: nom_clé RSA SHA256:GwKTTsGLCTlq…Ug agent

Notez le ‘agent’ en fin de ligne.

SOLUTION

Il est évident qu’il faut de la méthode pour ne pas se mélanger les clés… 

- Le comportement par défaut de ssh n'est acceptable que si on a une une seule clé pour tout. Ce qui ne marche pas si vous avez plusieurs comptes GitHub.

- L'agent ssh est obligatoire quand les clés privées sont cryptées avec une pass-phrase. Dans ce cas il est fortement recommandé de le combiner avec la méthode suivante pour rendre le choix des clés prévisible.

- La méthode des hosts fictifs définis dans .ssh/config demande de la configuration et de modifier les url git pour éviter les ambiguités, mais c’est la seule méthode multi-clés dont le comportement est prévisible et sans risque de provoquer des « too many authentication errors ».

Donc ==>   .ssh/config  + (ssh-agent si pass-phrase)

L'utilisation du fichier .ssh/config donne accès à de très nombreuses options qui vont bien au delà du problème des profils multiples avec GiyHub.

https://www.openssh.com/

Perl 5 Search Engine

 

The Perl 5 search engine

Note: StackOverflow is excluded from the list of sites.

 

See also:  Download  Core modules  PerlDoc 

 MetaCpan  GrepCpan  CpanTesters  CpanAuthors

GitHub  DockerHub

 The index  r/perl

 

 

--- Ajouter ce search engine à Firefox ---

Qt & CMake : Add New File impossible !

Quand on crée un nouveau projet avec Qt on a le choix entre utiliser qmake, CMake ou Qbs comme gestionnaire de Build.

Qbs est déprécié depuis fin 2018, et devait disparaître avant 2020, mais en 2022 il est toujours disponible dans Qt 6 !

qmake et CMake sont donc les seuls à prendre en considérations. Malheureusement l’intégration dans Qt Designer n'est pas la même. malgré les promesses faites à l’annonce de la fin de Qbs:

Support for qmake will continue unaffected
Support for CMake will improve
Longer term, we plan to switch to CMake for building Qt itself
CMake support in Qt Creator will be further improved

En pratique, la syntaxe de CMake s'avère être trop compliquée à analyser et certaines fonctions nécessitant de modifier le fichier CMake ne sont pas active dans Qt Designer quand CMake est le gestionnaire de build.
Note: Celui qui affirme ça, Tobias Hunger, était l'un des principaux développeur de Qt Designer, et en particulier du build, de 2009 à 2020 (date du COVID et de son départ de Qt).

Exemple concret:

Une fois un projet créé avec  CMake (PRJ1_CM dans les copies d'écran ci dessous) il n'est pas possible d'utiliser les fonctions "Add Existing Files", "Add Existing Directory" et "Add Library". Alors que cela est possible avec qmake (PRJ2_QM dans les copies d’écrans), et même avec Qbs.

 

 PRJ1_CM utilise CMake. 

Un click bouton droit sur le nom du projet montre que les fonction "Add Existing Files / Directory / Library"  sont inactives (grisées)

 

 

 

 

 

 

 

 PRJ2_QM utilise qmake.

Tout fonctionne très bien avec qmake.

(avec Qbs aussi)

 

 

 

 

 

 

 

 

 

Vous noterez que même les icônes dans l’arborescence des projets CMake/qmake ne sont pas les mêmes. Les fichiers .ui (très important dans le développement d'un interface graphique) ne sont pas mis dans un groupe "Forms" spécifique comme c'est le cas avec qmake.

En résumé: tout dans le premier lien donné plus haut est faux; Qbs est toujours là et CMake n'est toujours pas mieux supporté.

Notes: Copies d’écran faite en juin 2022 avec Qt LTS 6.2.3 et Qt Designer 7.0.2

 

Toolchain Raspberry Pi pico-RP2040 sous Windows

L’installation à la main d’une toolchain (suite d’outils de développement) est toujours fastidieuse. Les choses se complexifient quand il s’agit d’une chaîne fonctionnant sur une plateforme (Windows ou Linux) mais dont le résultat est destiné à s’exécuter sur une autre plateforme (un système embarqué). On parle dans ce cas de  chaîne de développement croisée (cross-compilation).

C’est ce que nous allons voir dans ce post : Comment installer sous Windows la chaîne de développement croisée C/C++ pour le SoC RP2040 de la fondation Raspberry Pi. Ce microcontrôleur est basé sur un processeur ARM Cortex M0+. On trouve ce RP2040  sur plusieurs cartes dont la référence est la carte ‘pico’ (et pico W) de Raspberry Pi. 

Note: La procedure d'installation officielle pour Windows est basée sur l'utilisation de  Build Tools for Visual Studio (de Microsoft) ce qui peut être rebutant pour beaucoup (et surprenant de la part de Raspberry Pi)

Nous aurons deux groupes de logiciels à installer, suivit d'un phase de configuration.

1/ Les logiciels qui ne sont pas propres au développement pour RP2040/pico.
Certains de ces logiciels sont peut être déjà installés sur votre PC.Il s’agit pour nous de Cmake, Git, Python et du compilateur gcc pour Windows de MinGW-w64 (Minimal GNU for Windows).

Note: Un compilateur natif est nécessaire pour compiler deux outils du pico SDK : l'assembleur/des-assembleur pioasm et le convertisseur de format elf2uf2. Je vous propose d'utiliser le compilateur opensource gcc de MinGW-w64.

2/ Les logiciels spécifiques. Il s’agit :
  - du cross-compilateur gcc C/C++ s’exécutant sous Windows mais générant du code pour ARM,
  - du SDK propre à la plateforme pico qui inclue des librairies, du code source et des outils spécifiques à cette plateforme.
  - des exemples d'utilisation de la carte pico.

Important:

Pour installer des programmes sous Windows il faut très souvent avoir les droits administrateur. Donc attention aux configurations qui ne concernent que l'utilisateur en cours car, au moment de l’installation, c'est l'administrateur et vous ne verrez pas ensuite ces configurations avec un utilisateur normal.

1/ Outils standards

1.1/ CMake

CMake est un méta make. Il génère les fichiers de make pour Make, NMake, Ninja, Qt ...
Nous l'utiliserons pour générer des fichiers Makefile pour make.

https://cmake.org/download/    (J'utilise la version 3.23.1  Ne pas utiliser la version 3.20)
Le nom du fichier est par exemple cmake-3.23.1-windows-x86_64.msi

Cochez l'option "Add CMake to the system PATH for all users".
Pour notre usage, inutile de créer un raccourci sur le bureau. 

 

1.2/ Git

Dans l'absolu on peut se passer de Git car il est possible de télécharger le SDK et les exemples, sous forme de fichiers compressés. Mais c'est tellement plus facile de maintenir à jour le SDK et les exemples avec Git.

https://git-scm.com/download/win (J'utilise la version 2.36.1 64 bits)
Le nom du fichier est par exemple Git-2.36.1-64-bit.exe

Exécuter explicitement le programme d'installation en temps qu’administrateur sinon Git sera installé dans votre espace perso C:\Users\xxxxx\AppData\Local\Programs\Git. (j'ai horreur de ça!).

Garder les options par défaut. En particulier laisser décochée l'option "Add a Git Bash profile to Windows Terminal", à moins de savoir ce que vous faites et d'avoir lu ceci.

Le seule option que j'ai modifié est la sélection de Notepad++ comme éditeur, à la place de l'antédiluvien Vim.

La distribution de Git pour Windows inclue une version minimale de environnement GNU ce qui permet d’exécuter Git à partir d'une ligne de commande Bash. C'est l'option "Git Bash Here" du clic droit dans le gestionnaire de fichier de Windows.

Note: Avec Windows 11 l’intégration de Git dans la clic droit est cachée dans un sous menu.

 

1.3/ Python 3

Notre but est de programmer la carte pico en C/C++, pas en Python, mais Python 3 est utilisé par le SDK.

https://www.python.org/downloads/windows/     (J'utilise la version 3.10.4 64 bits)
Le nom du fichier est par exemple python-3.10.4-amd64.exe

Par défaut, et pour des raison obscures, il n'est pas possible d'installer Python 3 dans %ProgramFiles% (C'est à dire "C:\Program File\"). Python s’installe par défaut dans %LocalAppData%\Programs. c'est à dire C:\Users\xxxx\AppData\Local\Programs\Python\Python3yz. Donc, NE PAS UTILISER L'ADMINISTRATEUR.

Cocher les deux cases: "Install launcher for all users" et "Add Python 3.10 to PATH". L'ajout se fera pour l'utilisateur courant.

Si l’installateur détecte que la taille maximal d'un chemin de fichier est plafonnée à 260 caractères il proposera de faire sauter cette limite: "Disable path length limit". Il faut accepter cette optimisation. Elle est bénéfique bien au delà de Python. 

Note: Cette limite existe depuis Windows 95 et est toujours présente par défaut dans Windows 11. Mais depuis Windows 10 on peut faire sauter cette limite en mettant à 1 la valeur de la clé de registre: Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem\LongPathsEnabled

 

1.4/ MinGW-w64 (à la place de Build Tools for Visual Studio)

Le projet MinGW-w64 propose une chaîne de compilation native pour Windows basée sur le compilateur gcc. C'est ce que nous allons utiliser à la place de l’énorme Visual Studio. Les programmes générés par MinGW-w64 sont de véritables programmes Windows ne dépendant pas d'une couche d’émulation POSIX comme c'est le cas avec Cygwin.

* Soit SourceForge: https://sourceforge.net/projects/mingw-w64/files/mingw-w64/

Le Online Intaller de source forge ne marche toujours pas depuis des années!
Télécharger le build de la version 8.1.0 de x86_64-posix-sjlj
Le nom du fichier est par exemple x86_64-8.1.0-release-posix-sjlj-rt_v6-rev0.7z

* Soit GitHub https://github.com/niXman/mingw-builds-binaries/releases

Les builds proposés sont plus à jour que sur SourceForge
Télécharger le dernier build (Dérouler les blocks 'Assets'). Seule la dernière release d'une version contient les binaires.
Le nom du fichier est par exemple x86_64-12.1.0-release-posix-sjlj-rt_v10-rev3.7z 

Note: ce repo github est géré par niXman qui est l'un des développeurs de MSys2.
Si vous utilisez MSys2 vous pouvez y installer le package mingw-w64-x86_64-toolchain.

Dans les deux cas il faudra 7Zip pour le décompacter. Une fois le fichier .7z ouvert dans 7Zip drag&droper le répertoire mingw64 sur votre disque. Je vous conseille de prendre un chemin ne contenant pas d'espaces. Pour moi c'est C:/pico/
Le compilateur natif est donc dans C:/pico/mingw64/

A propos de sjlj vs seh et de posix vs win32:

Méthodes de gestion des exceptions de C++.
- sjlj = SetJump/LongJump = méthode marchant en 32 et 64 bits permettant l'interopérabilité avec des librairies pas compilées avec gcc, mais plus lent que la méthode 'seh'.
- seh = Structured Exception Handle = méthode propre à Windows.

Méthodes de gestion du multi-thread.
- posix = supporte les thread de C++11. A besoin de la librairie winpthreads.
- win32 = support natif mais incomplet de C++11

Pour plus de details...

Informatif et optionnel: Il est possible d'utiliser Mingw-w64 via MSys2 avec Visual Studio Code (donc sans Build Tools for Visual Studio)

 1.5/ Vérification

A ce state vous devez pouvoir exécuter ces 4 commandes avec succès dans une console Windows (cmd.exe), aussi bien qu'avec la ligne de commande Bash (Bouton droit dans le gestionnaire de fichier puis "Git Bash Here")

 cmake, git et python sont déjà dans le PATH. On y ajoutera gcc plus tard.

2/ Outils spécifiques

2.1/  Arm GNU Toolchain

C'est la chaîne de cross-compilation qui s’exécute sous Windows mais qui génère du code pour ARM indépendamment de tout système cible (bare-metal target). C'est ce compilateur qui compilera vos projets pour la carte pico (ou tout autre carte utilisant un processeur ARM)

https://developer.arm.com/Tools and Software/GNU Toolchain (J'utilise la version 11.2-2022.02)
Le nom du fichier est par exemple gcc-arm-11.2-2022.02-mingw-w64-i686-arm-none-eabi.exe

Note: Gcc 11 supporte complètement le standard C++17 .

Là aussi je vous conseille de modifier le path par défaut pour qu'il ne contienne pas d'espaces.
Pour moi c'est C:\Pico\arm-none-eabi\11.2_2022.02  

En fin d’installation cocher les trois cases: "Lauch gccvar.bat", "Add path to environment" et "Add registry information"

2.2 Pico SDK & Examples

C'est ici que nous allons apprécier d'avoir installer Git.
Au préalable il faut choisir un répertoire où stocker le SDK de la carte pico et les exemples.
Je vous conseille de prendre un chemin ne contenant pas d'espaces. Donc pas dans "C:\Users\machin\My Documents\". Pour moi c'est "C:\Pico\"

Ouvrir une console Windows (cmd.exe) dans ce répertoire et taper ces commandes afin de cloner avec Git le SDK, puis les sous modules du SDK (cyw43-driver, lwip et tinyusb), puis les exemples:

  cd \Pico
  git clone -b master https://github.com/raspberrypi/pico-sdk.git 

  cd pico-sdk 
  git submodule update --init
  cd ..

  git clone -b master https://github.com/raspberrypi/pico-examples.git

L’arborescence dans mon répertoire C:\Pico\ est donc:

C:\Pico\
├─── arm-none-eabi\
├─── mingw64\
├─── pico-examples\
└─── pico-sdk\

Plus tard, je mettrai mes projets perso dans C:\Pico\pico-prj\

3/ Configuration

Pour que tous ces outils fonctionnent ensemble il ne reste plus qu'un peut de configuration à faire.

Deux variables d’environnement à créer au niveau système (ou utilisateur):

PICO_SDK_PATH=C:\Pico\pico-sdk
PICO_TOOLCHAIN_PATH=C:\arm-none-eabi\11.2_2022.02\bin

Six chemins à ajouter au path système (ou utilisateur):

CMake et Git sont déjà dans le path système, et Python est dans le path utilisateur. Il ne reste plus qu'a ajouter mingw64 et la toolchain ARM (il se peut que la toolchain ARM soit dans le path de l'administrateur, ce qui est inutile):

C:\Program Files\CMake\bin
C:\Program Files\Git\cmd

C:\Users\xxxx\AppData\Local\Programs\Python\Python310\
C:\Users\xxxx\AppData\Local\Programs\Python\Python310\Scripts\

C:\Pico\mingw64\bin
C:\Pico\arm-none-eabi\11.2_2022.02\bin

Après cette mise à jour du path fermer toutes les consoles et ouvrir une nouvelle console Windows (cmd.exe), CMake, Git et Python doivent toujours être accessibles en ligne de commande (Cf. plus haut) mais aussi les deux compilateurs et le make inclue avec mingw.

Ainsi que:

4/ Build !

Nous pouvons enfin construire notre premier projet!

Créer un répertoire build commun à tous les exemples: (Pour moi c'est C:\Pico\pico-exemple\build\)
Ouvrir une console Windows (cmd.exe) dans ce répertoire de build et exécuter cette commande pour construire tous les Makefiles pour tous les exemples: (ne pas oublier les .. )

cmake -G "MinGW Makefiles" ..

 
Puis, aller dans le sous-répertoire de build dédié à l'exemple le plus simple: blink, et le construire:

cd blink
makegw32-make.exe

Et voila ! Il ne reste plus qu'a faire un drag & drop du fichier blink.uf2 sur la carte pico.

blink.elf Error -1073741511

En principe on doit pouvoir exécuter ces commandes aussi depuis la ligne de commande "Git bash Here"

cd /c/Pico/pico-exemples
mkddir build
cd build
cmake -G "MinGW Makefiles" ..
cd blink
makegw32-make.exe

Mais à la fin on obtient cette erreur: Error -1073741511

...
[100%] Linking CXX executable blink.elf
mingw32-make:[blink\CMakeFiles\blink.dir\build.make:811: blink/blink.elf] Error -1073741511
mingw32-make: Deleting file 'blink/blink.elf'
mingw32-make: CMakeFiles\Makefile2:4223: blink/CMakeFiles/blink.dir/all] Error 2
mingw32-make: [Makefile:90: all] Error 2

Le code -1073741511 doit être interprété en hexa: 0xC0000139. Dans le monde Microsoft ça signifie Exception: Entry Point Not Found.

Une analyse avec Process Monitor montre que c'est le programme elf2uf2.exe qui avorte avec le code 0xC0000139 ce qui provoque l’arrêt de mingw32-make.

Toujours avec Process Monitor on peut voir que quand elf2uf2.exe n’échoue pas il est lié à des librairies c++ qui viennent de C:\Pico\mingw64\bin\ et quand il échoue il est lié avec des librairies qui viennent d'ailleurs. Dans mon cas le lien se fait avec des librairies venant de C:\Program Files\Git\mingw64\bin\

Une solution 'à la va vite' pour résoudre ce problème d'ordre de linkage est de copier la librairie C:\Pico\mingw64\bin\libstdc++-6.dll dans le même répertoire que elf2uf2.exe, donc pour moi dans C:\Pico\pico-examples\build\elf2uf2\ Ce n'est pas très propre mais ça marche tant que l'on ne supprime pas le répertoire build ou que l'on ne réinstalle pas les exemples.

Se simplifier la vie:

Cmake est utilisé pour (re)construire les fichiers Makefile de make. Pour générer les binaires ARM de notre projet nous exécutons donc make. Mais il se nome en fait mingw32-make.

Pour taper simplement 'make'  au lieu de 'mingw32-make' on peut ajouter un fichier make.bat dans le même répertoire que mingw32-make.exe. Pour moi c'est dans C:\Pico\mingw64\bin\

Ce fichier make.bat contient une seule ligne:

mingw32-make %* 

On peut faire la même chose pour la ligne de commande bash de Git.
Dans votre répertoire personnel de Windows (C:\Users\moi\) créer le fichier .bash_profile
avec cette simple ligne (ou ajouter la si le fichier existe deja)

alias make=mingw32-make.exe

Si vous craignez un conflit utilisez un autre nom que make, mais plus court que mingw32-make. Par exemple pmake pour pico make, ou pmk... à vous de choisir.

 Beaucoup d'autres optimisations sont possibles pour se simplifier la vie ;-)

Références:

Autre posts (en Anglais) décrivant l’installation de cette Toolchain pour Pico/RP2040:

vanhunteradams (avec visual studio)

shawnhymel (sans visual studio, mais avec vscode)

shabaz (avec visual studio)

neilk (avec visual studio)