🥇Mon cinquième jour avec Haiku : portons un peu de programmes

TL;DR: Un néophyte a vu Haiku pour la première fois et essaie de porter certains programmes du monde Linux.

Mon premier programme porté pour Haiku, empaqueté dans son format hpkg

Récemment j'ai découvert Haiku, un système d'exploitation pour PC étonnamment bon.
Aujourd'hui, je vais apprendre à porter de nouveaux programmes sur ce système d'exploitation. L'accent sera mis sur la description de ma première expérience de transition vers Haiku du point de vue d'un développeur Linux. Je m'excuse pour les erreurs idiotes commises en cours de route, car il ne s'est écoulé qu'une semaine depuis que j'ai démarré Haiku pour la première fois.

Je veux atteindre trois objectifs :

Porter une application CLI simple
Porter une application GUI sur Qt
Puis les empaqueter au format hpkg (puisque je pense encore à adapter AppDir et AppImage pour Haiku…)

Commencçons. Dans les sections documentation et développement, ainsi que dans le wiki de HaikuPorts, j'ai trouvé la direction nécessaire. Il existe même un livre en ligne au format PDF BeOS : Portage d'applications Unix.
467 pages — et cela date de 1997 ! Regarder à l'intérieur est effrayant, mais j'espère le meilleur. Les paroles du développeur sont encourageantes : « ça prend du temps, car BeOS n'était pas POSIX-compatible », mais Haiku l'est « en grande partie » déjà.

Portage d'une application CLI simple

Ma première pensée était de porter l'application avrdude, mais il s'avère que cela a déjà été fait il y a longtemps.

Première tentative : rien à voir

Ce que je ne parviens pas à comprendre, c'est qu'il y a déjà plus de 10 ans, des applications sont portées pour Haiku — alors que l'OS lui-même n'a même pas encore de version 1.0.

Deuxième tentative : besoin de réécrire

Ainsi, je vais utiliser ptouch-770, CLI pour contrôler l'imprimante Brother P-Touch 770 sur laquelle j'imprime des étiquettes.
J'imprime diverses étiquettes avec, et vous l'avez peut-être déjà vue dans l'article précédent. Un peu plus tôt, j'ai écrit un petit programme wrapper avec GUI en Python (puisqu'il est en Gtk+ — je vais devoir le réécrire, ce qui est une bonne occasion d'apprendre).

Imprimante d'étiquettes Brother P-Touch 770. Est-ce qu'elle fonctionnera sous Haiku ?

Le gestionnaire de paquets Haiku connaît les bibliothèques et les commandes, donc si je reçois le message « can't find libintl » au démarrage configure — je lance simplement pkgman install devel:libintl et le paquet requis sera trouvé. De même pkgman install cmd:rsync. Bref.

À l'exception des cas où ça ne fonctionne pas :

/Haiku/home> git clone https://github.com/probonopd/ptouch-770
Cloning into 'ptouch-770'...
remote: Enumerating objects: 134, done.
remote: Total 134 (delta 0), reused 0 (delta 0), pack-reused 134
Receiving objects: 100% (134/134), 98.91 KiB | 637.00 KiB/s, done.
Resolving deltas: 100% (71/71), done./Haiku/home> cd ptouch-770//Haiku/home/ptouch-770> make
gcc -Wall -O2 -c -o ptouch-770-write.o ptouch-770-write.c
ptouch-770-write.c:28:10: fatal error: libudev.h: No such file or directory
 #include <libudev.h>
          ^~~~~~~~~~~
compilation terminated.
Makefile:16: recipe for target 'ptouch-770-write.o' failed
make: *** [ptouch-770-write.o] Error 1/Haiku/home/ptouch-770> pkgman install devel:libudev
100% repochecksum-1 [65 bytes]
Validating checksum for Haiku...done.
100% repochecksum-1 [64 bytes]
Validating checksum for HaikuPorts...done.
*** Failed to find a match for "devel:libudev": Name not found/Haiku/home/ptouch-770> pkgman install devel:udev
100% repochecksum-1 [65 bytes]
Validating checksum for Haiku...done.
100% repochecksum-1 [64 bytes]
Validating checksum for HaikuPorts...done.
*** Failed to find a match for "devel:udev": Name not found

Peut-être qu'udev est trop linuxien, donc il n'existe pas pour Haiku. Cela signifie qu'il faut modifier le code source que j'essaie de compiler.
Eh bien, on ne peut pas sauter au-dessus de sa tête, et je ne sais même pas par où commencer.

Troisième tentative

Ce serait bien d'avoir tmate pour Haiku, alors je permettrai aux développeurs de Haiku de se connecter à ma session terminale - au cas où quelque chose ne se passerait pas comme prévu. Les instructions sont assez simples:

./autogen.sh
./configure
make
make install

Ça a l'air pas mal, alors pourquoi ne pas essayer ça sur Haiku ?

/Haiku/home> git clone https://github.com/tmate-io/tmate/Haiku/home> cd tmate//Haiku/home/tmate> ./autogen.sh
(...)/Haiku/home/tmate> ./configure
(...)
checking for libevent... no
checking for library containing event_init... no
configure: error: "libevent not found"/Haiku/home/tmate> pkgman install devel:libevent
(...)
The following changes will be made:
  in system:
    install package libevent21-2.1.8-2 from repository HaikuPorts
    install package libevent21_devel-2.1.8-2 from repository HaikuPorts
Continue? [yes/no] (yes) :
100% libevent21-2.1.8-2-x86_64.hpkg [965.22 KiB]
(...)
[system] Done.checking for ncurses... no
checking for library containing setupterm... no
configure: error: "curses not found"/Haiku/home/tmate> pkgman install devel:libcurses
(...)
*** Failed to find a match for "devel:libcurses": Name not found/Haiku/home/tmate> pkgman install devel:curses
(...)
*** Failed to find a match for "devel:curses": Name not found

À ce stade, j'ouvre HaikuDepot et je cherche curses.
J'ai trouvé quelque chose qui m'a donné une piste pour une requête plus précise :

/Haiku/home/tmate> pkgman install devel:libncurses
(...)
100% ncurses6_devel-6.1-1-x86_64.hpkg [835.62 KiB]
(...)./configure
(...)
checking for msgpack >= 1.1.0... no
configure: error: "msgpack >= 1.1.0 not found"/Haiku/home/tmate> pkgman install devel:msgpack
(...)
*** Failed to find a match for "devel:msgpack": Name not found/Haiku/home/tmate> pkgman install devel:libmsgpack
(...)
*** Failed to find a match for "devel:libmsgpack": Name not found

Je suis encore retourné sur HaikuDepot, et bien sûr, j'ai trouvé devel:msgpack_c_cpp_devel. Quels sont ces noms bizarres ?

/Haiku/home/tmate> pkgman install devel:msgpack_c_cpp_devel
100% repochecksum-1 [65 bytes]
Validating checksum for Haiku...done.
100% repochecksum-1 [64 bytes]
Validating checksum for HaikuPorts...done.
*** Failed to find a match for "devel:msgpack_c_cpp_devel": Name not found# Why is it not finding it? To hell with the "devel:".../Haiku/home/tmate> pkgman install msgpack_c_cpp_devel
(...)
The following changes will be made:
  in system:
    install package msgpack_c_cpp-3.1.1-1 from repository HaikuPorts
    install package msgpack_c_cpp_devel-3.1.1-1 from repository HaikuPorts
Continue? [yes/no] (yes) :
(...)/Haiku/home/tmate> ./configure
(...)
checking for libssh >= 0.8.4... no
configure: error: "libssh >= 0.8.4 not found"/Haiku/home/tmate> pkgman install devel:libssh/Haiku/home/tmate> make
(...)
In file included from /boot/system/develop/headers/msgpack.h:22,
                 from tmate.h:5,
                 from cfg.c:29:
/boot/system/develop/headers/msgpack/vrefbuffer.h:19:8: error: redefinition of struct iovec'
 struct iovec {
        ^~~~~
In file included from tmux.h:27,
                 from cfg.c:28:
/boot/system/develop/headers/posix/sys/uio.h:12:16: note: originally defined here
 typedef struct iovec {
                ^~~~~
Makefile:969: recipe for target 'cfg.o' failed
make: *** [cfg.o] Error 1

À ce stade, j'ai réalisé que porter un programme sur Haiku nécessite beaucoup plus de connaissances que celles nécessaires pour une simple recompilation.
J'ai parlé avec des développeurs sympathiques de Haiku, il s'avère qu'il y a un bug dans msgpack, et après quelques minutes, je vois un patch dans HaikuPorts. Je vois de mes propres yeux le paquet corrigé se construit ici (buildslave - machines virtuelles).

La construction du msgpack corrigé sur buildmaster

Au passage, j'envoie le patch à l'upstream pour ajouter le support de Haiku dans msgpack.

Cinq minutes plus tard, le msgpack mis à jour est déjà disponible sur Haiku :

/Haiku/home/tmate> pkgman update
(...)
The following changes will be made:
  in system:
    upgrade package msgpack_c_cpp-3.1.1-1 to 3.2.0-2 from repository HaikuPorts
    upgrade package msgpack_c_cpp_devel-3.1.1-1 to 3.2.0-2 from repository HaikuPorts
Continue? [yes/no] (yes) : y
100% msgpack_c_cpp-3.2.0-2-x86_64.hpkg [13.43 KiB]
(...)
[system] Done.

Étonnamment bien. Je l'ai dit ?!

Je retourne à la tâche originale :

/Haiku/home/tmate> make
(...)
In file included from tmux.h:40,
                 from tty.c:32:
compat.h:266: warning: "AT_FDCWD" redefined
 #define AT_FDCWD -100

In file included from tty.c:25:
/boot/system/develop/headers/posix/fcntl.h:62: note: this is the location of the previous definition
 #define AT_FDCWD  (-1)  /* CWD FD for the *at() functions */

tty.c: In function 'tty_init_termios':
tty.c:278:48: error: 'IMAXBEL' undeclared (first use in this function); did you mean 'MAXLABEL'?
  tio.c_iflag &= ~(IXON|IXOFF|ICRNL|INLCR|IGNCR|IMAXBEL|ISTRIP);
                                                ^~~~~~~
                                                MAXLABEL
tty.c:278:48: note: each undeclared identifier is reported only once for each function it appears in
Makefile:969: recipe for target 'tty.o' failed
make: *** [tty.o] Error 1

Maintenant, il semble que msgpack ne soit pas en cause. Je commente IMAXLABEL dans tty.c donc :

tio.c_iflag &= ~(IXON|IXOFF|ICRNL|INLCR|IGNCR|/*IMAXBEL|*/ISTRIP);

Résultat :

osdep-unknown.c: Dans la fonction 'osdep_get_cwd':
osdep-unknown.c:32:19: avertissement : paramètre inutilisé 'fd' [-Wunused-parameter]
 osdep_get_cwd(int fd)
               ~~~~^~
make: *** Pas de règle pour faire la cible 'compat/forkpty-unknown.c', nécessaire par 'compat/forkpty-unknown.o'.  Arrêt.

Eh bien, ça recommence... À propos :

/Haiku/home/tmate> ./configure | grep -i OPENAT
checking for openat... no

mr. waddlesplash indique où chercher :

/Haiku/home/tmate> ./configure LDFLAGS="-lbsd"
(...)/Haiku/home/tmate> make
(...)
In file included from tmux.h:40,
                 from window.c:31:
compat.h:266: warning: "AT_FDCWD" redefined
 #define AT_FDCWD -100

In file included from window.c:22:
/boot/system/develop/headers/posix/fcntl.h:62: note: this is the location of the previous definition
 #define AT_FDCWD  (-1)  /* CWD FD for the *at() functions */

make: *** No rule to make target 'compat/forkpty-unknown.c', needed by 'compat/forkpty-unknown.o'.  Stop.

Ici j'ai posté config.log.

On m'a expliqué qu'il y a quelque chose d'autre dans libnetwork pour libresolv sur Haiku. Apparemment, il faut modifier le code davantage. Je dois réfléchir...

find . -type f -exec sed -i -e 's|lresolv|lnetwork|g'  {} ;

La question éternelle : que se passe-t-il.

/Haiku/home/tmate> ./configure LDFLAGS="-lbsd"
(...)/Haiku/home/tmate> make
(...)
# Success!# Let's run it:/Haiku/home/tmate> ./tmate
runtime_loader: /boot/system/lib/libssh.so.4.7.2: Could not resolve symbol '__stack_chk_guard'
resolve symbol "__stack_chk_guard" returned: -2147478780
runtime_loader: /boot/system/lib/libssh.so.4.7.2: Troubles relocating: Symbol not found

La même chose, mais en profil. J'ai googlé et trouvé ça. Si j'ajoute -lssp cela aide "parfois", je teste :

/Haiku/home/tmate> ./configure LDFLAGS="-lbsd -lssp"
(...)/Haiku/home/tmate> make
(...)/Haiku/home/tmate> ./tmate

Wow ! Ça se lance ! Mais...

[tmate] échec de recherche ssh.tmate.io. Nouvelle tentative dans 2 secondes (échec irréparable dans la résolution de nom)

Je vais tenter de déboguer, le fichier est ici:

/Haiku/home/tmate> strace -f ./tmate >log 2>&1

"Mauvais identifiant de port" - c'est déjà comme une carte de visite haiku.Peut-être que quelqu'un sait ce qui ne va pas et comment le corriger ? Si c'est le cas, je mettrai à jour l'article. Lien vers GitHub.

Le portage d'une application GUI sur Qt.

Je choisis une simple application QML.

/> cd /Haiku/home//Haiku/home> git clone https://github.com/probonopd/QtQuickApp
/Haiku/home/QtQuickApp> qmake .
/Haiku/home/QtQuickApp> make
/Haiku/home/QtQuickApp> ./QtQuickApp # Works!

Vraiment simple. Moins d'une minute !

Emballage d'applications en hpkg utilisant haikuporter et haikuports.

Par où commencer ? Il n'y a pas de documentation simple, je vais sur le canal #haiku sur irc.freenode.net et j'entends :

Commande package — méthode de création de paquets de bas niveau. Dans la plupart des cas, il suffit de PackageInfo, comme décrit dans la section « En faire un véritable paquet .hpkg »
Je dois faire quelque chose comme ça
On peut utiliser hpkg-creator (j'ai un crash, rapport d'erreur)

Je ne sais pas quoi faire. Je pense que j'ai besoin d'un guide pour débutants du type « Bonjour, le Monde ! », idéalement une vidéo. Ce serait bien aussi d'avoir une introduction conviviale à HaikuPorter, comme c'est fait dans GNU hello.

Je lis ce qui suit :

haikuporter est un outil pour créer des projets de paquets communs pour Haiku. Il utilise le dépôt HaikuPorts comme base pour tous les paquets. Pour créer des paquets, on utilise des recettes haikuporter.

En outre, je découvre que :

Il n'est pas nécessaire de conserver les recettes dans le dépôt HaikuPorts. On peut créer un autre dépôt, y placer les recettes et ensuite indiquer à haikuporter de s'y référer.

C'est exactement ce dont j'ai besoin — à moins de chercher un moyen de rendre le paquet public. Mais c'est un sujet pour un autre post.

Installation de haikuporter et haikuports

cd /boot/home/
git clone https://github.com/haikuports/haikuporter --depth=50
git clone https://github.com/haikuports/haikuports --depth=50
ln -s /boot/home/haikuporter/haikuporter /boot/home/config/non-packaged/bin/ # le rendre exécutable de n'importe où
cd haikuporter
cp haikuports-sample.conf /boot/home/config/settings/haikuports.conf
sed -i -e 's|/mydisk/haikuports|/boot/home/haikuports|g' /boot/home/config/settings/haikuports.conf

Écriture de recette

SUMMARY="Application démonstration QtQuick"
DESCRIPTION="QtQuickApp est une application démonstration QtQuick pour tester le portage et l'emballage sous Haiku"
HOMEPAGE="https://github.com/probonopd/QtQuickApp"
COPYRIGHT="Aucun"
LICENSE="MIT"
REVISION="1"
SOURCE_URI="https://github.com/probonopd/QtQuickApp.git"
#PATCHES=""
ARCHITECTURES="x86_64"
PROVIDES="
    QtQuickApp = $portVersion
"
REQUIRES="
    haiku
"
BUILD_REQUIRES="
    haiku_devel
    cmd:qmake
"BUILD()
{
    qmake .
    make $jobArgs
}INSTALL()
{
    make install
}

Construction de la recette

Je sauvegarde le fichier sous le nom QtQuickApp-1.0.recipe, puis je lance haikuporter -S ./QuickApp-1.0.recipe. Les dépendances pour tous les paquets dans le dépôt haikuports, ce qui prend un certain temps. Je vais prendre un café.

Et pourquoi cette vérification doit-elle être faite sur ma machine locale, plutôt que de manière centralisée sur le serveur une fois pour tous ?

Selon Mr. waddlesplash :

Avec le fait qu'on peut écraser n'importe quel fichier dans le dépôt 😉 On peut un peu optimiser cela en calculant les informations nécessaires quand il le faut, car les dernières modifications sont assez rares.

~/QtQuickApp> haikuporter QtQuickApp-1.0.recipe
Vérification si des informations de dépendance doivent être mises à jour ...
Recherche d'informations de dépendance obsolètes ...
Erreur : QtQuickApp introuvable dans le dépôt

Il s'avère qu'il n'existe pas de fichier de recette standard contenant le code source de votre application. Il doit être conservé dans le dépôt au format HaikuPorts.

~\/QtQuickApp> mv QtQuickApp-1.0.recipe ..\/haikuports\/app-misc\/QtQuickApp\/ 
~\/QtQuickApp> ..\/haikuport 
~\/QtQuickApp> haikuporter -S QtQuickApp-1.0.recipe

Ce fait rend la compilation plus encombrante. Je n'aime pas trop cela, mais je pense que c'est nécessaire pour que, à terme, tout le logiciel open source soit disponible dans HaikuPorts.

Je reçois le message suivant :

~\/QtQuickApp> haikuporter -S QtQuickApp-1.0.recipe
Vérification s'il y a des informations de dépendance à mettre à jour ...
        mise à jour des informations de dépendance de QtQuickApp-1.0
Recherche d'informations de dépendance périmées ...
Erreur : QtQuickApp-1.0.recipe introuvable dans l'arborescence.

Qu'est-ce qui ne va pas ? Après avoir lu sur irc, je fais :

~\/QtQuickApp> haikuporter -S QtQuickApp
Vérification s'il y a des informations de dépendance à mettre à jour ...
        mise à jour des informations de dépendance de QtQuickApp-1.0
Recherche d'informations de dépendance périmées ...
----------------------------------------------------------------------
app-misc::QtQuickApp-1.0
        \/boot\/home\/haikuports\/app-misc\/QtQuickApp\/QtQuickApp-1.0.recipe
----------------------------------------------------------------------Téléchargement : https:\/\/github.com\/probonopd\/QtQuickApp.git ...
--2019-07-14 16:12:44--  https:\/\/github.com\/probonopd\/QtQuickApp.git
Résolution de github.com... 140.82.118.3
Connexion à github.com|140.82.118.3|:443... connecté.
Requête HTTP envoyée, attente de réponse... 301 Moved Permanently
Emplacement : https:\/\/github.com\/probonopd\/QtQuickApp [suivi]
--2019-07-14 16:12:45--  https:\/\/github.com\/probonopd\/QtQuickApp
Réutilisation de la connexion existante à github.com:443.
Requête HTTP envoyée, attente de réponse... 200 OK
Longueur : non spécifié [text\/html]
Sauvegarde dans : ‘\/boot\/home\/haikuports\/app-misc\/QtQuickApp\/download\/QtQuickApp.git’
     0K .                                                     1.34M=0.06s
2019-07-14 16:12:45 (1.34 Mo/s) - ‘\/boot\/home\/haikuports\/app-misc\/QtQuickApp\/download\/QtQuickApp.git’ sauvegardé [90094]
Validation de la somme de contrôle de QtQuickApp.git
Avertissement : ----- MODÈLE DE SOMME DE VÉRIFICATION -----
Avertissement : CHECKSUM_SHA256="cf906a65442748c95df16730c66307a46d02ab3a12137f89076ec7018d8ce18c"
Avertissement : -----------------------------
Erreur : Aucune somme de contrôle trouvée dans la recette !

Une question intéressante se pose. Si j'ajoute une somme de contrôle à la recette, correspondra-t-elle au dernier commit git pour l'intégration continue ? (Le développeur confirme : « Ça ne marchera pas. Les recettes sont conçues pour être relativement stables »).

Pour rire, ils ajoutent à la recette :

CHECKSUM_SHA256="cf906a65442748c95df16730c66307a46d02ab3a12137f89076ec7018d8ce18c"

Cela ne me convient toujours pas :

~\/QtQuickApp> haikuporter -S QtQuickApp
Vérification s'il y a des informations de dépendance à mettre à jour ...
        mise à jour des informations de dépendance de QtQuickApp-1.0
Recherche d'informations de dépendance périmées ...
----------------------------------------------------------------------
app-misc::QtQuickApp-1.0
        \/boot\/home\/haikuports\/app-misc\/QtQuickApp\/QtQuickApp-1.0.recipe
----------------------------------------------------------------------
Téléchargement de la source pour QtQuickApp.git ignoré
Validation de la somme de contrôle de QtQuickApp.git
Déballage de la source de QtQuickApp.git
Erreur : Type d'archive non reconnu dans le fichier \/boot\/home\/haikuports\/app-misc\/QtQuickApp\/download\/QtQuickApp.git

Pourquoi cela ? C'est un dépôt git, le code est déjà là, rien à décompresser. De mon point de vue, l'outil devrait être suffisamment intelligent pour ne pas rechercher un décompresseur lorsqu'il a une URL de GitHub.

Peut-être que cela fonctionnera avec uri git://

SOURCE_URI="git://github.com/probonopd/QtQuickApp.git"

Maintenant, il se plaint comme ceci :

Téléchargement : git://github.com/probonopd/QtQuickApp.git ...
Erreur : Le téléchargement depuis des sources non sécurisées est désactivé dans haikuports.conf !

Hmm, pourquoi tout est si compliqué, pourquoi ne peut-on pas « juste travailler » ? Après tout, il n'est pas si rare de pouvoir assembler quelque chose depuis GitHub. Les outils qui fonctionnent immédiatement, sans nécessiter de configuration, ou ce que j'appelle « bricolage » sont bien meilleurs.

Peut-être que cela fonctionnera comme ça :

SOURCE_URI="git+https://github.com/probonopd/QtQuickApp.git"

Non. Je reçois toujours cette erreur bizarre et je fais comme décrit ici

sed -i -e 's|#ALLOW_UNSAFE_SOURCES|ALLOW_UNSAFE_SOURCES|g' /boot/home/config/settings/haikuports.conf

Je progresse un peu plus loin, mais pourquoi cela me crie dessus (GitHub n'est pas sécurisé !) et essaie encore de décompresser quelque chose.

Selon mr. waddlesplash:

Eh bien, c'était dû au désir de vérifier l'intégrité des données reçues pour la construction. Une des options est de vérifier la somme de contrôle de l'archive, mais on peut aussi hachage des fichiers individuels, ce qui ne sera pas implémenté car cela prend beaucoup plus de temps. C'est probablement ce qui cause la « non-sécurité » de git et des autres VCS. Cela sera probablement toujours comme ça, car créer une archive sur GitHub est assez facile et souvent plus rapide. Et à l'avenir, peut-être que le message d'erreur ne sera pas aussi criard… (nous ne fusionnons plus de telles recettes dans HaikuPorts).

~QtQuickApp> haikuporter -S QtQuickApp
Vérification si des informations de dépendance doivent être mises à jour ...
Recherche d'infos de dépendance obsolètes ...
----------------------------------------------------------------------
app-misc::QtQuickApp-1.0
        /boot/home/haikuports/app-misc/QtQuickApp/QtQuickApp-1.0.recipe
----------------------------------------------------------------------Téléchargement : git+https://github.com/probonopd/QtQuickApp.git ...
Avertissement : LES SOURCES NON SÉCURISÉES SONT MAUVAISES ET NE DOIVENT PAS ÊTRE UTILISÉES EN PRODUCTION
Avertissement : VEUILLEZ PASSER À UN TÉLÉCHARGEMENT D'ARCHIVE STATIQUE AVEC SOMME DE CONTRÔLE AU PLUS VITE !
Clonage dans le dépôt nu '/boot/home/haikuports/app-misc/QtQuickApp/download/QtQuickApp.git'...
Décompression de la source de QtQuickApp.git
tar : /boot/home/haikuports/app-misc/QtQuickApp/work-1.0/sources/QtQuickApp-1.0 : Impossible d'ouvrir : Aucun fichier ou répertoire de ce type
tar : L'erreur n'est pas récupérable : sortie maintenant
La commande 'git archive HEAD | tar -x -C "/boot/home/haikuports/app-misc/QtQuickApp/work-1.0/sources/QtQuickApp-1.0"' a renvoyé un état de sortie non nul 2

Par habitude, je vais demander aux bonnes personnes sur le canal #haiku sur le réseau irc.freenode.net. Et que ferais-je sans eux ? Après un conseil, j'ai compris qu'il fallait utiliser :

srcGitRev="d0769f53639eaffdcd070bddfb7113c04f2a0de8"
SOURCE_URI="https://github.com/probonopd/QtQuickApp/archive/$srcGitRev.tar.gz"
SOURCE_DIR="QtQuickApp-$srcGitRev"
CHECKSUM_SHA256="db8ab861cfec0ca201e9c7b6c0c9e5e828cb4e9e69d98e3714ce0369ba9d9522"

D'accord, il est clair maintenant ce que cela fait — il télécharge une archive avec les sources d'une révision particulière. C'est un peu idiot, à mon avis, et pas tout à fait ce que je voulais, à savoir — télécharger la dernière révision de la branche master.

L'un des développeurs a expliqué cela ainsi :

Nous avons notre propre CI, donc tout ce qui est placé dans le dépôt haikuports sera empaqueté pour tous les utilisateurs, et nous ne voulons pas prendre de risques en construisant et en livrant « toutes les dernières versions en amont ».

Compris ! Quoi qu'il en soit, ça a donné ceci :

attente d'activation du package de construction QtQuickApp-1.0-1
attente d'activation du package de construction QtQuickApp-1.0-1
attente d'activation du package de construction QtQuickApp-1.0-1
attente d'activation du package de construction QtQuickApp-1.0-1
attente d'activation du package de construction QtQuickApp-1.0-1
(...)

Cela se répète ainsi à l'infini. Apparemment, c'est une erreur (y a-t-il un ticket ? Je n'ai pas trouvé).

Avec haikuporter updates-testing haikuports On ne ressent pas un niveau de « ça fonctionne juste », mais en tant que développeur, certaines choses dans le travail avec Haiku me plaisent. Dans l'ensemble, cela ressemble au Open Build Service — un ensemble d'outils pour construire des builds Linux : extrêmement puissant, avec une approche systématique, mais excessif pour ma petite application de type « hello world ».

Encore une fois, selon M. waddlesplash :

En effet, HaikuPorter est très strict par défaut (en plus, il y a un mode lint ainsi qu'un mode strict, qui le rendent encore plus strict !), mais seulement parce qu'il crée des paquets qui fonctionneront, et non pas simplement pour créer des paquets. C'est pourquoi il se plaint des dépendances non déclarées, des bibliothèques mal importées, des versions incorrectes, etc. L'objectif est de détecter tous les problèmes, y compris ceux à venir, avant que l'utilisateur ne s'en aperçoive (c'est pourquoi il n'a pas été possible d'installer avrdude, car la recette indiquait en fait une dépendance). Les bibliothèques ne sont pas simplement des paquets séparés et même pas des versions SO définies. HaikuPorter veille à ce que tout cela soit respecté dans les recettes elles-mêmes pour éviter les erreurs d'exécution.

En principe, un tel niveau de rigueur est justifié lors de la création d'un système d'exploitation, mais il me semble excessif pour une application « hello world ». J'ai décidé d'essayer autre chose.

Création d'applications au format hpkg, en utilisant la commande « package create »

Peut-être que cette simple instruction me conviendrait mieux ?

mkdir -p apps/
cp QtQuickApp apps/cat >  .PackageInfo <<EOF
name QtQuickApp
version 1.0-1
architecture x86_64

summary "Application de démonstration QtQuick"
description "QtQuickApp est une application de démonstration QtQuick pour tester le portage et l'emballage de Haiku"

packager "probono"
vendor "probono"

copyrights "probono"
licenses "MIT"

provides {
  QtQuickApp = 1.0-1
}requires {
  qt5
}
EOFpackage create -b QtQuickApp.hpkg
package add QtQuickApp.hpkg apps# Voir ci-dessous si vous souhaitez également que l'application
# apparaisse dans le menu

Étonnamment rapide, étonnamment simple, étonnamment efficace. Juste comme j'aime, incroyable !

Installation — quoi et où ?

J'ai déplacé le fichier QtQuickApp.hpkg dans ~ /config/packages, en utilisant le gestionnaire de fichiers, après quoi QtQuickApp est apparu magiquement dans ~ /config/apps.
Encore une fois étonnamment rapide, simple et efficace. Incroyable, incroyable !

Mais… (que seraient-ils sans ça !)

L'application est toujours absente de la liste des applications et de QuickLaunch. Je pense que je sais déjà comment le réparer. Dans le gestionnaire de fichiers, je déplace QtQuickApp.hpkg de ~ /config/packages vers /system/packages.

Non, toujours absente. Apparemment, j'ai (eh bien, et l'instruction) raté quelque chose.

En regardant l'onglet «Contents» dans HaikuDepot pour certaines autres applications, j'ai remarqué qu'il y a des fichiers du type /data/mimedb/application/x-vnd... ce qui est encore plus intéressant, /data/deskbar/menu/Applications/….

Eh bien, que dois-je y mettre ? Voyons…

mkdir -p data/deskbar/menu/Applications/
( cd data/deskbar/menu/Applications ; ln -s .. /.. /.. /.. /apps /QtQuickApp . )
package add QtQuickApp.hpkg apps data

Je suis sûr que ce truc fonctionnera, mais des questions demeurent : pourquoi est-ce nécessaire, à quoi sert cela ? À mon avis, cela ruine l'impression générale que le système est sophistiqué.

Comme l'a expliqué M. waddlesplash :

Parfois, il y a des applications nécessaires à d'autres applications, mais pas dans le menu. Par exemple, LegacyPackageInstaller sur votre capture d'écran, traitant des archives .pkg au format BeOS. J'aimerais que les utilisateurs puissent les installer, mais leur présence dans le menu entraînerait de la confusion.

Je pense qu'il existe une solution plus simple, par exemple Hidden=true dans les fichiers .desktop sur Linux. Pourquoi ne pas rendre l'information "cachée" une ressource et un attribut du système de fichiers ?

Ce qui n'est pas particulièrement sophistiqué — le nom (d'une certaine) application montrant le menu, deskbar, est rigidement lié au chemin.

M. waddlesplash explique à ce sujet :

"Deskbar" dans ce cas doit être compris comme un terme général (un peu comme "taskbar", qui fait référence à la fois à une application de Windows et à un concept général). Et puisque c'est deskbar, et non «Deskbar», cela peut aussi être compris de manière similaire.

2 «catalogues presque identiques» d'applications en eux

Pourquoi y a-t-il 2 catalogues d'applications, et pourquoi dans l'un de ces catalogues se trouve mon QtQuickApplication alors que dans l'autre, il n'est pas présent ? (Ce n'est pas un système mais un utilisateur, ce qui me paraît logique).
Je suis vraiment confus et je pense qu'il faudrait unifier tout cela.

commentaire de mr. waddlesplash

Dans le répertoire Apps, il y a des applications qui ne sont pas nécessaires dans le menu. Toutefois, la situation avec le menu doit vraiment être améliorée pour le rendre plus personnalisable.

Demande, ou cela ne se produira pas 😉

Je me suis demandé : est-il vraiment nécessaire de placer des applications dans /system/apps, si les utilisateurs ne doivent pas les voir là ? Peut-être serait-il mieux de les placer ailleurs, où l'utilisateur ne sera pas confronté à eux ? Tout comme c'est le cas dans Mac OS X, où le contenu des paquets .app, qui ne doit pas être visible par l'utilisateur dans /Applications, est caché dans les entrailles /System/Library/…«`.

Qu'en est-il des dépendances ?

Je pense qu'il serait utile d'indiquer d'une manière ou d'une autre les dépendances, n'est-ce pas ? Peut-on considérer Qt comme une partie essentielle de l'installation par défaut de Haiku ? Non ! Qt n'est pas installé par défaut. Le programme d'assemblage de paquets peut-il détecter automatiquement les dépendances en vérifiant les fichiers ELF ? On m'a dit que HaikuPorter le faisait effectivement, mais package non. C'est parce qu'il est juste un « assembleur de paquets », qui à lui seul crée simplement des fichiers hpkg.

Faut-il rendre Haiku plus sophistiqué en ajoutant une politique selon laquelle un paquet ne doit pas avoir de dépendances vis-à-vis des paquets qui ne font pas partie de haikuports? (Мне бы так хотелось, поскольку подобная политика значительно облегчает задачу — система смогла бы автоматически разрешить зависимости каждого пакета, загружаемого откуда угодно, без возни с дополнительными источниками пакетов).

mr. waddlesplash explique :

Nous ne souhaiterions pas restreindre autant la liberté des développeurs, car il est évident que si la CompanyX souhaite maintenir son propre ensemble de logiciels avec des dépendances (et donc un dépôt) — elle est totalement libre de le faire.

Dans ce cas, il serait peut-être recommandé d'éviter aux paquets tiers d'avoir des dépendances par rapport à quoi que ce soit qui ne soit pas dans haikuports, en emballant complètement tout ce qui est nécessaire avec l'application. Mais je pense que c'est un sujet pour un futur article dans cette série. [L'auteur fait allusion à AppImage ? — note du traducteur]

Ajout d'une icône d'application

Et si je veux ajouter à mes ressources une des icônes intégrées délicates de mon application nouvellement créée ? Il s'avère que c'est un sujet fascinant, donc cela deviendra le sujet principal du prochain article.

Comment organiser une compilation continue d'applications ?

Imaginez un projet similaire à Inkscape (oui, je sais qu'il n'est pas encore disponible sur Haiku, mais c'est pratique pour illustrer). Ils ont un dépôt de code source. https://gitlab.com/inkscape/inkscape.
Chaque fois que quelqu'un enregistre ses modifications dans le dépôt, des pipelines de construction se déclenchent, après quoi les modifications sont automatiquement testées, compilées, et l'application est empaquetée dans divers formats, y compris AppImage pour Linux (un paquet autonome qui peut être téléchargé pour des tests locaux, indépendamment de ce qui peut ou ne peut pas être installé sur le système). [je le savais bien ! — note du traducteur]). De même, tout se produit à chaque demande de fusion de branches, donc vous pouvez télécharger une application compilée à partir du code proposé dans la demande de fusion, avant même la fusion.

Les demandes de fusion affichant les statuts de construction et la possibilité de télécharger des binaires compilés en cas de succès (signalée en vert).

La construction se lance dans des conteneurs Docker. GitLab propose des runners gratuits sous Linux, et je pense qu'il est également possible de connecter vos propres runners (soit dit en passant, je ne vois pas comment cela fonctionnerait pour des systèmes comme Haiku, qui, autant que je sache, n'ont pas Docker ou un équivalent, mais pour FreeBSD, il n'y a pas Docker non plus, donc ce problème n'est pas unique à Haiku).

Idéalement, la construction d'applications pour Haiku pourrait être effectuée à l'intérieur d'un conteneur Docker pour Linux. Dans ce cas, la construction pour Haiku pourrait être intégrée dans les pipelines existants. Existe-t-il des croisement-compilateurs ? Ou faut-il émuler l'ensemble de Haiku à l'intérieur du conteneur Docker, en utilisant quelque chose comme QEMU/KVM (à condition que cela fonctionne ainsi dans Docker) ? D'ailleurs, de nombreux projets utilisent des principes similaires. Par exemple, Scribus fonctionne de cette manière — il est déjà disponible pour Haiku. Un jour, je pourrai soumettre de telles demandes de fusion dans d'autres projets pour y ajouter la prise en charge de Haiku.

Un des développeurs explique :

Pour d'autres projets souhaitant créer des paquets eux-mêmes, la méthode habituelle CMake/CPack est supportée. D'autres systèmes de construction peuvent être pris en charge si le programme de construction de paquet est appelé directement, ce qui est bien si les gens s'y intéressent. L'expérience montre qu'il n'y a pas eu beaucoup d'intérêt jusqu'à présent, donc haikuporter a fonctionné comme cela nous convenait, mais, en fin de compte, les deux méthodes doivent fonctionner ensemble. Nous devrions fournir un ensemble d'outils pour la construction croisée de logiciels à partir de Linux ou de tout autre système d'exploitation serveur (Haiku n'est pas conçu pour fonctionner sur des serveurs).

J'applaudis debout. Les utilisateurs ordinaires de Linux traînent avec eux tout ce poids supplémentaire et ce bagage additionnel (sécurité, contrôle strict, etc.) nécessaires à un système d'exploitation serveur, mais non à un personnel. C'est pourquoi je suis entièrement d'accord qu'avoir la possibilité de construire des applications pour Haiku sur Linux est la bonne voie.

Conclusion

Le portage d'applications POSIX sur Haiku est possible, mais peut nécessiter plus de ressources qu'une recompilation normale. Je me serais certainement attaché à cela pendant longtemps, sans l'aide des gens du canal #haiku sur le réseau irc.freenode.net. Mais même eux n'ont pas toujours vu immédiatement ce qui n'allait pas.

Les applications écrites en Qt sont une légère exception. J'ai compilé une simple application de démonstration sans trop de problèmes.

La construction de paquets pour de simples applications est également assez facile, mais seulement pour celles « publiées de la manière traditionnelle », c'est-à-dire ayant des archives de code source versionnées, destinées à être prises en charge dans haikuports. Pour une compilation continue (compilation à chaque commit) depuis GitHub, ce n'est pas si simple. Ici, Haiku se sent plus similaire à une distribution Linux qu'à un résultat sur Mac, où en appuyant sur le bouton « Construire » dans XCode, on obtient un paquet .app, prêt à être inséré dans l'image disque .dmg, préparé pour être chargé sur mon site.
La construction continue d'applications sur un système d'exploitation « serveur », par exemple, Linux, sera probablement possible s'il y a une demande de la part des développeurs, mais pour l'instant, le projet Haiku a d'autres tâches plus urgentes.

Essayez par vous-même ! En effet, le projet Haiku fournit des images à télécharger sur DVD ou USB, générées quotidiennement. Pour l'installation, il suffit de télécharger l'image et de l'écrire sur une clé USB à l'aide de Etcher

Vous avez des questions ? Nous vous invitons sur notre canal Telegram en russe.

Revue des erreurs : Comment se tirer une balle dans le pied en C et C++. Recueil de recettes Haiku OS

De l'auteur la traduction : c'est le cinquième article d'une série sur Haiku.

Liste des articles : Premier Deuxième Troisième Quatrième

Source : habr.com

Mon cinquième jour avec Haiku : portons quelques programmes