Reprise du message précédent :
Saute le pas Mr Jean, c’est pas si compliqué que ça. Faut juste aimer la compilation

ça devrait aller avec ma configuration actuelle

Et si t’aimes pas, la Calculate te tends les bras.

Sympa la compilation de qtwebengine de nos jours : 16Go, ce n'est pas suffisant avec 8 threads!
Ceci, au moins pour les deux dernières versions dans portage.

En même temps, tu cherche un peu les embrouilles.
Entre chrom-e/ium, boost, llvm-clang, firefox et libreoffice y'a des bouffeurs de ram à la compil'.
Imagine un peu ma dernière machine de crosscompile où j'ai du lui adjoindre 32G de ram parce que ... 3800XT dedans. Ceci dit, je m'embête plus, tout se qui est pas vital, je compile sous clang, gcc, c'est bien, mais c'est pas se qu'il y a de mieux pour les gros projets.

Certes .
Après, je pourrais peut-être le supprimer, vu son utilité :

Bref, tu as raison, il faut vouloir Enable QtWidgets support : à voir dans une prochaine mise à jour du coup!

Il peut être ghost pullé par je sais plus quels paquets, faudrait que je vérifie, mais de mémoire principalement digikam et luminance-hdr. Après, si tu dev pas, ça reste une API dispensable. Du coup te prive pas d'un ptit -webengine -telepathy dans les useflag pour le reste de KDE.

J'aime beaucoup Kmail, mais il force une dépendance sur qtwebengine (pour afficher les mails HTML).
Sur une Gentoo avec KDE mais sans Kmail j'arrive à éviter la dépendance sur qtwebengine (2 heures de build sur un core i7  tout de même).

Entre gnome qui est presque totalement dépendant de systemd (bidouillable mais chiant) et KDE qui demande des temps de compil juste abominablement longs pour le webengine (qui était avant contournable avec l'adapt webkit en qt, mais déprécié ) c'est sur que depuis quelques années, on est pas gâtés.

J'ai beaucoup utilisé Kmail, mais, je suis passé à Claws Mail depuis quelques années.
Là, dans ma liste, seul Digikam n'est pas dispensable, le reste, c'était plutôt du test (cela dit, Konqueror a été mon navigateur web pendant des années).
D'ailleurs, j'ai déjà supprimé akregator que je n'utilise également plus.
 
edit : exactement MysterieuseX.

sway + neomutt et plus de soucis !  
 
Bon j'ai quand même qtwebengine, faudrait que je regarde à cause de qui…

Yo !
 
Je suis en train de regarde qui utilise qtwebengine chez moi et je vois :
- dev-python/PyQtWebEngine (faut que je regarde pourquoi)
- net-misc/nextcloud-client  et là par contre je vais avoir du mal à m'en passer xD
 
 
Bon bah en gros pas le choix ! je vais devoir me taper qtwebengine encore ^^"

Le fork Qt5 de webkit fait mal.

Moi j'ai viré Qtwebengine, Chromium et Firefox (et Rust du coup) à cause des temps de compilation bien trop longs. J'utilise désormais firefox-bin.  
 
Outre le temps d'installation économisé, cela m'a permis de me débarrasser de python 2.7.  
 
Concernant qtwebengine, le bug suivant (https://bugs.gentoo.org/669082) a été ouvert pour demander une version pré-compilée mais  
sans trop de succès je crois.  
 
De manière générale, il y a aussi un projet de binhost : https://archives.gentoo.org/gentoo- [...] a06cf18137

Pour rust, tu as rust-bin :-)

Le soucis, c'est son intégration de plus en plus profonde dans KDE avec des applications qui s'en servent comme couche d'affichage graphique. Webkit reste un excellent moteur dans le fond.
Prend DigiKam par exemple, il est difficilement dispensable quand tu fais de la photo en opensource, y'a pas beaucoup de gestionnaires d'images avec une fonction éditeur pas trop dégueux.
 
Le plus gros problème de qtwebengine c'est qu'il est pas "binarisable" sans avoir à imposer un use spécifique au niveau de la toolchain, et ça va à l'encontre de la philosophie gentoo, ça reste une API bas niveau avec une intégration poussée Qt pour KDE, du coup j'ai un doute que la demande passe un jour (ça fait quand même depuis 2018 que ça court). L'option la plus censée à ce niveau pour quelqu'un qui voudrait du binaire en gardant la possibilité de compiler, avec portage dans le fond, c'est de passer sur calculate (ce que j'ai fait)
 
'fin bon, hormis à dériver sur du "gentoo politics" c'est pas franchement ça qui va apporter des solutions (y'en a t-il vraiment une ?)

Perso, j'ai rien contre Qtwebengine, bien au contraire. Les temps de compil ont simplement eu raison de lui!  
Comme tu le dis, il n'y pas vraiment de solution viable pour résoudre ce problème. Dommage vu les nombres posts sur le forum Gentoo concernant ce paquet.  
 
Clairement, le fait de perdre Digikam au passage est bien embêtant  
 
Rust va vite devenir problématique aussi, vu que son utilisation explose. Comme proposé par babaowhisky, je finirai probablement avec rust-bin.  
 
Je réfléchi depuis un moment à essayer Calculate ou Sabayon. Il faut que je me renseigne davantage.

Sabayon, j'aime pas, elle est systemd only, tu peux même pas le debrand en recompilant, le squelette de base de la distro est inamovible. En soit une Calculate est directement compatible gentoo, ou l'inverse et la migration est quasiment transparente (dans le sens où pour passer d'une calculate à une gentoo, tu délock portage et la migration se fait au fur et à mesure des mises à jour, et inversement, tu lock ton portage en modifiant les sources et tu passe d'une gentoo à une calculate).

 
(machine de 10 ans d'âge hein   et puis y'avait d'autres trucs qui tournaient en même temps   )
 
Ca fout les boules de se farcir ce foutu rust juste pour ça. Encore que ça va, les màj ne sont pas trop régulières en stable donc cela reste jouable. Sinon, cela sera rust-bin.

Rust est utilisé par Firefox, spidermonkey (dépendance de Polkit), les prochaines versions de dev-python/cryptography ... Rust est en train de devenir un composant obligatoire et ca va être compliqué de s'en passer!  
 
Je viens me souvenir que j'ai déjà rust-bin.  

Quel est le use nécessaire sur la toolchain ? En lisant le bug 669082, le seul problème que je vois est d'avoir quelqu'un pour faire le boulot d'écrire l'ebuild -bin et de le maintenir.
 
C'est une des raisons pour laquelle je suis repassé sur une Gentoo stable, en testing qtwebengine doit être recompilé très souvent parce qu'il dépend de pas mal de librairies qui bougent beaucoup.
 
J'ai l'impression que les temps de compilation redeviennent un problème avec Rust, Chromium et QtWebEngine, alors que c'était devenu très raisonnable avec l'avènement des CPU multi-cœurs. Mais quand même c'est toujours beaucoup plus raisonnable que lors de me premiers pas sous Gentoo, avec un emerge @world qui prenait plusieurs jours à terminer avec un Athlon XP 2400+.

Rien qu'avec Kerberos, Alsa et PulseAudio en global useflags, ça peut poser des soucis : si ton auth utilise pas kerberos et que QtWebEngine est compilé avec le support kerberos, il va s'attendre à avoir des authentifications kerberos. Idem pour les sorties audio qui sont pas forcements standards. Dans les locals, tu peut préférer ton ffmpg système au lieu de l'embarqué (si peut que l'upstream soit en retard niveau fonctionnalité, ou qu'il y ait des fonctionnalités dans ton ffmpg système qui ne sont plus dans l'embarqué, idem pour icu)
 
Edit : après une solution serait de le compiler avec clang au lieu de GCC, d'ailleurs, il est fortement conseillé pour firefox et libreoffice d'utiliser clang au lieu de gcc.

Bon Gentoo or not Gentoo ...  
D'un côté, la facilité d'avoir Mesa-git et compiler Wine avec ses propres patches et de l'autre les 4-5 heures d'installation sur mon laptop.
 

Calculate et tu compile ton mesa-git et ton wine comme sur Gentoo. Enjoy !

Sans installer Calculate, est-ce qu'il existe un moyen pour savoir avec quels use flags sont compilés les binaires ?

Les binaires gentoo genre firefox bin ?
Je sais plus mais oui c'est documenté, sinon si tu fait du binhost tu le sais, autrement si tu utilise un repos externe, faut le demande à celui qui distribue les binaires.

Je parlais des packages pré-compilés de Calculate Linux. Exemple, si je veux installer Qtwebengine sur Calculate, quels sont les use flags activés par les dev Calculate?  
 
Je n'avais pas trouvé d'info technique là-dessus.
 
Mais en explorant les mirroirs Calculate, je suis tombé sur les packages au format xpak, que l'on peut explorer.  
 
 

En faisant un « eix qtwebengine », qui te donnera toutes les infos sur les versions disponibles, la version installée (en surbrillance, le cas échéant) et les flags (bleus : activés ; rouges : désactivés) ?
 
Après, il existe un TU sur Calculate, donc si tu as des questions à poser dessus…
Tu peux aussi contacter Adrien D (Linuxtricks), qui l’utilise au quotidien chez lui et y contribue (traduction, miroir français, version GNOME non encore officielle).

Un appel au secours cross-topic m'amène ici.  
 
Bref, est ce qu'il y a eu des tentatives d'optimisation côté stockage de masse ?  
Un truc de j'utilise beaucoup dans le tuning des grosses BDD, c'est le multi-DD : c'est à dire que je répartis les fichiers manipulés afin de répartir les IO et la charge en écriture.
Plusieurs niveaux d'optimisation sont possibles :

• Répartition sur plusieurs partitions : optimisation sur la sérialisation des écritures des partoches (parallélisation des files d'IO du kernel)
• Répartition sur plusieurs DD : parallélisation des I/O sur les partoches, les DDs et les contrôleurs de disque
• Donner la préférence aux DD les plus rapides de la machine
• utiliser LVM2 ? (répartition de la charges sur les DD à la discrétion du pilote LVM)
• RAMFS ? Pour les riches qui ont 4 fois plus de RAM que ce qu'ils ont besoin (après tout, on est sur HFR )

Après pour ceux qui ont un datacenter, ils peuvent tenter l'approche ferme de calcul. Par exemple, DVDRIP dispose d'une très bonne approche du calcul réparti.  
 
Vala, les idées en vrac du dimanche matin

Oui, par exemple sur une BDD tu peux utiliser un SSD plus rapide pour les redo / write ahead logs et du stockage plus lent pour les données en mettant chaque base de donnée / tablespace sur des disques différents.

 
Oui alors non, faut mieux explicité ton problème parce que là, sans savoir de quoi tu parle, c'est tendu de comprendre. Surtout pour ceux qui suivent pas, "l'autre topic" dans lequel tu parle de tes soucis de longueur de compilation.
En l'occurrence même moi je vois même pas le rapport entre tes temps de compilation longs, et les BDD, autant pour le premier j'aurai bien une réponse, autant pour le second c'est quoi le contexte ? Ca concerne gentoo et/ou la compilation de gros trucs ?

Ok, (t'es bien une chieuse comme indiqué sous le pseudo, on dirait ma femme)

Alors oui, les temps de compilation sont sensibles à la bande passante disque. Cette composante est souvent LE goulot d'étranglement. En multipliant les espaces disque utilisés et en les utilisant en parallèle, on gagne. D'où mon p'tit message.

Le rapport avec les BDD, c'est que ce sont des applications qui sollicitent beaucoup le stockage de masse et qu'une des voies d'optimisation est l'utilisation de plusieurs disques et plusieurs contrôleurs en parallèle. C'est typiquement une des clés de l'architecture des exadata d'Oracle.

Alors, non, on l'a déjà dit comment fonctionnait justement la compilation sous GCC.
 
GCC possède un paramètre du nombre de thread à utiliser, et le nombre de thread détermine la consommation en RAM, pas en espace ni en IO disque. En fait GCC est naïf concernant les disques (et c'est normal si tu y réfléchit bien). En revanche, il va aller swapper lorsque l'espace ram vient a manquer.
 
Ici, deux choix, soit t'as une blinde de ram, soit tu configure ton swapiness et ton nice pour bouffer la ram en priorité avant de swapper, chose que ne font pas ou n'apprennent pas à faire les distributions "binaires".
On est absolument pas sur le même système que les BDD dans la gestion des process, puisqu'une BDD a une taille fixée (I/O datagram) d'utilisation qui dépend de la taille des données que tu manipule et la taille de ram block sur les fonctions que tu lui demande d'exécuter.

Pour éviter de faire trop d'I/O disque avec Portage et GCC, une technique est d'utiliser un tmpfs afin que GCC crée tous ses fichiers intermédiaires en mémoire: https://wiki.gentoo.org/wiki/Portage_TMPDIR_on_tmpfs
 
Bien sûr ça ne fonctionne pas pour les paquets un peu trop gros.

Inutile, comme précisé : swapiness et nice. Le TMPFS agit sur un autre point qui n'apporte pas grand chose en performances sur des disques modernes (SSD), en gros, il stock les fichier compilés avant la finalisation du projet dans le TMP, mais ça n'ajoute pas à la vitesse de lecture (et donc de compilation intrinsèquement). En gros, c'est pas du cache. Pour avoir un vrai "readahead" y'a pas de secret, faut de la ram. De plus, il y a certains projet (Rust, boost, libcaca/cacao, webengine et ses dérivés/chrom-e/ium, libreoffice) qui dépassent allégrement la barre des 10 a 20G de ram utilisée en cours de compile, et là, c'est le drame.

Je limite à 6 threads pour qtwebengine avec mes 16Go .
(il fut un temps où j'avais 24Go de Ram ... mais ça ne me servait pas)

Hop, à jour :

L'identification renforcée sur Gentoo : ça devient des mots de passe un peu pénibles à se rappeler .
Genre Moat5Board&Open !

Hello,

Après plus de 10 and éloigné de Gentoo, j'ai voulu voir si j'avais perdu la main ou pas... Eh bah oui, perdu la main.
Je m'arrache les cheveux depuis deux jours sur un problème que voici:

J'essaye de monter des répertoires NFS lors du boot, mais invariablement j'ai le message suivant:
Failed to mount NFS. Network is unreachable.

J'ai bien

ainsi que

qui sont lancés au boot.
Et mon fstab contient

comme option pour monter les partitions.

De plus, lors que je me loggue et que je relance netmount via un rc-service, les répertoires sont correctement montés. Un mount -a ne pose également aucun problème. C 'est que la config NFS doit a priori être correcte. Ca coince donc surement lors de la prise en charge du réseau, mais où?

Je dois louper un truc... Si quelqu'un a une idée?

Merci

 
Bon,
 
A priori problème résolu, mais je ne sais pas quelle en était la cause...
 
Pour chopper une lease IP j'utilisais le package net-misc/dhcpcd et non pas la méthode plus basique décrite dans le handbook.
En revenant avec le méthode préconisée dans le handbook, ie sans utiliser le package net-misc/dhcpcd, le système lors du boot attend bien d'avoir une lease IP avant de monter les shares NFS.
 
Cheers,

Le petit up de Pâques 2022.
 
Une mise à jour qui peut poser souci, cf là.
systemd-utils combines sys-fs/udev, systemd-boot, and systemd-tmpfiles making them obsolete (thus the removal, there should be a news item soon'ish to make things clearer).
Il est toujours sympa ce systemd ...  

Juste Alsa qui ne charge pas chez moi (pour le moment). À voir dans la discussion précédente.
Mais, comme j'ai tendance à ne pas mettre le son, ça ne me gêne que peu   .
 
edit : et si j'enlevais sys-fs/udev (250) qui reste présent chez moi !
Bref, je vois que tout est déjà dans la version r1 de systemd-utils (genre).
Au final, il faut juste attendre la synchronisation ... qui vient d'arriver :