# Rebasculer de ~arch vers arch (sans ACCEPT_KEYWORDS)

## pti-rem

Bonjour,

Je crée ce sujet suite à la discussion « ACCEPT_KEYWORDS et package.accept_keywords (~arch) » avec guitou, ghoti et sebB.

Lors d'une mise à jour périlleuse récente de mon système, j'ai dû utiliser ACCEPT_KEYWORDS="~amd64" dans /etc/portage/make.conf

Il me semble que le simple paquet app-eselect/eselect-opengl aurait dû être effacé au préalable pour pouvoir l'éviter.

Les commentaires à ce propos sont les bienvenus.

Désormais, il n'existe plus de mention ACCEPT_KEYWORDS dans mon /etc/portage/make.conf

J'ai créé un nouveau /etc/portage/package.accept_keywords pour tous les paquets installés, sous la forme « =xxx/yyy-1.2.3::repository » afin de les figer.

```
equery list -F '=$cpv::$repo' '*'
```

Je souhaite basculer comme auparavant et ce n'est pas une mince affaire, ni une histoire de quelques heures ; cela va être long.

 *NeddySeagoon wrote:*   

> https://forums.gentoo.org/viewtopic-p-8153130.html#8153130
> 
> Hell might freeze over first 
> 
> 

 

 *sebB wrote:*   

> Par le jeu des dépendances, ça va vite devenir bloquant si tu n'es pas vigilant.
> 
> Le but étant d'éviter les downgrade, donc jouer avec le package.accept_keywords un bon moment encore.
> 
> Il faut que, soit tes paquets instables deviennent stable, soit qu'une version stable supérieure arrive.

 

Ce sujet est là pour aider en cas de pépin ou lors de questionnement relatif aux choix qui seront amenés à faire.

Je ne suis pas inquiet car mon système répond bien et je veux bien prendre le temps pour voir venir.

Je compte actualiser l'arbre de Gentoo et faire une mise à jour chaque matin.

Pour faire le eix-sync -a (dont emerge --sync) ; C'est bien une fois par 24h maximum pour ne pas être banni temporairement ?

 *https://www.gentoo.org/support/rsync-mirrors/  wrote:*   

> Sync netiquette
> 
> Please note: common gentoo-netiquette says you should not sync more than once a day.
> 
> Users who abuse the rsync.gentoo.org rotation may be added to a temporary ban list.

 

Merci !Last edited by pti-rem on Sun Apr 26, 2020 8:05 am; edited 1 time in total

----------

## pti-rem

Bonjour,

L'overlay local figé de l'arbre de Portage est en place depuis cette nuit ; Il est nommé « gentoo-2020 »

J'ai eu un premier conflit :

```
These are the packages that would be merged, in order:

Calculating dependencies... done!

Total: 0 packages, Size of downloads: 0 KiB

WARNING: One or more updates/rebuilds have been skipped due to a dependency conflict:

dev-ruby/xmlrpc:0

  (dev-ruby/xmlrpc-0.3.0:0/0::gentoo-2020, ebuild scheduled for merge) USE="-doc -test" ABI_X86="(64)" RUBY_TARGETS="ruby24 ruby25 (-ruby26) (-ruby27)" conflicts with

    >=dev-ruby/xmlrpc-0.3.0[ruby_targets_ruby27] required by (dev-lang/ruby-2.7.0:2.7/2.7::gentoo, installed) USE="berkdb examples gdbm ipv6 rdoc ssl -debug -doc -jemalloc -jit -libressl -rubytests -socks5 -static-libs -tk -xemacs" ABI_X86="(64)"

                            ^^^^^^^^^^^^^^^^^^^ 

Nothing to merge; quitting.
```

```
These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild   R    ] dev-ruby/xmlrpc-0.3.0::gentoo-2020 [0.3.0::gentoo] USE="-doc -test" RUBY_TARGETS="ruby24 ruby25 (-ruby26) (-ruby27*)" 0 KiB

Total: 1 package (1 reinstall), Size of downloads: 0 KiB

!!! Multiple package instances within a single package slot have been pulled

!!! into the dependency graph, resulting in a slot conflict:

dev-ruby/xmlrpc:0

  (dev-ruby/xmlrpc-0.3.0:0/0::gentoo-2020, ebuild scheduled for merge) USE="-doc -test" ABI_X86="(64)" RUBY_TARGETS="ruby24 ruby25 (-ruby26) (-ruby27)" pulled in by

    dev-ruby/xmlrpc (Argument)

  (dev-ruby/xmlrpc-0.3.0:0/0::gentoo, installed) USE="-doc -test" ABI_X86="(64)" RUBY_TARGETS="ruby24 ruby25 ruby27 -ruby26" pulled in by

    >=dev-ruby/xmlrpc-0.3.0[ruby_targets_ruby27] required by (dev-lang/ruby-2.7.0:2.7/2.7::gentoo, installed) USE="berkdb examples gdbm ipv6 rdoc ssl -debug -doc -jemalloc -jit -libressl -rubytests -socks5 -static-libs -tk -xemacs" ABI_X86="(64)"

                            ^^^^^^^^^^^^^^^^^^^                                                                                 

It might be possible to solve this slot collision

by applying all of the following changes:

   - dev-ruby/xmlrpc-0.3.0 (Change USE: +ruby_targets_ruby27)
```

J'ai choisi de faire la modification suivante :

```
#

# */*::gentoo-2020 : préexistant

#

=dev-ruby/xmlrpc-0.3.0:0/0::gentoo-2020 # ajouté sam. mars 28 09:55:59 CET 2020

```

Je n'ai plus de mise à jour proposée après cette modification :

```
These are the packages that would be merged, in order:

Calculating dependencies... done!

Total: 0 packages, Size of downloads: 0 KiB

Nothing to merge; quitting.
```

Je ne pense pas que j'aurais pu jouer avec package.accept_keywords pour solutionner autrement ce conflit.

édition : je pense que ce conflit n'aurait pas eu lieu si la priorité de mon overlay avait été inférieure à celle du dépôt gentoo officiel.

Ce n'était pas le cas et c'est rectifié avec priority = -2000 pour mon overlay local.

 *'en utilisant euse' wrote:*   

> Metadata cache not found. You need to run !!! 'egencache --repo=gentoo-2020 --update' !!! to generate metadata for your overlays

 

Je m'exécute donc : cette commande est particulièrement longue... (pour l'overlay en question)

Je n'ai plus besoin d'exclure mon overlay local de la commande /usr/bin/eix-update (avec -x) depuis que le cache des métadonnées a été généré. La lenteur n'est plus de mise  :Smile: 

J'ai renommé mon overlay « g20 » : c'est moins long à saisir que « gentoo-2020 »  :Wink: Last edited by pti-rem on Sun Mar 29, 2020 4:17 pm; edited 1 time in total

----------

## pti-rem

Bonjour,

```
n73sm ~ # emerge -pv  =app-shells/quoter-3.0_p2-r1::gentoo =app-shells/push-2.0-r1::gentoo =app-portage/eix-0.33.9-r1::gentoo

These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild   R    ] app-shells/quoter-3.0_p2-r1::gentoo  0 KiB

[ebuild   R    ] app-shells/push-2.0-r1::gentoo  0 KiB

[ebuild   R    ] app-portage/eix-0.33.9-r1::gentoo  USE="debug doc nls sqlite" 0 KiB

Total: 3 packages (3 reinstalls), Size of downloads: 0 KiB

n73sm ~ #
```

```
n73sm ~ # gcc-config -l

 [1] x86_64-pc-linux-gnu-8.3.0

 [2] x86_64-pc-linux-gnu-9.2.0 *

 [3] x86_64-pc-linux-gnu-9.3.0

n73sm ~ # 
```

```
n73sm ~ # emerge -pv dev-lang/python:2.7 dev-lang/python:3.6 dev-lang/python:3.7 dev-lang/python:3.8 dev-lang/python:3.9

These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild   R    ] dev-lang/python-2.7.17-r1:2.7::gentoo  USE="bluetooth examples gdbm ipv6 ncurses readline sqlite ssl (threads) (wide-unicode) xml (-berkdb) -build -hardened -libressl -tk -wininst" 0 KiB

[ebuild   R    ] dev-lang/python-3.6.10:3.6/3.6m::gentoo  USE="bluetooth examples gdbm ipv6 ncurses readline sqlite ssl (threads) xml -build -hardened -libressl -test -tk -wininst" 0 KiB

[ebuild   R    ] dev-lang/python-3.7.7:3.7/3.7m::gentoo  USE="bluetooth examples gdbm ipv6 ncurses readline sqlite ssl xml -build -hardened -libressl -test -tk -wininst" 0 KiB

[ebuild   R   ~] dev-lang/python-3.8.2:3.8::gentoo  USE="bluetooth examples gdbm ipv6 ncurses readline sqlite ssl xml -build -hardened -libressl -test -tk -wininst" 0 KiB

[ebuild   R   ~] dev-lang/python-3.9.0_alpha5:3.9::gentoo  USE="bluetooth examples gdbm ipv6 ncurses readline sqlite ssl xml -build -hardened -libressl -test -tk -wininst" 0 KiB

Total: 5 packages (5 reinstalls), Size of downloads: 0 KiB

n73sm ~ # eselect python list

Available Python interpreters, in order of preference:

  [1]   python3.6

  [2]   python3.7

  [3]   python3.8

  [4]   python2.7

n73sm ~ #
```

```
n73sm ~ # eselect binutils list

 [1] x86_64-pc-linux-gnu-2.33.1

 [2] x86_64-pc-linux-gnu-2.34 *

n73sm ~ # eselect binutils set 1

 * Switching to x86_64-pc-linux-gnu-2.33.1 ...                                                                                                                                     [ ok ]

 * Please remember to run:

 *   # . /etc/profile

n73sm ~ # . /etc/profile

n73sm ~ #
```

Il me reste la glibc-2.30-r6 qui est encore instable aujourd'hui :

```
Portage 2.3.96 (python 3.6.10-final-0, default/linux/amd64/17.1/desktop, gcc-9.2.0, glibc-2.30-r6, 4.19.97-gentoo x86_64)
```

Je ne touche pas à la glibc car je pense que c'est trop risqué pour le système.Last edited by pti-rem on Tue Mar 31, 2020 8:00 am; edited 2 times in total

----------

## pti-rem

Bonjour,

net-libs/libvncserver-0.9.12-r5 vient de devenir stable ce 30 mars dernier.

Je pense qu'il s'agit du premier de mes paquets à évoluer en version stable naturellement - grâce aux développeurs ;

en suivant le principe défini au départ avec sebB.

Autrement, sys-auth/rtkit ne dépend que de app-emulation/wine-vanilla dans mon système.

```
n73sm ~ # emerge -p sys-auth/rtkit

[ebuild   R    ] sys-auth/rtkit-0.11-r2 

n73sm ~ #
```

```
n73sm ~ # eselect wine list

Available wine versions:

  [1]   wine-vanilla-4.0.2 *

  [2]   wine-vanilla-5.4

n73sm ~ #
```

Mon captvty-2.7.8 (pas à jour) fonctionne sous wine comme auparavant.

```
n73sm ~ # emerge -avuDN =sys-libs/binutils-libs-2.33.1-r1::gentoo

These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild     UD ] sys-libs/binutils-libs-2.33.1-r1:0/2.33.1::gentoo [2.34:0/2.34::gentoo] USE="nls -64-bit-bfd -multitarget -static-libs" ABI_X86="32 (64) (-x32)" 0 KiB

[ebuild  rR    ] x11-libs/cairo-1.16.0-r3::gentoo  USE="X glib opengl svg (-aqua) -debug (-gles2-only) -static-libs -utils -valgrind" ABI_X86="32 (64) (-x32)" 0 KiB

Total: 2 packages (1 downgrade, 1 reinstall), Size of downloads: 0 KiB

WARNING: One or more updates/rebuilds have been skipped due to a dependency conflict:

sys-libs/binutils-libs:0

  (sys-libs/binutils-libs-2.34:0/2.34::gentoo, ebuild scheduled for merge) USE="nls -64-bit-bfd -multitarget -static-libs" ABI_X86="32 (64) (-x32)" conflicts with

    =sys-libs/binutils-libs-2.33.1-r1::gentoo

The following packages are causing rebuilds:

  (sys-libs/binutils-libs-2.33.1-r1:0/2.33.1::gentoo, ebuild scheduled for merge) causes rebuilds for:

    (x11-libs/cairo-1.16.0-r3:0/0::gentoo, ebuild scheduled for merge)

Would you like to merge these packages? [Yes/No] n

Quitting.

n73sm ~ # eselect binutils list

 [1] x86_64-pc-linux-gnu-2.33.1 *

 [2] x86_64-pc-linux-gnu-2.34

n73sm ~ # eselect binutils set 2

 * Switching to x86_64-pc-linux-gnu-2.34 ...                                                                                                                                       [ ok ]

 * Please remember to run:

 *   # . /etc/profile

n73sm ~ # . /etc/profile

n73sm ~ #
```

----------

## pti-rem

Bonjour,

 *eix-diff wrote:*   

> [?]   == sys-libs/glibc (2.30-r6(2.2)@22/03/2020; (~)2.30-r6(2.2)^t -> 2.29-r7(2.2)^t): GNU libc C library

 

La version installée (~)2.30-r6(2.2)^t de sys-libs/glibc n'existe plus.

La 2.29-r7(2.2)^t est une version stable nouvelle.

emerge -pvuDN @world ne propose aucune mise à jour.

```
n73sm ~ # emerge -avuDN =sys-libs/glibc-2.29-r7:2.2::gentoo

These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild     UD ] sys-libs/glibc-2.29-r7:2.2::gentoo [2.30-r6:2.2::gentoo] USE="multiarch (multilib) ssp -audit -caps (-cet) -compile-locales -doc -gd -headers-only -nscd -profile (-selinux) -suid -systemtap -test (-vanilla) (-crypt%*) (-custom-cflags%) (-static-libs%*)" 0 KiB

Total: 1 package (1 downgrade), Size of downloads: 0 KiB

Would you like to merge these packages? [Yes/No] n

Quitting.

n73sm ~ #
```

sys-libs/glibc : c'est délicat !

J'ai le souvenir d'un plantage irrémédiable.

Je ne sais pas quel comportement adopter.

Le plus sage est de suivre Portage normalement, donc de ne rien changer.

Ou alors upgrader vers la version 2.30-r7 : 2.2 ?

Je voudrais avoir des avis.

C'est quoi ce suffixe ^t de eix-diff ? il veut dire quoi ?

Merci

```
n73sm ~ # qgrep -JlNR -x "~amd64 +" | sort | uniq | wc -l

508

n73sm ~ #
```

----------

## YetiBarBar

Bonjour,

Tu n'avais pas mis l'overlay glibc dans ton overlay portage local?

Tu peux encore rattraper le coup en téléchargeant un snapshot un peu vieux ici: http://distfiles.gentoo.org/snapshots/

Ta version installée était au moins présente le 1er avril. Un conseil, garde le snapshot sous le coude pour retrouver des ebilds qui disparaitrait... Avec un snapshot complet dans ton overlay, tu figes un arbre, qui s'élagueras au fur et à mesure que tes paquets seront remplacés. Là où tu peux éventuellement avoir des ennuis avec cette méthode, c'est en cas de disparition d'un fichier distfiles des serveurs distants.

PS: En revanche, on ne downgrade JAMAIS glibc "unless you understand that you will break your gentoo"... https://forums.gentoo.org/viewtopic-t-845000.html

----------

## pti-rem

Bonsoir,

 *YetiBarBar wrote:*   

> Tu n'avais pas mis l'overlay glibc dans ton overlay portage local?

 

Je n'ai pas mis d'overlay spécifique hormis avoir fait :

```
n73sm /opt # git clone https://anongit.gentoo.org/git/repo/gentoo.git

Clonage dans 'gentoo'...

remote: Enumerating objects: 12713, done.

remote: Counting objects: 100% (12713/12713), done.

remote: Compressing objects: 100% (10374/10374), done.

remote: Total 2257650 (delta 5149), reused 5075 (delta 2338)

Réception d'objets: 100% (2257650/2257650), 571.07 Mio | 2.08 Mio/s, fait.

Résolution des deltas: 100% (1584431/1584431), fait.

Mise à jour des fichiers: 100% (89889/89889), fait.

n73sm /opt # date

ven. mars 27 23:11:03 CET 2020

n73sm /opt # mv gentoo gentoo-2020

```

Donc je pense que oui :

```
rem@n73sm ~ $ ls -l /opt/gentoo-2020/sys-libs/glibc/glibc-2.30-r6.ebuild

-rw-r--r-- 1 root root 43434 27 mars  23:08 /opt/gentoo-2020/sys-libs/glibc/glibc-2.30-r6.ebuild

rem@n73sm ~ $

rem@n73sm ~ $ du -h --max-depth=0 /opt/gentoo-2020/

1,3G   /opt/gentoo-2020/

rem@n73sm ~ $ 
```

C'est équivalent à un snapshot ?

Vaut-il mieux que je fige et réinstalle =sys-libs/glibc-2.30-r6::g20 sur =sys-libs/glibc-2.30-r6::gentoo ?

Je veux dire par figer, mettre =sys-libs/glibc-2.30-r6::g20 dans mon package.accept_keywords à la place de =sys-libs/glibc-2.30-r6::gentoo

Mon overlay local « g20 » est moins prioritaire (-2000) que l'overlay gentoo (-1000)

Donc, il n'est pas sollicité, dû moins jusqu'ici : Je n'ai pas de paquet de cet overlay « g20 » qui soit proposé lors des mises à jour fréquentes du système.

Je pense avoir les outils mais il faudrait en théorie ne pas upgrader en ~arch, ni downgrader.

En pratique, je fais des choix personnels parfois ; exemples : upgrade en ~arch de app-editors/nano et de sys-apps/man-pages ou downgrade en stable de app-portage/eix et sys-auth/rtkit.

Je dois avoir besoin d'un rappel pour la stratégie pratique...

 *sebB wrote:*   

> Il faut que, soit tes paquets instables deviennent stable, soit qu'une version stable supérieure arrive.
> 
> Par le jeu des dépendances, ca va vite devenir bloquant si tu n'est pas vigilant.
> 
> Le but étant d'éviter les downgrade, donc jouer avec le package.keyword un bon moment encore

 

Je ne cherche pas à avoir que des paquets stables installés à terme.

Je ne sais pas comment on peut nommer une Gentoo stable avec une évolution de certains paquets en ~arch ?

J'avais déjà nombre de paquets en ~arch installés avant d'avoir fait la mise à jour malheureuse avec ACCEPT_KEYWORDS="~amd64" dans mon /etc/portage/make.conf

Quels éléments pourront dire que je reviens "comme avant" ? ; maintenant que je suis sans ACCEPT_KEYWORDS.

Le remplacement en version équivalente stable ou en version stable plus élevée ? (comme sebB l'explique)

Alors, comment différencier les paquets qui doivent respecter cette logique de ceux avec lesquels j'ai davantage de latitude ?

Je vois que je me complique la réflexion mais je n'ai pas trouvé vraiment le comportement à réitérer.

C'est encore jeune tout ça  :Wink: 

 *YetiBarBar wrote:*   

> En revanche, on ne downgrade JAMAIS glibc

 

C'est très clair. Merci.

----------

## YetiBarBar

Bonjour,

Ton overlay ne te sers à rien si tu ne mets pas d'accept_keyword pour les paquets de ton overlay. Il ne faut pas en avoir peur. Si une version plus "haute" que celle de ton overlay stabilise, elle sera installé.

Perso, ce que j'aurai fait pour stabiliser mon système dans ton cas:

- copie des ebuilds dans un overlays;

- récupération de la liste des paquets ~arch à l'aide d'eix;

- ajout de ces paquets dans acept_keyword pour les 2 ebuilds: celui de portage "main" et celui de ton "overlay" (les 2 pour être sûr d'éviter un rebuild).

Et ensuite attente que tout stabilise. C'est à peut près ce que tu as fait, sauf que tu n'as pas déclaré que tu acceptais les ebuilds de ton overlay;

Dans ton cas particulier, pour glibc, quitte à avoir un rebuild, perso je démasquerai la toute dernière de l'arbre portage officiel qui est un bump d'une version mineure (on reste sur la même version de glibc, il n'y a "que" quelques patches qui change).

----------

## pti-rem

Bonjour YetiBarBar,

J'ai des difficultés à comprendre l'avantage de ta proposition et également à envisager techniquement comment la mettre en œuvre.

Je ne suis pas d'accord avec de surcroît ; voir le conseil de sebB à https://forums.gentoo.org/viewtopic-p-8436564.html#8436564 (et autour)

 *YetiBarBar wrote:*   

> Ton overlay ne te sers à rien si tu ne mets pas d'accept_keyword pour les paquets de ton overlay.
> 
> 

 

La double liste des paquets en ~arch serait bien trop volumineuse pour un package.accept_keywords non ?

J'ai actuellement 1711 entrées avec le equery list -F '=$cpv::$repo' '*' > /etc/portage/package.accept_keywords que j'effectue après le revdep-rebuild -- -av de chaque mise à jour.

```
n73sm ~ # qgrep -lNR -x "~amd64 +" | sort | uniq | wc -l

30598

n73sm ~ # qgrep -lNR -x "~amd64 +" | sort | uniq | grep "::g20" | wc -l

15335

n73sm ~ # qgrep -lNR -x "~amd64 +" | sort | uniq | grep "::gentoo" | wc -l

15263

n73sm ~ #
```

Et si j'ai bien compris, tu aurais accepté un nombre éventuellement conséquent de mises à jour en ~arch (voire en downgrade) pour ensuite attendre que tout se stabilise ?

 *YetiBarBar wrote:*   

> C'est à peut près ce que tu as fait, sauf que tu n'as pas déclaré que tu acceptais les ebuilds de ton overlay

 

Mon overlay g20 est une sorte de sauvegarde des ebuilds à un moment t pour pouvoir en disposer même si Gentoo décide de supprimer un paquet de l'arbre principal.

```
n73sm ~ # equery has repository g20

 * Searching for repository g20 ... 

[I-O] [  ] kde-frameworks/attica-5.68.0:5/5.68

[I-O] [  ] kde-frameworks/extra-cmake-modules-5.68.0:5/5.68

[I-O] [  ] kde-frameworks/karchive-5.68.0:5/5.68

[I-O] [  ] kde-frameworks/kauth-5.68.0:5/5.68

[I-O] [  ] kde-frameworks/kbookmarks-5.68.0:5/5.68

[I-O] [  ] kde-frameworks/kcmutils-5.68.0:5/5.68

[I-O] [  ] kde-frameworks/kcodecs-5.68.0:5/5.68

[I-O] [  ] kde-frameworks/kcompletion-5.68.0:5/5.68

[I-O] [  ] kde-frameworks/kconfig-5.68.0:5/5.68

[I-O] [  ] kde-frameworks/kconfigwidgets-5.68.0:5/5.68

[I-O] [  ] kde-frameworks/kcoreaddons-5.68.0:5/5.68

[I-O] [  ] kde-frameworks/kcrash-5.68.0:5/5.68

[I-O] [  ] kde-frameworks/kdbusaddons-5.68.0:5/5.68

[I-O] [  ] kde-frameworks/kdeclarative-5.68.0:5/5.68

[I-O] [  ] kde-frameworks/kded-5.68.0:5/5.68

[I-O] [  ] kde-frameworks/kdoctools-5.68.0:5/5.68

[I-O] [  ] kde-frameworks/kfilemetadata-5.68.0:5/5.68

[I-O] [  ] kde-frameworks/kglobalaccel-5.68.0:5/5.68

[I-O] [  ] kde-frameworks/kguiaddons-5.68.0:5/5.68

[I-O] [  ] kde-frameworks/ki18n-5.68.0:5/5.68

[I-O] [  ] kde-frameworks/kiconthemes-5.68.0:5/5.68

[I-O] [  ] kde-frameworks/kinit-5.68.0:5/5.68

[I-O] [  ] kde-frameworks/kio-5.68.0:5/5.68

[I-O] [  ] kde-frameworks/kirigami-5.68.0:5/5.68

[I-O] [  ] kde-frameworks/kitemviews-5.68.0:5/5.68

[I-O] [  ] kde-frameworks/kjobwidgets-5.68.0:5/5.68

[I-O] [  ] kde-frameworks/knewstuff-5.68.0:5/5.68

[I-O] [  ] kde-frameworks/knotifications-5.68.0:5/5.68

[I-O] [  ] kde-frameworks/knotifyconfig-5.68.0:5/5.68

[I-O] [  ] kde-frameworks/kpackage-5.68.0:5/5.68

[I-O] [  ] kde-frameworks/kservice-5.68.0:5/5.68

[I-O] [  ] kde-frameworks/ktextwidgets-5.68.0:5/5.68

[I-O] [  ] kde-frameworks/kwallet-5.68.0:5/5.68

[I-O] [  ] kde-frameworks/kwidgetsaddons-5.68.0:5/5.68

[I-O] [  ] kde-frameworks/kwindowsystem-5.68.0:5/5.68

[I-O] [  ] kde-frameworks/kxmlgui-5.68.0:5/5.68

[I-O] [  ] kde-frameworks/oxygen-icons-5.68.0:5/5.68

[I-O] [  ] kde-frameworks/solid-5.68.0:5/5.68

[I-O] [  ] kde-frameworks/sonnet-5.68.0:5/5.68

[I-O] [  ] sys-libs/glibc-2.30-r6:2.2

n73sm ~ #
```

Je vais laisser en place =sys-libs/glibc-2.30-r6::g20 (qui m'a demandé un rebuild) jusqu'à la prochaine stabilisation.

 *YetiBarBar wrote:*   

> perso je démasquerai la toute dernière de l'arbre portage officiel qui est un bump d'une version mineure

 

C'est laquelle exactement ? désolé de faire un peu boulet  :Wink: 

Je ne rejette pas tout en bloc, c'est surtout que j'ai mal compris et que je croyais détenir un début de méthode. Je verrai bien avec le temps.

Merci tout de même  :Smile: 

Autrement, j'ai préféré revenir à la version testing de eix (=app-portage/eix-0.33.11::gentoo) et de portage (=sys-apps/portage-2.3.98-r1::gentoo)

```
n73sm ~ # emerge --version

Portage 2.3.98 (python 3.6.10-final-0, default/linux/amd64/17.1/desktop, gcc-9.2.0, glibc-2.30-r6, 4.19.97-gentoo x86_64)

n73sm ~ #
```

----------

## YetiBarBar

Bonjour,

Je pense qu'effectivement, on s'est mal compris.

Pour repasser en arch, tu as du mettre un bon groupe de paquets de l'arbre officiel dans le fichier

```
/etc/portage/packages.keywords
```

 (a noter que ce fichier peut etre remplacé par un répertoire pour plus d'organisation) afin que portage ne te les downgrade pas. 

Ma proposition était simplement de rajouter un doublon de cette ligne avec une référence à ton nouvel arbre pour que portage s'y reporte automatiquement en cas de disparition d'ebuild. Néanmoins, c'est effectivement plus simple de le faire à la main pour chaque disparition comme tu viens de le faire. Celà n'aurait pas entrainé de recompilation tant que les paquets ne disparaissent pas de l'arbre.

Tu tiens effectivement la bonne méthode pour stabiliser ton install. Il va juste falloir du temps.

Pour glibc, tu ne coupais pas à une recompilation, soit de glibc-2.30-r6::g20, soit de glibc-2.30-r8. Maintenant que tu l'a recompilé, n'y touche plus jusqu'à la stabilisation ! A ce moment là, tu auras droit à une nouvelle recompilaton.

Por info, sais-tu combien il te reste de paquets instables ?

```
eix --installed-unstable
```

----------

## pti-rem

Bonjour,

Le fichier ou le répertoire /etc/portage/package.keywords sont déclarés comme "deprecated" par Gentoo ; le remplaçant est /etc/portage/package.accept_keywords

J'ai préféré m'y soumettre mais je ne pense pas que ce soit une bonne évolution.

J'y place l'ensemble de mes paquets installés sous la forme « =xxx/yyy-1.2.3::repository » avec :

```
equery list -F '=$cpv::$repo' '*' > /etc/portage/package.accept_keywords
```

dès que la liste des paquets installés change et aussi pour remettre en ordre ce fichier.

J'ai par exemple choisi hier d'installer le paquet testing =sys-apps/file-5.38-r1::gentoo sur le testing =sys-apps/file-5.38::gentoo

J'ai dû pour ce faire ajouter auparavant =sys-apps/file-5.38-r1::gentoo à la fin de /etc/portage/package.accept_keywords

Il y a à la fois les paquets installés depuis l'arbre officiel ainsi que des paquets installés depuis mon overlay local « g20 » dans ce gros fichier /etc/portage/package.accept_keywords

Je constate un certain ralentissement avant que l'invite pour le choix ne revienne lors d'un emerge -avuDN @world

 *YetiBarBar wrote:*   

> Tu tiens effectivement la bonne méthode pour stabiliser ton install. Il va juste falloir du temps.

 

Je pense qu'il y a dans mon /etc/portage/package.accept_keywords des paquets qui pourraient / devraient ne pas y figurer ; notamment les paquets déjà stables.

Je ne sais pas si je vais y remédier - il le faudrait peut-être - ni encore comment surtout...

Il me semble qu'une commande eix --installed-unstable avec une sortie formatée pourrait convenir.

édition :

Après quelques essais, je doute beaucoup sur ce point : Mon gros /etc/portage/package.accept_keywords ne va pas grossir encore énormément et la méthode d'utilisation est simple.

Alors qu'en enlever les paquets déjà stables me donne des downgrades à gérer et globalement une méthode plus complexe.

Je vais laisser mûrir  :Wink: 

Oui, ça va prendre du temps, mais je ne comprends pas bien comment peut se définir le point de basculement entre l'état actuel et l'état stable retrouvé ;

d'autant plus que j'utilisais, j'utilise et j'utiliserai encore des paquets testing ?

Au fond, l'état stable est déjà retrouvé, non ? ou au minimum défini.

 *YetiBarBar wrote:*   

> Ma proposition était simplement de rajouter un doublon de cette ligne avec une référence à ton nouvel arbre pour que portage s'y reporte automatiquement en cas de disparition d'ebuild.

 

Je comprends le principe. J'ai déjà à faire pour diminuer mon /etc/portage/package.accept_keywords et je me méfie un peu des automatismes.

 *YetiBarBar wrote:*   

> Néanmoins, c'est effectivement plus simple de le faire à la main pour chaque disparition comme tu viens de le faire.

 

J'ai eu la chance d'observer la sortie d'eix-diff et de me reporter à la page sys-libs/glibc.

Je pense qu'il y a encore un certain nombre de paquets installés dans mon système qui ont déjà disparu de l'arbre officiel.

Je ne crois pas que ce soit bien grave.

 *YetiBarBar wrote:*   

> Pour glibc, tu ne coupais pas à une recompilation, soit de glibc-2.30-r6::g20, soit de glibc-2.30-r8. Maintenant que tu l'a recompilé, n'y touche plus jusqu'à la stabilisation !

 

Oui, c'est bien entendu.

Mais en fait, je pense que j'ai dû probablement recompiler glibc de manière identique bit à bit par rapport à la version disparue =sys-libs/glibc-2.30-r6::gentoo mais qui était installée.

 *eix --installed-unstable wrote:*   

> Found 484 matches

 

 *'un autre compte avec eix' wrote:*   

> n73sm ~ # EIX_LIMIT=0 eix --installed-in-some-overlay --installed-unstable --pure-packages --format '<installedversions:EQNAMEVERSION>' | wc -l
> 
> 504
> 
> n73sm ~ #

 

Ce n'est pas tant le nombre de paquets testing installés qui compte.

Ce que je comprends maintenant, c'est que je préfère une Gentoo stable (donc sans ACCEPT_KEYWORDS="~arch" dans /etc/make.conf) pour choisir d'autoriser les paquets testing à s'installer ou non.

Alors qu'avec une Gentoo testing, je pense qu'il faut veiller particulièrement à l'escalade naturelle des paquets testing qui s'installent.

Cela m'évoque une différence pour les permissions entre les OS réseau NT et Netware ; dans l'un, il fallait autoriser alors que dans l'autre, il s'agissait d'interdire ou de restreindre.

C'était pour l'anecdote.

----------

## pti-rem

 *Quote:*   

>  *YetiBarBar wrote:*   Ma proposition était simplement de rajouter un doublon de cette ligne avec une référence à ton nouvel arbre pour que portage s'y reporte automatiquement en cas de disparition d'ebuild. 
> 
> Je comprends le principe. J'ai déjà à faire pour diminuer mon /etc/portage/package.accept_keywords et je me méfie un peu des automatismes.
> 
>  *YetiBarBar wrote:*   Néanmoins, c'est effectivement plus simple de le faire à la main pour chaque disparition comme tu viens de le faire. 

 

J'essaie une façon :

J'ai placé */*::g20 dans /etc/portage/package.accept_keywords - à la suite de ma liste ordinaire.

J'ai eu une possibilité de mises à jour suivante :

```
n73sm ~ # emerge -pvuDN @world

These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild     U ~] dev-libs/ell-0.30::g20 [0.28::gentoo] USE="-glib -pie" ABI_X86="(64) -32 (-x32)" 467 KiB

[ebuild     U ~] media-libs/leptonica-1.79.0:0/5::g20 [1.74.4:0/5::gentoo] USE="gif jpeg png tiff zlib -jpeg2k -static-libs -test -utils -webp" ABI_X86="(64) -32 (-x32)" 0 KiB

[ebuild  NS   ~] sys-kernel/gentoo-sources-5.5.13:5.5.13::g20 [4.14.83:4.14.83::gentoo, 4.19.27-r1:4.19.27-r1::gentoo, 4.19.37:4.19.37::gentoo, 4.19.44:4.19.44::gentoo, 4.19.97:4.19.97::gentoo, 5.5.11:5.5.11::gentoo] USE="-build -experimental -symlink" 577 KiB

[ebuild     U ~] sys-fs/lvm2-2.02.187::g20 [2.02.186-r2::gentoo] USE="readline thin udev -device-mapper-only -lvm2create_initrd -sanlock (-selinux) -static -static-libs -systemd" 2 350 KiB

[ebuild     U ~] www-client/links-2.20.2-r1:2::g20 [2.20.2:2::gentoo] USE="X bzip2 gpm ipv6 jpeg ssl tiff unicode zlib -brotli -fbcon -freetype -libevent -libressl -livecd -lzip -lzma (-suid) (-svga) -zstd" 0 KiB

[ebuild     U ~] dev-libs/libgusb-0.3.4::g20 [0.3.3::gentoo] USE="introspection vala -gtk-doc -static-libs -test" ABI_X86="(64) -32 (-x32)" 0 KiB

[ebuild     U ~] media-libs/mesa-20.0.2::g20 [19.3.5::gentoo] USE="X classic dri3 egl gallium gbm gles2 libglvnd llvm zstd%* -d3d9 -debug -gles1 -lm-sensors -opencl -osmesa (-selinux) -test -unwind -vaapi -valgrind -vdpau -vulkan -vulkan-overlay -wayland -xa -xvmc (-pax_kernel%)" ABI_X86="32 (64) (-x32)" VIDEO_CARDS="i915 i965 intel (-freedreno) -iris (-lima) -nouveau (-panfrost) -r100 -r200 -r300 -r600 -radeon -radeonsi (-vc4) -virgl (-vivante) -vmware" 0 KiB

[ebuild     U ~] net-libs/nodejs-13.12.0::g20 [13.11.0::gentoo] USE="doc icu inspector npm snapshot ssl system-ssl -debug -pax_kernel -systemtap -test" CPU_FLAGS_X86="sse2" 32 072 KiB

[ebuild     U ~] app-arch/file-roller-3.32.4::g20 [3.32.3::gentoo] USE="libnotify -nautilus (-packagekit)" 835 KiB

[ebuild     U ~] media-libs/libsdl2-2.0.12::g20 [2.0.10-r1::gentoo] USE="X alsa dbus haptic joystick opengl pulseaudio sound threads udev video (-aqua) (-custom-cflags) -gles% -jack% -kms -libsamplerate -nas -oss -static-libs -tslib -vulkan -wayland -xinerama -xscreensaver (-altivec%) (-gles2%)" ABI_X86="32 (64) (-x32)" CPU_FLAGS_X86="mmx sse sse2 -3dnow" VIDEO_CARDS="(-vc4)" 0 KiB

[ebuild     U ~] media-sound/lollypop-1.2.29::g20 [1.1.4.16::gentoo] PYTHON_SINGLE_TARGET="python3_6%*" PYTHON_TARGETS="(-python3_6%*)" 0 KiB

[ebuild     UD~] www-client/firefox-74.0-r1::g20 [74.0-r3::gentoo] USE="gmp-autoupdate pulseaudio screenshot startup-notification system-av1 system-harfbuzz system-icu system-jpeg system-libevent system-libvpx system-sqlite system-webp -bindist -clang -custom-cflags -custom-optimization -debug -eme-free -geckodriver -hardened -hwaccel -jack -lto -pgo (-selinux) -test -wayland -wifi" CPU_FLAGS_X86="-avx2" L10N="en-GB fr -ach -af -an -ar -ast -az -be -bg -bn -br -bs -ca -cak -cs -cy -da -de -dsb -el -en-CA -eo -es-AR -es-CL -es-ES -es-MX -et -eu -fa -ff -fi -fy -ga -gd -gl -gn -gu -he -hi -hr -hsb -hu -hy -ia -id -is -it -ja -ka -kab -kk -km -kn -ko -lij -lt -lv -mk -mr -ms -my -nb -nl -nn -oc -pa -pl -pt-BR -pt-PT -rm -ro -ru -si -sk -sl -son -sq -sr -sv -ta -te -th -tr -uk -ur -uz -vi -xh -zh-CN -zh-TW" 0 KiB

[ebuild     U ~] net-misc/teamviewer-15.4.4445::g20 [15.3.2682::gentoo] 12 751 KiB

[ebuild     U ~] app-emulation/virtualbox-6.1.4-r2::g20 [6.1.4-r1::gentoo] USE="alsa doc opengl opus pam pulseaudio python qt5 sdk udev vnc -debug -dtrace -headless -java -libressl -lvm -pax_kernel -vboxwebsrv" PYTHON_SINGLE_TARGET="python3_6 -python3_7 -python3_8 (-python2_7%)" 3 KiB

[ebuild     U ~] kde-plasma/polkit-kde-agent-5.18.3:5::g20 [5.17.5:5::gentoo] USE="-debug" 0 KiB

Total: 15 packages (13 upgrades, 1 downgrade, 1 in new slot), Size of downloads: 49 051 KiB

WARNING: One or more updates/rebuilds have been skipped due to a dependency conflict:

sys-auth/rtkit:0

  (sys-auth/rtkit-0.12:0/0::g20, ebuild scheduled for merge) USE="-systemd" ABI_X86="(64)" conflicts with

    sys-auth/rtkit::gentoo required by @selected 

                          

sys-devel/gcc:9.2.0

  (sys-devel/gcc-9.2.0-r4:9.2.0/9.2.0::g20, ebuild scheduled for merge) USE="(cxx) fortran (multilib) nls nptl openmp pch (pie) sanitize ssp vtv (-altivec) -d -debug -doc (-fixed-point) -go -graphite (-hardened) (-jit) (-libssp) -lto -objc -objc++ -objc-gc -pgo -systemtap -test -vanilla" ABI_X86="(64)" conflicts with

    sys-devel/gcc:9.2.0::gentoo required by @selected 

                               

n73sm ~ #
```

J'aurais pu facilement l'effectuer mais étant dans un objectif de stabilisation, j'ai décidé de masquer globalement les paquets en question :

```
#

# */*::g20 : préexistant

#

www-client/firefox::g20 # ajouté

sys-auth/rtkit::g20

sys-devel/gcc::g20

dev-libs/ell::g20

media-libs/leptonica::g20

sys-kernel/gentoo-sources::g20

sys-fs/lvm2::g20

www-client/links::g20

dev-libs/libgusb::g20

media-libs/mesa::g20

net-libs/nodejs::g20

app-arch/file-roller::g20

media-libs/libsdl2::g20

media-sound/lollypop::g20

net-misc/teamviewer::g20

app-emulation/virtualbox::g20

kde-plasma/polkit-kde-agent::g20 # le lun. avril 13 17:17:36 CEST 2020 ; voir /root/emerge-pvuDN-world-2020-04-13-0.txt

#

sys-apps/portage::g20

<sys-apps/portage-2.3.98-r1::gentoo # le lun. avril 13 2020
```

Je n'ai donc plus eu cette proposition de mises à jour : « Your system is consistent »

Je pense être au terme de la configuration de ma méthode si ce changement s'avère concluant.

Je vais devoir à terme surveiller les mises à jour pour pouvoir enlever progressivement les masques - qui deviendront inutiles - sur les quelques paquets de mon overlay local g20.

Je comprends maintenant bien mieux sebB quand il disait que je n'aurais plus beaucoup de mises à jour proposées.

Et que je peux désormais les faire moins souvent ; presque comme je le souhaite.

Je suis bien content d'avoir cet overlay local et d'avoir intégré */*::g20 d'un coup d'un seul !

Bon, c'est forcément plus lent à mettre à jour mais c'est la juste contrepartie.

Il y aura peut-être besoin de démasquer, je verrai bien.

Je croise les doigts  :Wink: 

Merci encore sebB & Merci bien YetiBarBar

----------

## pti-rem

```
n73sm ~ # emerge -avuDN @world

These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild  NS    ] sys-kernel/gentoo-sources-5.4.28:5.4.28::gentoo [4.14.83:4.14.83::gentoo, 4.19.27-r1:4.19.27-r1::gentoo, 4.19.37:4.19.37::gentoo, 4.19.44:4.19.44::gentoo, 4.19.97:4.19.97::gentoo, 5.5.11:5.5.11::gentoo] USE="-build -experimental -symlink" 1 093 KiB

[ebuild     U  ] app-text/enchant-2.2.8:2::gentoo [2.2.7:2::gentoo] USE="hunspell -aspell" 954 KiB

[ebuild     U  ] sys-fs/fuse-common-3.9.1::gentoo [3.9.0::gentoo] 0 KiB

Total: 3 packages (2 upgrades, 1 in new slot), Size of downloads: 2 047 KiB

Would you like to merge these packages? [Yes/No]
```

----------

## pti-rem

 *Quote:*   

> J'essaie une façon :
> 
> J'ai placé */*::g20 dans /etc/portage/package.accept_keywords - à la suite de ma liste ordinaire.

 

Après coup, j'ai l'impression que c'est une bêtise ; je suis revenu dessus.

Merci pour vos avis.

----------

## YetiBarBar

glibc-2.30-r8  est stabilisé!

----------

## pti-rem

Oui, j'ai vu aussi ; ça tombe bien ; enfin plutôt rapidement je veux dire  :Smile: 

J'ai aussi une affaire en cours avec la news « Python 3.7 to become the default target » ; c'est un peu hors-sujet.

```
n73sm ~ # emerge --version

Portage 2.3.99 (python 3.7.7-final-0, default/linux/amd64/17.1/desktop, gcc-9.2.0, glibc-2.30-r8, 4.19.97-gentoo x86_64)

n73sm ~ #
```

 *eix --installed-unstable wrote:*   

> Found 389 matches

 

----------

## pti-rem

Bonjour,

Le remplacement des versions unstable / testing des paquets continue progressivement.

```
n73sm ~ # equery has repository g20

 * Searching for repository g20 ... 

n73sm ~ #

n73sm ~ # emerge --version

Portage 2.3.103 (python 3.7.8-final-0, default/linux/amd64/17.1/desktop, gcc-9.2.0, glibc-2.30-r8, 4.19.97-gentoo x86_64)

n73sm ~ #
```

 *eix --installed-unstable wrote:*   

> Found 174 matches

 

J'avais tout un tas de paquets installés en kde-*/*::g20 et j'ai eu un gros blocage relatif en partie à ces paquets lors d'une mise à jour (des versions différentes qui ne peuvent coexister)

Comme je ne suis en compagnie de KDE que pour kde-apps/k3b et kde-apps/kdenlive j'ai trouvé une solution radicale pour l'effectuer :

```
# emerge -av --depclean kde-*/* # (qui n'a manifesté aucune opposition pour aucun paquet)

# synchronisation de l'arbre de Portage et des overlays

# emerge -avuDN @world

# emerge -av --depclean

# revdep-rebuild -- -av

# emerge -av kde-apps/k3b kde-apps/kdenlive # (qui a réinstallé les bonnes versions stables des dépendances du dépôt principal gentoo)
```

J'ai un gros boulot de nettoyage des obsolescences repérées avec eix-test-obsolete ; un outil que je connais à peine :

```
n73sm ~ # eix-test-obsolete > obsolete-eix-`date -I`.txt

n73sm ~ # ls -lh obsolete-eix-`date -I`.txt

-rw-r--r-- 1 root root 144K  5 août  02:40 obsolete-eix-2020-08-05.txt

n73sm ~ #
```

Mais bon, les obsolescences ne m'affolent pas  :Wink:  C'est pas ça qui va faire planter le système.

Aussi, il faudrait peut-être que je mette à jour mon noyau sys-kernel/gentoo-sources en 4.19.120 ou 4.19.129 (stables) mais c'est toujours pareil,

quasi-impossible de trouver une version stable pérenne ; c'est agaçant pour tout dire.

Je ne sais pas trouver le statut de mon noyau actuel 4.19.97Last edited by pti-rem on Tue Apr 26, 2022 8:15 am; edited 1 time in total

----------

## pti-rem

Bonjour,

net-firewall/iptables et sys-apps/iproute2 deviennent stables depuis le repo gentoo.

=media-video/mkvtoolnix-48.0.0 également.

```
[*U]  == net-firewall/iptables (1.8.4-r1(0/1.8.3)@23/03/2020; ~1.8.5(0/1.8.3) -> 1.8.5(0/1.8.3)): Linux kernel (2.4+) firewall, NAT and packet mangling tools

[*U]  == sys-apps/iproute2 (5.5.0@23/03/2020; ~5.8.0 -> 5.7.0): kernel routing and traffic control utilities
```

```
>>> Failed to emerge dev-libs/zziplib-0.13.71, Log file:

>>>  '/var/tmp/portage/dev-libs/zziplib-0.13.71/temp/build.log'
```

J'ai les USE="doc sdl static-libs -test" pour dev-libs/zziplib

J'ai essayé # USE="-static-libs" emerge -avUD =dev-libs/zziplib-0.13.71::gentoo

qui m'a réinstallé plusieurs paquets sans le drapeau static-libs mais la compilation de =dev-libs/zziplib-0.13.71::gentoo échoue encore.

Pareil avec le drapeau sdl

Machine arrière avec # emerge -avUD =dev-libs/zziplib-0.13.69-r1::gentoo

pour laisser ou réinstaller la version stable =dev-libs/zziplib-0.13.69-r1::gentoo

puis la fixer avec un masquage des versions supérieures.

```
n73sm ~ # cat /etc/portage/package.mask/zziplib

>dev-libs/zziplib-0.13.69-r1::gentoo

dev-libs/zziplib::g20

n73sm ~ #
```

Je verrai ce problème de compilation plus tard si il perdure.

édition : en fait, je ne vais masquer que la version qui cloche (=dev-libs/zziplib-0.13.71::gentoo)

https://packages.gentoo.org/packages/dev-libs/zziplib/bugs

édition : dev-libs/zziplib-0.13.71-r1 vient résoudre le problème.

« Your system is consistent »

```
n73sm ~ # emerge --version

Portage 2.3.103 (python 3.7.8-final-0, default/linux/amd64/17.1/desktop, gcc-9.2.0, glibc-2.31-r6, 4.19.97-gentoo x86_64)

n73sm ~ #
```

« Found 152 matches » unstables

----------

## pti-rem

Bonjour,

Il m'est arrivé d'accepter quelques régressions en stable (downgrades) en faisant attention aux fonctions des paquets.

J'en ai pas pris note. Il s'agissait principalement de paquets de haut niveau d'après ce que j'ai pu comprendre.

Aujourd'hui

```
[*U]  == dev-libs/glib (2.64.1(2)@25/03/2020; ~2.64.5(2)^t -> 2.64.4(2)^t): The GLib library of C routines

[*U]  == dev-libs/gobject-introspection (1.64.0@24/04/2020; ~1.64.1-r1^t -> 1.64.1-r1^t): Introspection system for GObject-based libraries

[*U]  == dev-libs/gobject-introspection-common (1.64.0@25/03/2020; ~1.64.1 -> 1.64.1): Build infrastructure for GObject Introspection

[*U]  == dev-util/gdbus-codegen (2.64.1@24/04/2020; ~2.64.5 -> 2.64.4): GDBus code and documentation generator

[*U]  == dev-util/glib-utils (2.64.1@24/04/2020; ~2.64.5 -> 2.64.4): Build utilities for GLib using projects

[*U]  == net-libs/glib-networking (2.64.0@25/03/2020; ~2.64.3^t -> 2.64.3^t): Network-related giomodules for glib

[*U]  == dev-libs/atk (2.35.1@25/03/2020; ~2.36.0 -> 2.36.0): GTK+ & GNOME Accessibility Toolkit [ le 31 août à 15:05 heure française ]

[*U]  == sys-devel/bison (3.5.4@09/05/2020; ~3.7.1^t -> 3.7.1^t): A general-purpose (yacc-compatible) parser generator [ le 1er septembre à 17:00 heure française ]
```

[*U] indique des versions non stables qui deviennent stables (reprenez-moi si je me trompe)

Je n'ai pas mentionné jusqu'à présent de [U] où la version non stable est remplacée par une version stable supérieure.

« Found 140 matches » unstables

```
n73sm ~ # emerge --version

Portage 3.0.4 (python 3.7.8-final-0, default/linux/amd64/17.1/desktop, gcc-9.2.0, glibc-2.31-r6, 4.19.97-gentoo x86_64)

n73sm ~ #
```

----------

## pti-rem

Bonjour,

Je suis un peu coincé sur ce coup là, avec quelques downgrades :

```
n73sm ~ # emerge -avuDN @world

These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild  r  UD ] dev-haskell/stm-2.4.2:0/2.4.2::g20 [2.4.4.1:0/2.4.4.1::gentoo] USE="-doc -hscolour -profile" 0 KiB

[ebuild  rR    ] dev-haskell/transformers-base-0.4.4:0/0.4.4::g20 [0.4.4:0/0.4.4::gentoo] USE="orphaninstances -doc -hscolour -profile" 0 KiB

[ebuild  rR    ] dev-haskell/exceptions-0.8.3:0/0.8.3::g20 [0.8.3:0/0.8.3::gentoo] USE="-doc -hscolour -profile -test" 0 KiB

[ebuild     UD ] dev-haskell/mmorph-1.0.6:0/1.0.6::g20 [1.0.9:0/1.0.9::gentoo] USE="-doc -hscolour -profile" 0 KiB

[ebuild  rR   ~] dev-haskell/monad-control-1.0.2.3:0/1.0.2.3::gentoo  USE="-doc -hscolour -profile" 0 KiB

[ebuild     UD ] dev-haskell/resourcet-1.1.7.4:0/1.1.7.4::g20 [1.1.9:0/1.1.9::gentoo] USE="-doc -hscolour -profile -test" 0 KiB

[ebuild     U  ] dev-libs/check-0.15.2::gentoo [0.15.0::gentoo] USE="-doc -subunit -test" ABI_X86="(64) -32 (-x32)" 299 KiB

[ebuild   R    ] dev-python/zipp-3.1.0::gentoo  USE="-doc -test" PYTHON_TARGETS="python3_7 -pypy3 -python3_6 -python3_8 -python3_9%" 0 KiB

[ebuild     U  ] app-text/texlive-core-2020-r12::gentoo [2020-r10::gentoo] USE="X luajittex xetex -cjk -doc -source -tk -xindy" 0 KiB

[ebuild   R    ] sys-apps/portage-3.0.4-r1::gentoo  USE="(ipc) native-extensions rsync-verify xattr -apidoc -build -doc -gentoo-dev (-selinux) -test%" PYTHON_TARGETS="python3_6 python3_7 -pypy3 -python3_8 -python3_9" 0 KiB

Total: 10 packages (2 upgrades, 3 downgrades, 5 reinstalls), Size of downloads: 299 KiB

The following packages are causing rebuilds:

  (dev-haskell/stm-2.4.2:0/2.4.2::g20, ebuild scheduled for merge) causes rebuilds for:

    (dev-haskell/transformers-base-0.4.4:0/0.4.4::g20, ebuild scheduled for merge)

    (dev-haskell/exceptions-0.8.3:0/0.8.3::g20, ebuild scheduled for merge)

    (dev-haskell/monad-control-1.0.2.3:0/1.0.2.3::gentoo, ebuild scheduled for merge)

Would you like to merge these packages? [Yes/No] y
```

```
!!! existing preserved libs:

>>> package: dev-haskell/exceptions-0.8.3

 *  - /usr/lib64/x86_64-linux-ghc-8.0.2/libHSexceptions-0.8.3-A2rXmtjtrRE7lIRuPnxwzq-ghc8.0.2.so

 *      used by /usr/lib64/x86_64-linux-ghc-8.0.2/libHSresourcet-1.1.9-6uo5HVR4PWQBr2fHU8bbqk-ghc8.0.2.so (dev-haskell/resourcet-1.1.9)

 *      used by /usr/lib64/x86_64-linux-ghc-8.0.2/libHStemporary-1.2.0.4-3xwHfFmjIB4EP0EeDpUXS9-ghc8.0.2.so (dev-haskell/temporary-1.2.0.4)

>>> package: dev-haskell/mmorph-1.0.6

 *  - /usr/lib64/x86_64-linux-ghc-8.0.2/libHSmmorph-1.0.9-4JK5hHJtTLl6nbs7cO7K3C-ghc8.0.2.so

 *      used by /usr/lib64/x86_64-linux-ghc-8.0.2/libHSresourcet-1.1.9-6uo5HVR4PWQBr2fHU8bbqk-ghc8.0.2.so (dev-haskell/resourcet-1.1.9)

>>> package: dev-haskell/monad-control-1.0.2.3

 *  - /usr/lib64/x86_64-linux-ghc-8.0.2/libHSmonad-control-1.0.2.3-KRFDvwPWg3aD0qrjplG1s9-ghc8.0.2.so

 *      used by /usr/lib64/x86_64-linux-ghc-8.0.2/libHSlifted-base-0.2.3.12-37p34nmuYJDDyl92OY785B-ghc8.0.2.so (dev-haskell/lifted-base-0.2.3.12)

 *      used by /usr/lib64/x86_64-linux-ghc-8.0.2/libHSresourcet-1.1.9-6uo5HVR4PWQBr2fHU8bbqk-ghc8.0.2.so (dev-haskell/resourcet-1.1.9)

>>> package: dev-haskell/transformers-base-0.4.4

 *  - /usr/lib64/x86_64-linux-ghc-8.0.2/libHStransformers-base-0.4.4-4TDmCsR520d8z8kPwbm8YT-ghc8.0.2.so

 *      used by /usr/lib64/x86_64-linux-ghc-8.0.2/libHSlifted-base-0.2.3.12-37p34nmuYJDDyl92OY785B-ghc8.0.2.so (dev-haskell/lifted-base-0.2.3.12)

 *      used by /usr/lib64/x86_64-linux-ghc-8.0.2/libHSresourcet-1.1.9-6uo5HVR4PWQBr2fHU8bbqk-ghc8.0.2.so (dev-haskell/resourcet-1.1.9)

Use emerge @preserved-rebuild to rebuild packages using these libraries

 * After world updates, it is important to remove obsolete packages with

 * emerge --depclean. Refer to `man emerge` for more information.

n73sm ~ # emerge @preserved-rebuild -av

These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild   R   ~] dev-haskell/temporary-1.2.0.4:0/1.2.0.4::gentoo  USE="-doc -hscolour -profile" 0 KiB

[ebuild   R   ~] dev-haskell/lifted-base-0.2.3.12:0/0.2.3.12::gentoo  USE="-doc -hscolour -profile -test" 0 KiB

[ebuild     UD ] dev-haskell/resourcet-1.1.7.4:0/1.1.7.4::g20 [1.1.9:0/1.1.9::gentoo] USE="-doc -hscolour -profile -test" 0 KiB

Total: 3 packages (1 downgrade, 2 reinstalls), Size of downloads: 0 KiB

Would you like to merge these packages? [Yes/No] y
```

```
n73sm ~ # equery has repository g20

 * Searching for repository g20 ... 

[I-O] [  ] dev-haskell/exceptions-0.8.3:0/0.8.3

[I-O] [  ] dev-haskell/mmorph-1.0.6:0/1.0.6

[I-O] [  ] dev-haskell/resourcet-1.1.7.4:0/1.1.7.4

[I-O] [  ] dev-haskell/stm-2.4.2:0/2.4.2

[I-O] [  ] dev-haskell/transformers-base-0.4.4:0/0.4.4

n73sm ~ #
```

« Your system is consistent »

« Found 130 matches » unstables

Plan B, je peux aussi enlever ces paquets de mon système :

Je ne sais pas à quoi ils servent.

```
n73sm ~ # emerge -av --depclean dev-haskell/exceptions::g20 dev-haskell/mmorph::g20 dev-haskell/resourcet::g20 dev-haskell/stm::g20 dev-haskell/transformers-base::g20 dev-haskell/temporary dev-haskell/monad-control dev-haskell/lifted-base

Calculating dependencies... done!

>>> Calculating removal order...

>>> These are the packages that would be unmerged:

 dev-haskell/temporary

    selected: 1.2.0.4 

   protected: none 

     omitted: none 

 dev-haskell/resourcet

    selected: 1.1.7.4 

   protected: none 

     omitted: none 

 dev-haskell/mmorph

    selected: 1.0.6 

   protected: none 

     omitted: none 

 dev-haskell/lifted-base

    selected: 0.2.3.12 

   protected: none 

     omitted: none 

 dev-haskell/exceptions

    selected: 0.8.3 

   protected: none 

     omitted: none 

 dev-haskell/monad-control

    selected: 1.0.2.3 

   protected: none 

     omitted: none 

 dev-haskell/transformers-base

    selected: 0.4.4 

   protected: none 

     omitted: none 

 dev-haskell/stm

    selected: 2.4.2 

   protected: none 

     omitted: none 

All selected packages: =dev-haskell/monad-control-1.0.2.3 =dev-haskell/mmorph-1.0.6 =dev-haskell/stm-2.4.2 =dev-haskell/temporary-1.2.0.4 =dev-haskell/exceptions-0.8.3 =dev-haskell/resourcet-1.1.7.4 =dev-haskell/lifted-base-0.2.3.12 =dev-haskell/transformers-base-0.4.4

>>> 'Selected' packages are slated for removal.

>>> 'Protected' and 'omitted' packages will not be removed.

Would you like to unmerge these packages? [Yes/No] n

Quitting.

Packages installed:   1707

Packages in world:    366

Packages in system:   43

Required packages:    1699

Number to remove:     8

n73sm ~ #
```

J'aime bien aussi élaguer mon système.

J'adopte le plan B.

----------

## pti-rem

Bonjour,

```
[*U]  == net-fs/samba (4.12.1@20/05/2020; ~4.13.1^t -> 4.12.9^t): Samba Suite Version 4
```

```
Portage 3.0.8 (python 3.7.9-final-0, default/linux/amd64/17.1/desktop, gcc-9.2.0, glibc-2.32-r2, 4.19.97-gentoo x86_64)
```

« Your system is consistent »

« Found 110 matches » unstables

Puis, en 2020.12.03 @ 16:20 heure de Paris

```
[*U]  == media-tv/plex-media-server (1.20.5-r2[3]@20/11/2020; ~1.21.0-r1^msd[3] -> 1.21.0.3711^msd[3]): A free media library that is intended for use with a plex client
```

Il y a aussi :

```
[U]   == sys-process/audit (2.8.5@11/09/2020; (~)2.8.5^t -> 2.8.5-r2^t): Userspace utilities for storing and processing auditing records
```

Je ne comprends pas bien la différence entre [*U] et [U] montrée par eix-diff pour deux paquets unstable qui deviennent stables.

Pour finir, le PYTHON_TARGETS="python3_8*" fait son apparition lors de la mise à jour. Et pour de nombreux paquets.

```
Portage 3.0.9 (python 3.7.9-final-0, default/linux/amd64/17.1/desktop, gcc-9.2.0, glibc-2.32-r2, 4.19.97-gentoo x86_64)
```

« Your system is consistent »

« Found 88 matches » unstables

----------

## pti-rem

Bonjour,

Je commence la mise à jour quotidienne et je rencontre un questionnement.

```
[?]   == dev-python/zstandard (0.15.1@07/03/2021; (~)0.15.1^t -> 0.14.1^t): Zstandard Bindings for Python
```

```
n73sm ~ # emerge -pvuDN dev-python/zstandard

These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild     U  ] x11-libs/libXt-1.2.1::gentoo [1.2.0::gentoo] USE="-doc -test" ABI_X86="32 (64) (-x32)" 767 KiB

[ebuild     U  ] x11-libs/libdrm-2.4.104::gentoo [2.4.103::gentoo] USE="-libkms -valgrind" ABI_X86="32 (64) (-x32)" VIDEO_CARDS="intel nouveau -amdgpu (-exynos) (-freedreno) (-omap) -radeon (-tegra) (-vc4) (-vivante) -vmware" 410 KiB

[ebuild     U  ] dev-libs/libevdev-1.11.0::gentoo [1.10.0::gentoo] USE="-doc -test" ABI_X86="(64) -32 (-x32)" 435 KiB

[ebuild     UD ] dev-python/zstandard-0.14.1::gentoo [0.15.1::gentoo] USE="-test" PYTHON_TARGETS="python3_7 python3_8 -python3_9 (-pypy3%)" 0 KiB

[ebuild     U  ] media-libs/mesa-20.3.4::gentoo [20.2.6::gentoo] USE="X classic dri3 egl gallium gbm gles2 llvm zstd -d3d9 -debug -gles1 -lm-sensors -opencl -osmesa (-selinux) -test -unwind -vaapi -valgrind -vdpau -vulkan -vulkan-overlay -wayland -xa -xvmc -zink" ABI_X86="32 (64) (-x32)" VIDEO_CARDS="i915 i965 intel (-freedreno) -iris (-lima) -nouveau (-panfrost) -r100 -r200 -r300 -r600 -radeon -radeonsi (-v3d) (-vc4) -virgl (-vivante) -vmware" 13 920 KiB

[ebuild     U  ] media-libs/libepoxy-1.5.5::gentoo [1.5.4::gentoo] USE="X egl -test" ABI_X86="32 (64) (-x32)" 325 KiB

Total: 6 packages (5 upgrades, 1 downgrade), Size of downloads: 15 855 KiB

n73sm ~ #
```

Je ne sais pas si je dois accepter sans crainte le downgrade de dev-python/zstandard

J'ai bien envie de le faire comme j'ai pu le faire plusieurs fois auparavant pour d'autres paquets plus "évidents"

Mais ce paquet dev-python/zstandard est quand même un peu particulier, non ?

Qu'en pensez-vous ?

Bon... Vu que la version (~)0.15.1^t a été installée récemment, le 07/03/2021 dernier, je vais faire selon ce que me préconise Portage.

« Your system is consistent »

« Found 56 matches » installed-unstableLast edited by pti-rem on Thu Mar 11, 2021 11:05 am; edited 1 time in total

----------

## YetiBarBar

Bonjour,

Que lui trouves-tu de particulier? Qui en dépend?

```
equery depends dev-python/zstandard
```

(Ce paquet n'est pas installé sur ma machine)

----------

## pti-rem

Bonjour YetiBarBar,

Rien que le nom "zstandard" de Python.

```
n73sm ~ # equery depends dev-python/zstandard

 * These packages depend on dev-python/zstandard:

dev-vcs/mercurial-5.6.1-r1 (dev-python/zstandard[python_targets_python3_7(-)?,python_targets_python3_8(-)?,-python_single_target_python3_7(-),-python_single_target_python3_8(-)])

n73sm ~ #
```

Encore une commande que je ne connaissais pas, merci.

Je ne sais plus trop pourquoi - comment j'ai dev-vcs/mercurial dans mon système ni à quoi il sert.

J'ai dû mettre un USE il y a longtemps. Faut croire que je voulais expérimenter...

```
n73sm ~ # grep -R mercurial /etc/portage/package.use/ | grep -v "#"

/etc/portage/package.use/petit-paquet:>=app-portage/layman-2.4.3::gentoo git cvs mercurial subversion

/etc/portage/package.use/python-upgrades:dev-vcs/mercurial PYTHON_TARGETS: python2_7 python3_6

n73sm ~ #
```

Tel que je vois la chose là, le USE mercurial pour >=app-portage/layman-2.4.3::gentoo est à enlever maintenant.Last edited by pti-rem on Fri Mar 12, 2021 6:09 am; edited 1 time in total

----------

## YetiBarBar

Du coup, on vait faire un mode récursif^^!

```
equery d mercurial
```

A mon avis, soit c'est juste un USE flag "mercurial" qui traine quelquepart dans ta conf. (soit make.conf, soit dans le profil, soit au niveau des package.use)

En tout cas, sauf si tu as un besoin primordial d'accéder à mercurial ou que tu utilises un overlay basé sur mercurial, tu ne risques rien!

Que dis la commande:

```
layman -l
```

----------

## pti-rem

```
n73sm ~ # equery d mercurial

 * These packages depend on mercurial:

app-portage/layman-2.4.3 (mercurial ? dev-vcs/mercurial)

dev-python/setuptools_scm-5.0.1 (!sparc ? dev-vcs/mercurial)

n73sm ~ #
```

```
n73sm ~ # layman -l

 * plex-overlay              [Git       ] (https://github.com/comio/plex-overlay.git                                                                                                    )

n73sm ~ #
```

 *YetiBarBar wrote:*   

> En tout cas, sauf si tu as un besoin primordial d'accéder à mercurial ou que tu utilises un overlay basé sur mercurial, tu ne risques rien!
> 
> 

 

J'ai un lointain souvenir qui me rappelle « on sait jamais, ça pourrait servir... »

J'en ai pas l'utilité.

Par contre, je sais pas ce que ce dev-python/setuptools_scm-5.0.1 fait là...

```
n73sm ~ # equery d dev-python/setuptools_scm

 * These packages depend on dev-python/setuptools_scm:

dev-python/importlib_metadata-3.4.0 (dev-python/setuptools_scm[python_targets_pypy3(-)?,python_targets_python3_7(-)?,python_targets_python3_8(-)?,-python_single_target_pypy3(-),-python_single_target_python3_7(-),-python_single_target_python3_8(-)])

dev-python/py-1.10.0 (dev-python/setuptools_scm[python_targets_pypy3(-)?,python_targets_python3_7(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,-python_single_target_pypy3(-),-python_single_target_python3_7(-),-python_single_target_python3_8(-),-python_single_target_python3_9(-)])

dev-python/pylast-4.1.0 (dev-python/setuptools_scm[python_targets_pypy3(-)?,python_targets_python3_7(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,-python_single_target_pypy3(-),-python_single_target_python3_7(-),-python_single_target_python3_8(-),-python_single_target_python3_9(-)])

dev-python/setuptools-53.0.0 (dev-python/setuptools_scm[python_targets_pypy3(-)?,python_targets_python3_7(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,-python_single_target_pypy3(-),-python_single_target_python3_7(-),-python_single_target_python3_8(-),-python_single_target_python3_9(-)])

dev-python/tox-3.21.4 (dev-python/setuptools_scm[python_targets_pypy3(-)?,python_targets_python3_7(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,-python_single_target_pypy3(-),-python_single_target_python3_7(-),-python_single_target_python3_8(-),-python_single_target_python3_9(-)])

dev-python/virtualenv-20.4.0 (dev-python/setuptools_scm[python_targets_pypy3(-)?,python_targets_python3_7(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,-python_single_target_pypy3(-),-python_single_target_python3_7(-),-python_single_target_python3_8(-),-python_single_target_python3_9(-)])

dev-python/zipp-3.4.0 (>=dev-python/setuptools_scm-3.4.2[python_targets_pypy3(-)?,python_targets_python3_7(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,-python_single_target_pypy3(-),-python_single_target_python3_7(-),-python_single_target_python3_8(-),-python_single_target_python3_9(-)])

n73sm ~ #
```

C'est un gros bazar ?

Je laisse, c'est pas grave.

----------

## YetiBarBar

Tu n'utilises pas d'overlay sous Mercurial, donc tu peux des USE de layman.

Pour setuptools_scm, c'est une dépendance requise si tu utilises le USE test. equery donne un faux positif.

En enlevant le USE="mercurial" et en laissant:

```
emerge -DuavN --keep-going=y --with-bdeps=y @world
```

 puis 

```
emerge -av --depclean
```

, tu devrait avoir un paquet de moins en unstable!

----------

## pti-rem

Bonjour,

J'ai recompilé layman sans mercurial mais j'avoue que je n'ai pas très bien compris ton message YetiBarBar.

Que equery donne un faux positif, d'accord. Je ne sais pas pourquoi mais d'accord.

Je n'utilise pas le USE test pour setuptools_scm

```
rem@n73sm ~ $ sudo emerge -pv setuptools_scm

These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild   R    ] dev-python/setuptools_scm-5.0.1::gentoo  USE="-test" PYTHON_TARGETS="python3_7 python3_8 -pypy3 -python3_9" 0 KiB

Total: 1 package (1 reinstall), Size of downloads: 0 KiB

rem@n73sm ~ $
```

dev-vcs/mercurial-5.6.1-r1::gentoo n'est pas instable pour amd64 mais « The following features are restricted: [test] »

https://packages.gentoo.org/packages/dev-vcs/mercurial

Si il y a un objectif, c'est d'enlever dev-vcs/mercurial de mon système.

```
rem@n73sm ~ $ sudo emerge -av --depclean =dev-vcs/mercurial-5.6.1-r1::gentoo

Calculating dependencies... done!

>>> Calculating removal order...

>>> These are the packages that would be unmerged:

 dev-vcs/mercurial

    selected: 5.6.1-r1 

   protected: none 

     omitted: none 

All selected packages: =dev-vcs/mercurial-5.6.1-r1

>>> 'Selected' packages are slated for removal.

>>> 'Protected' and 'omitted' packages will not be removed.

Would you like to unmerge these packages? [Yes/No] y

>>> Waiting 5 seconds before starting...

>>> (Control-C to abort)...

>>> Unmerging in: 5 4 3 2 1

>>> Unmerging (1 of 1) dev-vcs/mercurial-5.6.1-r1...

Packages installed:   1744

Packages in world:    372

Packages in system:   43

Required packages:    1744

Number removed:       1

 * GNU info directory index is up-to-date.

rem@n73sm ~ $
```

Voilà ! Ça a marché...

Ça revient presque au même que ce que tu voulais me dire, mais hier, ça voulait pas.

```
rem@n73sm ~ $ sudo equery depends dev-python/zstandard

 * These packages depend on dev-python/zstandard:

rem@n73sm ~ $
```

----------

## YetiBarBar

Bonjour,

Pour le faux positif, "equery depends" a un bug avec les conditions imbriquées: https://bugs.gentoo.org/show_bug.cgi?id=485306

```
cat /usr/portage/dev-python/setuptools_scm/setuptools_scm-5.0.2.ebuild
```

 permet de voir (si tu arrives à t'y retrouver dans la syntaxe des ebuilds   :Confused:  ) que setuptools_scm dépend de mercurial si le flag test et que tu n'es pas sur sparc (ce qui n'est ni ton cas, ni le mien!).

Quitte à me répéter, après chaque mise à jour de world avec le flag --newuse, pense à lancer un 

```
emerge -av --depclean
```

 sans spécifier de paquets à nettoyer pour dégager tout ce qui est devenu obsolète (il faut quand même vérifier avant).

----------

## pti-rem

Bonjour,

 *YetiBarBar wrote:*   

> Pour le faux positif, "equery depends" a un bug avec les conditions imbriquées: https://bugs.gentoo.org/show_bug.cgi?id=485306

 

Je ne me suis pas intéressé au bug ; Il me fait penser à celui du USE doc global pour les références circulaires.

 *YetiBarBar wrote:*   

> si tu arrives à t'y retrouver dans la syntaxe des ebuilds

 

Non, je ne m'y intéresse pas.

 *YetiBarBar wrote:*   

> Quitte à me répéter

 

Tu as raison mais pas de souci pour moi à ce niveau là.

Je n'utilise pas l'option --verbose pour la commande --depclean ; juste --ask

Je peux l'utiliser pour un --depclean d'un paquet particulier.

 *YetiBarBar wrote:*   

> il faut quand même vérifier avant

 

Ça peut être évident comme quasiment impossible.

Généralement, je fais confiance.

Je vérifie un peu.

Pour en revenir à ce sujet, le retrait de ruby25 aura eu la peau de ma volonté de revenir en stable.

La compilation de dev-ruby/bundler-2.1.4 échouait sur un "rdoc not found"

Après, je me suis bien mélangé les pinceaux et j'ai perdu du temps.

J'en aurais certainement gagné en postant une demande d'aide.

Je n'ai pas envie de revenir en arrière même si c'est probablement possible.

Je n'ai toujours pas de mention ACCEPT_KEYWORDS dans mon make.conf

J'ai retiré mon dépôt local g20 qui à vrai dire n'a pas beaucoup servi.

J'ai retiré mon /etc/portage/package.accept_keywords/arch qui était généré avant chaque mise à jour par la commande :

```
equery list -F '=$cpv::$repo' '*' > /etc/portage/package.accept_keywords/arch
```

Je laisse désormais ce sujet à l'abandon. Je verrai bien comment se dérouleront les prochaines mises à jour.

J'en ai marre d'administrer et mon utilisation se réduit de beaucoup. La mise en veille fonctionne bien.

Bien à vous

```
n73sm ~ # emerge --info

Portage 3.0.20 (python 3.9.5-final-0, default/linux/amd64/17.1/desktop, gcc-10.3.0, glibc-2.33-r1, 4.19.97-gentoo x86_64)

=================================================================

System uname: Linux-4.19.97-gentoo-x86_64-Intel-R-_Core-TM-_i7-2670QM_CPU_@_2.20GHz-with-glibc2.33

KiB Mem:    12200416 total,   4068596 free

KiB Swap:   12582908 total,  12582908 free

Timestamp of repository gentoo: Fri, 09 Jul 2021 23:45:01 +0000

Head commit of repository gentoo: 9dbdc2ab3748b2823e26edd26efa13356ada5f91

sh bash 5.1_p8

ld GNU ld (Gentoo 2.35.2 p1) 2.35.2

app-shells/bash:          5.1_p8::gentoo

dev-java/java-config:     2.3.1::gentoo

dev-lang/perl:            5.32.1::gentoo

dev-lang/python:          2.7.18_p10::gentoo, 3.6.13_p5::gentoo, 3.7.10_p6::gentoo, 3.9.5_p2::gentoo

dev-lang/rust-bin:        1.52.1::gentoo

dev-util/cmake:           3.18.5::gentoo

dev-util/pkgconfig:       0.29.2::gentoo

sys-apps/baselayout:      2.7::gentoo

sys-apps/openrc:          0.42.1-r1::gentoo

sys-apps/sandbox:         2.24::gentoo

sys-devel/autoconf:       2.13-r1::gentoo, 2.69-r5::gentoo

sys-devel/automake:       1.13.4-r2::gentoo, 1.16.3-r1::gentoo

sys-devel/binutils:       2.35.2::gentoo

sys-devel/gcc:            8.3.0-r3::gentoo, 9.2.0-r2::gentoo, 9.3.0-r2::gentoo, 10.3.0::gentoo

sys-devel/gcc-config:     2.4::gentoo

sys-devel/libtool:        2.4.6-r6::gentoo

sys-devel/make:           4.3::gentoo

sys-kernel/linux-headers: 5.10::gentoo (virtual/os-headers)

sys-libs/glibc:           2.33-r1::gentoo

Repositories:

gentoo

    location: /usr/portage

    sync-type: rsync

    sync-uri: rsync://rsync.fr.gentoo.org/gentoo-portage

    priority: -1000

    sync-rsync-extra-opts: 

    sync-rsync-verify-metamanifest: yes

    sync-rsync-verify-jobs: 1

    sync-rsync-verify-max-age: 24

plex-overlay

    location: /var/lib/layman/plex-overlay

    masters: gentoo

    priority: 50

ACCEPT_KEYWORDS="amd64"

ACCEPT_LICENSE="@FREE"

CBUILD="x86_64-pc-linux-gnu"

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

CHOST="x86_64-pc-linux-gnu"

CONFIG_PROTECT="/etc /usr/share/config /usr/share/gnupg/qualified.txt"

CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c"

CXXFLAGS="-march=corei7-avx -O2 -pipe"

DISTDIR="/usr/portage/distfiles"

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

ENV_UNSET="CARGO_HOME DBUS_SESSION_BUS_ADDRESS DISPLAY GOBIN GOPATH PERL5LIB PERL5OPT PERLPREFIX PERL_CORE PERL_MB_OPT PERL_MM_OPT XAUTHORITY XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR"

FCFLAGS="-O2 -pipe"

FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles ipc-sandbox merge-sync multilib-strict network-sandbox news parallel-fetch pid-sandbox preserve-libs protect-owned qa-unresolved-soname-deps sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr"

FFLAGS="-O2 -pipe"

GENTOO_MIRRORS="http://mirrors.linuxant.fr/distfiles.gentoo.org/ http://gentoo.modulix.net/gentoo/ http://gentoo.mirrors.ovh.net/gentoo-distfiles/ ftp://gentoo.mirrors.ovh.net/gentoo-distfiles/"

LANG="fr_FR.utf8"

LDFLAGS="-Wl,-O1 -Wl,--as-needed"

LINGUAS="fr-FR fr en-US en en-GB"

MAKEOPTS="-j3 -l6"

PKGDIR="/usr/portage/packages"

PORTAGE_CONFIGROOT="/"

PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git"

PORTAGE_TMPDIR="/var/tmp"

USE="X a52 aac acl acpi aes alsa amd64 avx bluetooth branding bzip2 cairo cdda cdr cli crypt cups dbus dri dts dvd dvdr elogind emboss encode examples exif fdk flac fortran gdbm gif gpm gtk gui handbook iconv icu jpeg lcms libglvnd libnotify libtirpc mad mmx mmxext mng mp3 mp4 mpeg multilib ncurses networkmanager nls nptl ogg opengl openmp pam pango pcre pdf png policykit ppds pulseaudio qt5 readline sdl seccomp spell split-usr sse sse2 sse4_1 sse4_2 ssl ssse3 startup-notification svg tcpd tiff tools truetype udev udisks unicode upower usb utils vorbis wxwidgets x264 x265 xattr xcb xml xv xvid zlib" ABI_X86="64" ADA_TARGET="gnat_2018" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="karbon sheets words" CAMERAS="ptp2 ax203" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="aes avx mmx mmxext popcnt sse sse2 sse3 sse4_1 sse4_2 ssse3" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock greis isync itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="evdev synaptics" KERNEL="linux" L10N="fr-FR fr en-US en en-GB" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LUA_SINGLE_TARGET="lua5-1" LUA_TARGETS="lua5-1" NGINX_MODULES_HTTP="dav auth_pam fancyindex addition geoip fastcgi uwsgi gzip rewrite autoindex charset proxy" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php7-3 php7-4" POSTGRES_TARGETS="postgres10 postgres11" PYTHON_SINGLE_TARGET="python3_7" PYTHON_TARGETS="python3_9 python3_7" RUBY_TARGETS="ruby26" SANE_BACKENDS="genesys hp hp3500 hp3900 hp4200 hp5400 hp5590 snapscan hpsj5s canon canon630u canon_dr" USERLAND="GNU" VIDEO_CARDS="i965 i915 intel nvidia" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq proto steal rawnat logmark ipmark dhcpmac delude chaos account"

Unset:  CC, CPPFLAGS, CTARGET, CXX, INSTALL_MASK, LC_ALL, PORTAGE_BINHOST, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, RUSTFLAGS

n73sm ~ # 
```

Last edited by pti-rem on Mon Jul 12, 2021 8:09 am; edited 1 time in total

----------

## pti-rem

 *pti-rem wrote:*   

> Je n'ai pas envie de revenir en arrière même si c'est probablement possible.

 

Je n'ai pas pu m'en empêcher vu le petit correctif à appliquer à dev-ruby/bundler-2.1.4 pour achever son installation. (USE="-doc")

Je travaille mieux la nuit et après avoir dormi. Les journées sont souvent remplies de certitudes.

J'ai retiré de /etc/portage/package.accept_keywords/ ce que j'y avais mis pour la mise à jour en unstable de paquets concernant ruby ; l'essentiel de cette mise à jour.

Le nettoyage des USEs va attendre un petit peu.

Du coup, j'ai un petit paquet de downgrades :

```
n73sm ~ # emerge -avuDN @world

These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild     UD ] virtual/rubygems-15::gentoo [16::gentoo] RUBY_TARGETS="ruby26 (-ruby25) (-ruby27%*) (-ruby30%*)" 0 KiB

[ebuild     UD ] dev-ruby/rake-12.3.3::gentoo [13.0.4::gentoo] USE="-doc -test" RUBY_TARGETS="ruby26 (-ruby25) (-ruby27%*) (-ruby30%*)" 0 KiB

[ebuild     UD ] dev-ruby/power_assert-1.1.5::gentoo [2.0.0::gentoo] USE="-doc -test" RUBY_TARGETS="ruby26 (-ruby25) (-ruby27*) (-ruby30%*)" 0 KiB

[ebuild   R    ] virtual/ruby-ssl-11::gentoo  RUBY_TARGETS="ruby26 (-ruby25) (-ruby27*) (-ruby30*)" 0 KiB

[ebuild     UD ] dev-ruby/did_you_mean-1.3.1:2.6::gentoo [1.5.0:2.6::gentoo] USE="-test" RUBY_TARGETS="ruby26 (-ruby25) (-ruby27%*) (-ruby30%*)" 0 KiB

[ebuild     UD ] dev-ruby/minitest-5.11.3:5::gentoo [5.14.4:5::gentoo] USE="-doc -test" RUBY_TARGETS="ruby26 (-ruby25) (-ruby27%*) (-ruby30%*)" 0 KiB

[ebuild   R    ] dev-ruby/net-telnet-0.2.0:1::gentoo  USE="-doc -test" RUBY_TARGETS="ruby26 (-ruby25) (-ruby27*)" 0 KiB

[ebuild     UD ] dev-ruby/xmlrpc-0.3.0::gentoo [0.3.2::gentoo] USE="-doc -test" RUBY_TARGETS="ruby26 (-ruby25) (-ruby27*) (-ruby30%)" 0 KiB

[ebuild   R    ] dev-ruby/kpeg-1.1.0-r1:1::gentoo  USE="-doc -test" RUBY_TARGETS="ruby26 (-ruby25) (-ruby27*) (-ruby30*)" 0 KiB

[ebuild     UD ] dev-ruby/test-unit-3.3.3:2::gentoo [3.4.4:2::gentoo] USE="-doc -test" RUBY_TARGETS="ruby26 (-ruby25) (-ruby27%*) (-ruby30%*)" 0 KiB

[ebuild     UD ] dev-ruby/json-2.3.0:2::gentoo [2.5.1-r1:2::gentoo] USE="-doc -test" RUBY_TARGETS="ruby26 (-ruby25) (-ruby27*) (-ruby30%*)" 0 KiB

[ebuild     UD ] dev-ruby/racc-1.4.14::gentoo [1.5.2-r1::gentoo] USE="-doc -test" RUBY_TARGETS="ruby26 (-ruby25) (-ruby27%*) (-ruby30%*)" 0 KiB

[ebuild     UD ] dev-ruby/rubygems-3.0.9::gentoo [3.2.14::gentoo] USE="-server -test" RUBY_TARGETS="ruby26 (-ruby25) (-ruby27%*) (-ruby30%*)" 0 KiB

[ebuild     UD ] dev-ruby/rdoc-6.1.2::gentoo [6.3.2::gentoo] USE="-doc -test" RUBY_TARGETS="ruby26 (-ruby25) (-ruby27%*) (-ruby30%*)" 0 KiB

[ebuild     UD ] dev-ruby/bundler-2.1.4:2::gentoo [2.2.21:2::gentoo] USE="doc -test" RUBY_TARGETS="ruby26 (-ruby25) (-ruby27*) (-ruby30%*)" 0 KiB

Total: 15 packages (12 downgrades, 3 reinstalls), Size of downloads: 0 KiB

Would you like to merge these packages? [Yes/No] n

Quitting.

n73sm ~ # echo "=dev-ruby/bundler-2.1.4:2::gentoo -doc" >> /etc/portage/package.use/bundler

n73sm ~ # eselect ruby list

Available Ruby profiles:

  [1]   ruby26 (with Rubygems)

  [2]   ruby27 (with Rubygems) *

  [3]   ruby30 (with Rubygems)

n73sm ~ # eselect ruby set 1

Successfully switched to profile:

  ruby26

n73sm ~ #
```

Cette mise à jour s'effectue sans problème. « Found 19 matches » unstable.

Je préfèrerai me passer de ce /etc/portage/package.accept_keywords/arch que je générais.

À vrai dire, je n'ai pas encore bien compris réellement son fonctionnement et son utilité.

édition après une nouvelle mise à jour : il semble bien que cela fonctionne bien sans maintenant ; c'était peut-être utile au début ?

 *pti-rem wrote:*   

> Je laisse désormais ce sujet à l'abandon

 

Je lui redonne sa chance mais je n'interviendrai pas beaucoup.

----------

## pti-rem

Le retour en paquets stables est achevé.

J'ai un peu accéléré sur la fin avec une bonne quinzaine de paquets dont je n'avais pas une réelle utilité et qui pouvaient être retirés. 

Ce fut une expérience intéressante ; Elle m'a fait ralentir mon rythme et elle a révélé des points que je dois mieux étudier.

Donc « ce n'est pas une mince affaire » en effet, mais c'est possible.

Cet achèvement est symbolique ; ce n'est qu'un trait dessiné dans le sable.

Je vais continuer mon utilisation ordinaire de Gentoo sur mon transportable presque vieux de 10 ans.

Je ne m'interdis pas du tout d'installer autre chose que du stable.

Pour le moment, je vais la tester telle qu'elle est quelques temps.

Et j'ai besoin de souffler aussi...

Je remercie toutes les personnes qui m'ont aidé en contribuant.

```
n73sm ~ # eix --installed-unstable

No matches found

n73sm ~ # ls /etc/portage/package.accept_keywords/

n73sm ~ # grep ACCEPT_KEYWORDS /etc/portage/make.conf

#ACCEPT_KEYWORDS="~amd64"

n73sm ~ #
```

----------

