Introduction à QtWebEngine
QtWebEngine intègre les
composantes web de chromium dans
Qt. Il contient sa propre copie de ninja qu'il utilise lors de la
construction s'il ne peut pas trouver une copie sur le système, et
diverses copies de bibliothèques de ffmpeg, icu, libvpx et zlib
(dont libminizip) qui ont été forkées par les développeurs de
chromium.
Ce paquet et les navigateurs qui l'utilisent peuvent être utiles si
vous utilisez un site conçu pour google chrome, ou chromium.
![[Avertissement]](../images/warning.png)
Avertissement
QtWebEngine utilise une copie modifiée de chromium, et est donc
vulnérable à de nombreux problèmes qui y sont trouvés. Les
développeurs de Qt semblent forker une version plus récente pour
les versions mineures de Qt, mais comme chromium publie de
nouvelles versions très régulièrement, quand les développeurs de
Qt arrivent à faire passer leur longue suite de tests à une
version, elle est presque toujours déjà trop vieille et les
correctifs de sécurité pour chromium (dont certains ont un numéro
de CVE) peuvent prendre plusieurs mois à apparaître dans une
version de QtWebengine, même si la sévérité est Critique.
Ainsi, vous devriez vous méfier de l'utilisation de QtWebEngine
dans un contexte sensible et devriez toujours mettre à jour vers
la nouvelle version dès qu'elle apparaît dans le livre, même si
elle n'est pas identifiée comme une mise à jour de sécurité.
Identifier les vulnérabilités corrigées dans une version donnée
nécessite de récupérer les branches « based-NNN »
appropriées juste avant les version précédentes et actuelles, et
c'est souvent compliqué. Les rapports des entrées QTBUG corrigées
ne semblent pas disponibles et il n'y a aucune documentation dans
les archives sur les changement après les versions qt-5.
Ce paquet est connu pour pouvoir être construit et fonctionner
correctement avec une plateform 12.2.
Avertissement
Par défaut, ninja utilisera tous les CPU actifs + 2 (si au moins
4 existent), même s'ils ne sont pas disponibles pour la tâche
actuelle parce que le terminal a été restreint avec
« taskset ». Dans BLFS, ce paquet prend plus de temps à
construire que n'importe quel autre. Une fois, la construction de
ce paquet a échoué à environ 90 pourcent à cause d'un problème de
mémoire sur un système à 24 cœurs et 32 Go de mémoire.
Pour contourner cela, voir les explications des commandes
ci-dessous.
Informations sur le paquet
Téléchargements supplémentaires
Dépendances de qtwebengine
Requises
Cups-2.4.10, html5lib-1.1, nodejs-20.16.0, nss-3.103, pciutils-3.13.0 et Qt-6.7.2
Recommandées
![[Note]](../images/note.png)
Note
Si ces paquets ne sont pas installés, le processus de
construction compilera et installera ses propres (sans doute plus
vieilles) versions, avec pour effet d'augmenter l'espace disque
utilisé et le temps pris par la construction et l'installation.
soit alsa-lib-1.2.12 soit PulseAudio-17.0 (ou les deux), FFmpeg-7.0.2, ICU-75.1, libwebp-1.4.0, libxslt-1.1.42
et Opus-1.5.2
Facultatives
libevent-2.1.12, MIT
Kerberos V5-1.21.3, pipewire-1.2.3, Poppler-24.08.0, jsoncpp,
libsrtp, snappy
Installation de qtwebengine
Tout d'abord, adaptez la copie embarquée de Chromium à la dernière
version de ffmpeg :
patch -Np1 -d src/3rdparty/chromium < ../qtwebengine-6.7.2-ffmpeg7_fixes-1.patch
Ensuite, corrigez un échec de la construction qui arrive à cause de
la construction de BLFS qui n'utilise pas OpenH264 :
sed -e '189 s/=/& false/' \
-e '190 d' \
-i.orig src/3rdparty/chromium/third_party/webrtc/webrtc.gni
Installez qtwebengine en exécutant
les commandes suivantes :
mkdir build &&
cd build &&
cmake -D CMAKE_MESSAGE_LOG_LEVEL=STATUS \
-D QT_FEATURE_webengine_system_ffmpeg=ON \
-D QT_FEATURE_webengine_system_icu=ON \
-D QT_FEATURE_webengine_system_libevent=ON \
-D QT_FEATURE_webengine_proprietary_codecs=ON \
-D QT_FEATURE_webengine_webrtc_pipewire=ON \
-D QT_BUILD_EXAMPLES_BY_DEFAULT=OFF \
-G Ninja .. &&
ninja
Ce paquet n'a pas de suite de tests.
Maintenant, en tant qu'utilisateur root :
ninja install
Explication des commandes
CMAKE_MESSAGE_LOG_LEVEL=STATUS :
affiche des messages qui pourraient intéresser les utilisateurs des
projets. Dans l'idéal, ces messages devraient être concis, pas plus
d'une simple ligne, tout en restant informatifs.
QT_FEATURE_webengine_system_* :
spécifie les paquets externes que le système devrait utiliser.
QT_BUILD_EXAMPLES_BY_DEFAULT=OFF :
ne pas construire les exemples par défaut.
NINJAJOBS=4 make : Si vous avez
corrigé le ninja du système dans LFS pour qu'il reconnaisse la
variable d'environnement NINJAJOBS, cette commande lancera le ninja
du système avec le nombre de travaux spécifiées (c.-à-d. 4). Il y a
plusieurs raisons pour lesquelles vous pourriez vouloir faire
cela :
-
Construire sur un sous-ensemble des CPU permet de mesurer le
temps de construction pour un plus petit nombre de
processeurs, et de lancer d'autres tache gourmandes en CPU en
même temps. Pour les rédacteurs sur une machine avec de
nombreux CPU, qui essayent de mesurer le temps pour une
machine à 4 cœurs, NINJAJOBS=4
make donnera une approximation raisonnable (il y a une
petite période où N+2 travaux python2 et node tournent en
même temps).
-
Sur une machine avec seulement 4 CPU en ligne,
l'ordonnancement de N+2 taches pour qtwebengine est plus lent
d'environ 3 à 7 %, sans doute à cause de la taille des
fichiers C++ et de leurs nombreux fichiers inclus et modèles.
Donc, dans le doute paramétrez NINJAJOBS aux nombre de CPU.
-
Réduire le nombre de cœurs utilisé pour des paquets gourmands
en CPU pendant un long moment peut atténuer des problèmes de
température.
-
Réduire le nombre de cœurs évitera d'éventuels problèmes de
mémoire sur les systèmes qui n'ont pas suffisamment de
mémoire (ou d'espace d'échange) quand tous les cœurs sont
actifs. L'approche suggérée est de limiter le nombre de cœurs
à environ un pour chaque 1,5 Go de RAM et d'espace
d'échange combinés.
Configuration de QtWebEngine
Informations sur la configuration
Si vous mettez à jour depuis une version mineur plus ancienne de
cette application, vous devrez nettoyer le cache du navigateur pour que certaines pages
fonctionnent, p. ex. pour falkon
ce sera dans ~/.cache/falkon/. vous
devrez le faire si le navigateur commence à rendre la page puis
se change en un onglet vide avec un message disant que quelque
chose s'est mal passé, et un bouton pour réessayer. Même après
avoir supprimé l'ancien cache, vous pourriez avoir besoin de
réessayer plusieurs fois pour chaque onglet affecté.
Si un navigateur utilisant ce paquet ne s'exécute pas et si
lorsqu'il est lancé depuis un terminal il rapporte
« Trace/breakpoint trap » c'est probablement un
problème de configuration du noyau — il n'y a pas besoin de
reconstruire QtWebEngine, voyez la prochaine section, recompilez
le noyau et redémarrez sur le nouveau noyau.
Configuration du noyau
Ce paquet n'a pas besoin des options facultatives des espaces de
noms du noyau, mais si les espaces de noms utilisateurs sont
activés (comme c'est le cas dans certaines
unités systemd, en durcissement) les espaces de noms de PID
doivent aussi être activés. Dans ce cas activez les options
suivantes dans la configuration du noyau et recompilez le noyau si
nécessaire :
General setup --->
-*- Namespaces support ---> [NAMESPACES]
# Enable or disable *both* of them:
[ /*] User namespace [USER_NS]
[ /*] PID Namespaces [PID_NS]