# [ebuild] masquer pour moins avoir à mettre à jour (biais)

## pti-rem

Bonsoir,

Dans le contexte de début d'année plutôt anxiogène de part les médias principalement, il m'a semblé important de mettre à jour mon système plusieurs fois ces quelques dernières semaines.

D'une manière générale, mes mises à jour globales sont vraiment trop importantes en temps de compilation et en chaleur interne pour mon portable i7-2670QM@2.2 de 2012.

```
CFLAGS="-march=corei7-avx -O2 -pipe"

CPU_FLAGS_X86="aes avx mmx mmxext popcnt sse sse2 sse3 sse4_1 sse4_2 ssse3"

USE="aes avx mmx mmxext sse sse2 ssse3 sse4_1 sse4_2 ssse3 nls unicode ssl examples handbook bluetooth pulseaudio -ipv6 aac fdk qt3support x265 nautilus -systemd -airplay"
```

J'ai adopté le C++14 PIE comme l'indique la news ; Donc désormais avec gcc version 6.4.0 (Gentoo 6.4.0-r1 p1.3)

Je souhaite idéalement masquer des versions d'ebuilds > à des versions stables - mais dont des mises à jour sont proposées... Encore et encore.

Je ne sais pas trop bien m'y prendre, je fais ça au semi-pifomètre et c'est pas méthodique.

Pour les applications utilisateur, ça reste plutôt facile ; je pense davantage au système.

C'est surtout "les gros morceaux" que je voudrais fixer, des ebuilds particulièrement longs à compiler.

Je me demande si il y aurait des "sortes" de listes d'ensembles stables dont la version > est masquée ?

Mon installation remonte à plusieurs années ; peut-être 2012...

Maintenant, je patauge tranquillement dedans sans y faire de changement majeur.

J'utilise le simple xfce4 et ses extras

Je reste avec openrc et le nommage d'interfaces style eth0

Je ne pense pas prendre le noyau 4.14 ; même quand il sera stable.

Je ne crois pas qu'il présente vraiment de l'utilité dans mon cas. Malgré Meltdown...

Suit mes bidouillages de masquage ; je n'ai pas mis mon système à jour après.

```
n73sm /etc/portage/package.mask # ls -gt

total 96

-rw-r--r-- 1 root  30 19 janv. 16:26 dev-python-pygobject

-rw-r--r-- 1 root  79 19 janv. 16:21 gnome-base-gnome-desktop

-rw-r--r-- 1 root  52 19 janv. 16:09 vala

-rw-r--r-- 1 root  60 19 janv. 15:56 x11-libs-gtk+

-rw-r--r-- 1 root  22 19 janv. 15:47 dev-libs-glib

-rw-r--r-- 1 root  41 19 janv. 15:46 xfce4-terminal

-rw-r--r-- 1 root  22 19 janv. 15:38 net-fs-libnfs

-rw-r--r-- 1 root  29 19 janv. 15:32 webkit-gtk

-rw-r--r-- 1 root  24 19 janv. 15:25 kodi

-rw-r--r-- 1 root  25 19 janv. 15:24 libxml2

-rw-r--r-- 1 root  38 19 janv. 15:21 sources

-rw-r--r-- 1 root  77 19 janv. 15:20 llvm

-rw-r--r-- 1 root  26  2 déc.  23:40 hplip-3.17

-rw-r--r-- 1 root  75 13 nov.  06:33 nvidia

-rw-r--r-- 1 root 257 11 nov.  19:44 qtwebkit

-rw-r--r-- 1 root  33 29 sept. 08:04 opera

-rw-r--r-- 1 root  93 29 juin   2017 plex

-rw-r--r-- 1 root  30 15 déc.   2016 paramiko

-rw-r--r-- 1 root  30 17 oct.   2016 systemd

-rw-r--r-- 1 root  21 25 févr.  2016 vo-aacenc

-rw-r--r-- 1 root  50 21 déc.   2015 emul

-rw-r--r-- 1 root  28 22 févr.  2015 libtool

-rw-r--r-- 1 root  53 22 févr.  2015 openrc

-rw-r--r-- 1 root  22 22 févr.  2015 perl
```

```
n73sm /etc/portage/package.mask # echo "" && for f in $(ls -t1); do echo "Pour "$f" :" && cat $f | sed '/^$/d' && echo ""; done

Pour x11-libs-gtk+ :

#>x11-libs/gtk+-3.22.19:3::gentoo

=x11-libs/gtk+-3.22.19::mv

Pour sources :

#>sys-kernel/gentoo-sources-4.9.76-r1

Pour llvm :

#>sys-devel/clang-4.0.1

#>sys-devel/llvm-4.0.1-r1

#>sys-devel/llvm-common-4.0.1

Pour libxml2 :

#>dev-libs/libxml2-2.9.6

Pour webkit-gtk :

#>net-libs/webkit-gtk-2.18.5

Pour net-fs-libnfs :

#>net-fs/libnfs-1.9.7

Pour xfce4-terminal :

#>x11-terms/xfce4-terminal-0.8.6::gentoo

Pour dev-libs-glib :

#>dev-libs/glib-2.52.3

Pour vala :

#>dev-lang/vala-0.34.9

#>dev-libs/vala-common-0.34.9

Pour gnome-base-gnome-desktop :

#>gnome-base/gnome-desktop-3.22.2

#>gnome-base/gsettings-desktop-schemas-3.22.0

Pour dev-python-pygobject :

#>dev-python/pygobject-3.22.0

Pour kodi :

>media-tv/kodi-17.3-r1

Pour hplip-3.17 :

>=net-print/hplip-3.17.10

Pour nvidia :

#>x11-drivers/nvidia-drivers-340.93-r1

#>x11-drivers/nvidia-drivers-361.28

Pour qtwebkit :

# required by dev-qt/qtwebkit:4 (argument)

# /usr/portage/profiles/package.mask:

# Andreas Sturmlechner <asturm@gentoo.org> (16 Oct 2017)

# Qt4WebKit is ancient and is likely to have more holes

# in it than swiss cheese. Bug #620684

=dev-qt/qtwebkit-4.8.7

Pour opera :

=www-client/opera-12.16_p1860-r1

Pour plex :

<=media-tv/plex-media-server-1.5.7.4016::fkmclane

<=media-tv/plex-media-server-1.5.5::gentoo

Pour paramiko :

#>=dev-python/paramiko-2.0.2

Pour systemd :

sys-apps/systemd

sys-fs/udev

Pour vo-aacenc :

media-libs/vo-aacenc

Pour emul :

# mask emul-linux

app-emulation/emul-linux-x86-*

Pour libtool :

<sys-devel/libtool-2.4.3-r2

Pour openrc :

<sys-apps/openrc-0.13.0

<sys-process/procps-3.3.9-r2

Pour perl :

<dev-lang/perl-5.18.0
```

Last edited by pti-rem on Sun Jan 21, 2018 3:42 pm; edited 2 times in total

----------

## El_Goretto

 *pti-rem wrote:*   

> Je ne pense pas prendre le noyau 4.14 ; même quand il sera stable.
> 
> Je ne crois pas qu'il présente vraiment de l'utilité dans mon cas. Malgré Meltdown...
> 
> 

 

Oh que si.

Tu as une machine avec un CPU Intel et un navigateur internet contenant un moteur Javascript. Tu exécutes donc du code tiers tous les jours. 

Bienvenue en 2018  :Wink: 

----------

## sebB

Le problème est que tu vas te retrouver bloqué à un moment ou un autre (par le jeu des dépendances).

Ca ne sera pas forcément de suite, mais peut-être dans 6 mois, 1 an, et là, la maj va être folklorique.

Si je suis ta logique, tu souhaite presque figer ton système?

Par contre, il est pas beau du tout ton package.mask.

 *Quote:*   

> D'une manière générale, mes mises à jour globales sont vraiment trop importantes en temps de compilation et en chaleur interne pour mon portable i7-2670QM@2.2 de 2012. 

 

Ca te prends combien de temps pour compiler gtk+?

----------

## pti-rem

Salut sebB et merci.

Pour réinstaller x11-libs/gtk+-3.22.19::gentoo seul j'ai ce time :

real 5m2,772s

user 19m38,694s

sys 2m6,242s

Ça fait pas gros.

Je me disais que je pouvais me satisfaire d'une certaine version stable pour certains paquets ; je n'ai pas envie de me retrouver dans le folklore non plus.

C'est théoriquement possible de figer un peu son système et même d'en revenir j'imagine.

Ma machine tourne h24 et il y a un aspect un peu déplaisant que je ne m'explique pas bien à faire une mise à jour globale @world

genre « on sait ce qu'on a mais pas ce qu'on va trouver » & « Pourquoi tout ça encore ? »

Elle fait un petit peu serveur, j'aimerai pas l'avoir en rade en rapport à une mise à jour.

Pour mon package.mask, c'est la forme ou le fond qui ne va pas ? les deux ? J'y ai commenté tous mes ajouts du 19 janvier.

Mes USE doivent aussi manquer d'élégance, si ce n'est de logique. Avec des excédents aussi.

Il y a plein de principes fondamentaux qui m'échappent encore. Mon système est probablement surchargé par rapport à mes besoins. C'est pas certain.

J'ai plus de mal à me former davantage maintenant ; bon... j'ai un système qui tourne et c'est déjà bien.

Pour mon time emerge -pvuDN @world : https://pastebin.com/YXFKvxUG

Par exemple : llvm clang passent de la version 4 à la 5 en nouveau slot et j'ai pas mal de paquets en 3.22 qui passent en 3.24

Je donnerai le time de cette emerge.

J'aimerai bien - ça c'est sûr - avoir une trace du temps mis par chaque paquet pour émerger et utiliser juste ce facteur en premier.

Si il y a une astuce à utiliser ? Je dois bien pouvoir faire quelque chose avec /var/log/emerge.log

Je crois également qu'il vaut mieux que j'accepte de faire comme d'habitude tant que je ne connais pas davantage le rôle des paquets.

C'est aussi que j'étais avec gcc en version 4.x et j'ai eu du boulot pour le mettre à jour en version 5.y juste avant de devoir suivre la news pour le mettre à jour à nouveau (Gentoo 6.4.0-r1 p1.3)

Je vais passer mon MAKEOPTS de j9 à j5 ; pour utiliser en même temps et voir si ça chauffe moins. Le temps n'a guère d'importance en fait.

Au passage, y a t'il une version unstable conseillée des gentoo-sources du noyau 4.14 ?

édition : Je suis un peu ambivalent pour ce qui est du temps, peut-être que maintenant en j5 je me sentirai moins contrarié en pouvant utiliser ma machine tout en surveillant l'emerge.Last edited by pti-rem on Sun Jan 21, 2018 3:44 pm; edited 1 time in total

----------

## pti-rem

MAKEOPTS="j5" résout mes soucis  :Smile: 

La température des cœurs reste raisonnable.

J'ai de la disponibilité pour travailler ou servir un peu.

Je peux suivre la mise à jour ; jeter un coup d'œil.

Le temps de compilation ne rentre plus en ligne de compte.

Je me sens bête alors ! d'être resté si longtemps avec cette problématique qui trouve une si simple solution.

Du coup, évidemment, je m'intéresse bien moins à masquer des paquets comme j'ai pu l'envisager.

 *El_Goretto wrote:*   

> Tu as une machine avec un CPU Intel et un navigateur internet contenant un moteur Javascript. Tu exécutes donc du code tiers tous les jours. 
> 
> Bienvenue en 2018 

 

Cette affaire est tellement énorme et incroyable. C'est dingue.

Qui pourra dire que telle url donne à exécuter un code malveillant ?

Toutes les machines sont bonnes pour le rouleau à terme, si je me réfère à un article du point.

Autrement, Merci El_Goretto.

C'est pas ici que l'on va épiloguer.

----------

## sebB

Déjà tu peux virer tout les < dans tes mask.

Avec sensiblement le même CPU que toi voilà ce que j'utilise (le temps de compil je m'en fou et mon ordi n'est jamais surchargé)

```
MAKEOPTS="-j4 -l8"

EMERGE_DEFAULT_OPTS="--jobs=4 --load-average=4.0 --keep-going --with-bdeps=y"
```

Ca avec une compil en tmpfs et ton ordi devrait respirer.

Sinon pour les grosses compil, tu peux les virer à coup de exclude.

 *Quote:*   

> 
> 
>  J'aimerai bien - ça c'est sûr - avoir une trace du temps mis par chaque paquet pour émerger et utiliser juste ce facteur en premier. 

 

genlop -t paquet

----------

## pti-rem

J'ai fait comme tu m'as recommandé sebB

Je suis vraiment satisfait ! Merci beaucoup.

Ça change la donne.

Mes mask sont nettoyés

https://pastebin.com/4FdGZchG

Bonne journée

----------

## pti-rem

Bonjour,

 *sebB wrote:*   

> Avec sensiblement le même CPU que toi voilà ce que j'utilise (le temps de compil je m'en fou et mon ordi n'est jamais surchargé) 
> 
> ```
> MAKEOPTS="-j4 -l8" 
> 
> ...

 

Il y a quelque temps, j'ai encore réduit de manière empirique à :

```
MAKEOPTS="-j4 -l4"

EMERGE_DEFAULT_OPTS="--jobs=3 --load-average=3.0 --keep-going --with-bdeps=y"
```

Et ça chauffe encore trop !

J'ai l'impression que mon CPU utilise souvent sa fonction Boost jusqu'à 3,1 GHz depuis une mise à jour de noyau (je ne sais plus laquelle) ;

De mémoire, la fréquence était plafonnée à 2,2 GHz avant.

Je dépasse allègrement le High de 86° en mise à jour pour aller vers 90° et un peu au-delà.

Je voudrais baisser les parallélisations pour moins faire chauffer quitte à prendre plus de temps.

Et j'ai besoin de journaliser les températures.

Si vous pouviez me donner un coup de main ?

Merci

Je vais essayer avec :

```
MAKEOPTS="-j3 -l3"

EMERGE_DEFAULT_OPTS="--jobs=2 --load-average=3.0 --keep-going --with-bdeps=y"

```

C'est mieux, les pointes à 90° sont beaucoup plus rares  :Smile: 

```
Toutes les 2,0s: sensors                         n73sm: Mon Jan 14 09:51:13 2019

asus-isa-0000

Adapter: ISA adapter

temp1:        +88.0°C

acpitz-virtual-0

Adapter: Virtual device

temp1:        +88.0°C  (crit = +103.0°C)

coretemp-isa-0000

Adapter: ISA adapter

Package id 0:  +88.0°C  (high = +86.0°C, crit = +100.0°C)

Core 0:        +85.0°C  (high = +86.0°C, crit = +100.0°C)

Core 1:        +88.0°C  (high = +86.0°C, crit = +100.0°C)

Core 2:        +86.0°C  (high = +86.0°C, crit = +100.0°C)

Core 3:        +80.0°C  (high = +86.0°C, crit = +100.0°C)
```

----------

## El_Goretto

Quelques remarques, en prenant un peu de recul:

- jouer avec les options logicielles de portage n'est pas une solution à un problème de chauffe, puisque cela ne concerne que portage, et que ce n'est pas fiable.

- si c'est un problème de dissipation de chaleur, alors il serait peut être temps de mettre les mains dans le cambouis et regarder ce que tu peux faire côté hardware (nettoyage, changement de pâte thermique, etc.)

- les CPUs ont depuis longtemps un mécanisme de "throttling" pour ralentir violemment quand les températures sont dangereuses pour eux. Vérifie que ton CPU en est équipé. Tu dois même pouvoir voir dans les logs linux quand le phénomène se déclenche (c'est le cas sur mon laptop et un microserveur chez moi).

Voilà, c'est pour mettre en perspective le temps passé sur ce sujet vs le fait de le "résoudre", bon courage à toi  :Wink: 

----------

## pti-rem

Salut El_Goretto

Jouer avec les options logicielles de Portage n'est pas effectivement totalement fiable ; certaines compilations montent quand même haut la température, c'est suivant les paquets.

Mais quand même, dans l'ensemble, j'ai l'impression d'avoir une baisse.

En outre, c'est vraiment les mises à jour avec Portage qui sont longues et qui chauffent dur ; Mon usage quotidien est tout à fait tiède.

J'ouvre mon portable plusieurs fois par an depuis son achat pour un dépoussiérage et nettoyage ; c'est le moment d'ailleurs mais la météo s'y prête un peu mal.

Ce portable se salit très vite, c'est dû à la vie en baraque bricolée et poussiéreuse - tabac, chauffage au bois, etc... - que je mène.

Je m'inquiète à chaque coup d'entretien pour le petit clip plastique de blocage de la nappe du clavier.

J'ai même cassé une pale du ventilo en soufflant de trop près au compresseur... Heureusement qu'un ange aux doigts de fée a su bien la recoller (Ouf !)

J'ignore encore si sur ce modèle n73sm des pads thermiques sont placés au niveau des deux zones principales de refroidissement (en dessous, contre la puce) et qui mènent en conduite en cuivre au dissipateur + ventilo d'extraction ; tout l'ensemble me semble métallique.

C'est un bricolage risqué de démonter l'ensemble de refroidissement et surtout de bien le remonter ; je n'ai jamais fait cette maintenance pour un portable et je ne suis pas certain de bien le faire ou même si c'est à faire.

La poussière joue pour beaucoup.

Je ne connaissais pas ce mécanisme de "throttling" ; est-il indépendant de tout logiciel à la base ?

Je vais chercher.

J'ai un mécanisme hardware de "Too HOT Shutdown" : le portable s'éteint tout net. De mémoire, ça m'est arrivé trois fois.

Le temps n'a pas d'importance.

Bon courage à toi aussi  :Smile: 

Merci

----------

## pti-rem

Bonsoir,

J'ai repris les recommandations de sebB pour mon i7-2670QM CPU @ 2.20GHz :

```
MAKEOPTS="-j4 -l8"

EMERGE_DEFAULT_OPTS="--jobs=4 --load-average=4.0 --keep-going --with-bdeps=y"
```

Je désactive maintenant le Turbo Boost jusqu'à 3,1 GHz du processeur avant de faire une mise à jour :

```
echo 1 > /sys/devices/system/cpu/intel_pstate/no_turbo
```

Et elle se passe vraiment mieux ; bien moins de montée en température et moins de bruit fort du ventilateur d'extraction.

J'ai compulsé quelques liens pour m'informer et comprendre le mécanisme de "throttling" ;

En première lecture, je vois que la T JUNCTION de 100 °C de ce processeur me semble bien élevée.

De quoi faire souffler très chaud et bruyant avant d'enclencher le "throttling".

https://ark.intel.com/products/53469/Intel-Core-i7-2670QM-Processor-6M-Cache-up-to-3_10-GHz

Je dois encore étudier ce mécanisme.

 *Quote:*   

> En outre, c'est vraiment les mises à jour avec Portage qui sont longues et qui chauffent dur ; Mon usage quotidien est tout à fait tiède.

 

Il y a aussi les transcodages du serveur Plex qui peuvent faire chauffer dur et souffler fort ; mais dans ce cas j'accepte de les laisser se faire - pour le moment - en Turbo Boost activé.

----------

## Dominique_71

J'ouvre mon portable 2 fois par année pour enlever la poussière. La fréquence exacte dépend de l'utilisation et de l'environnement mais une fois par année me semble un minimum pour une machine qui tourne tous les jours.

EDIT: Cela est valable pour n'importe quelle électronique qui n'est pas scellée. Il y en a qui vont être surpris. ENDEDIT

Le plus important est le ventilateur. Envoyer de l'air comprimé dans le ventilo n'est pas la solution car il va tourner tellement vite qu'il sera inutilisable après. Il reste donc le tournevis, le pinceau et l'aspirateur. Pour la pâte thermique, si le portable a été bien monté avec de la pâte de qualité, je conseille de pas toucher sauf si c'est impossible d'accéder au ventilo pour le nettoyer sans démonter un truc qui est monté avec de la pâte. Par contre si tu démontes quelque chose qui est monté avec de la pâte thermique (ou simplement s'il a bougé), il faut enlever complètement la pâte avec de l'isopropanol (ou de l'alcool à brûler, mais avec les fréquences actuelles des CPU, l'isopropanol est vraiment conseillé car si les 2 ne laissent pas de trace, l'isopropanol s'évapore beaucoup plus vite même s'il va se glisser dans des endroits minuscules.) et remonter en mettant de la pâte neuve.

----------

