Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Rebasculer de ~arch vers arch (sans ACCEPT_KEYWORDS)
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index French
View previous topic :: View next topic  
Author Message
pti-rem
Guru
Guru


Joined: 14 Oct 2011
Posts: 334
Location: Grande Aquitaine, FRANCE

PostPosted: Fri Mar 27, 2020 11:34 am    Post subject: Rebasculer de ~arch vers arch (sans ACCEPT_KEYWORDS) Reply with quote

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.
Code:
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 !
_________________
Il faut être léger pour voler sur les cailloux ! amd64/17.1/desktop (stable) | release 2.7 | ~amd64 vers stable (avec des paquets testing) | GMT


Last edited by pti-rem on Sun Apr 26, 2020 8:05 am; edited 1 time in total
Back to top
View user's profile Send private message
pti-rem
Guru
Guru


Joined: 14 Oct 2011
Posts: 334
Location: Grande Aquitaine, FRANCE

PostPosted: Sat Mar 28, 2020 9:22 am    Post subject: dev-ruby/xmlrpc Reply with quote

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 :

emerge -avuDN @world:
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.

emerge -pv dev-ruby/xmlrpc:
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 :

cat /etc/portage/package.mask/gentoo-2020:
#
# */*::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 :

emerge -avuDN @world:
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 :)

J'ai renommé mon overlay « g20 » : c'est moins long à saisir que « gentoo-2020 » ;)
_________________
Il faut être léger pour voler sur les cailloux ! amd64/17.1/desktop (stable) | release 2.7 | ~amd64 vers stable (avec des paquets testing) | GMT


Last edited by pti-rem on Sun Mar 29, 2020 4:17 pm; edited 1 time in total
Back to top
View user's profile Send private message
pti-rem
Guru
Guru


Joined: 14 Oct 2011
Posts: 334
Location: Grande Aquitaine, FRANCE

PostPosted: Sun Mar 29, 2020 11:13 am    Post subject: eix, gcc, python 3.6, binutils : en versions stables Reply with quote

Bonjour,

J'ai préféré revenir à une version stable de app-portage/eix:
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 ~ #

J'ai également compilé et sélectionné une version stable de sys-devel/gcc:
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 ~ #

J'ai sélectionné par defaut la version stable 3.6 de dev-lang/python:
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 ~ #

J'ai installé et sélectionné une version stable de sys-devel/binutils:
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 :

emerge --version:
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.
_________________
Il faut être léger pour voler sur les cailloux ! amd64/17.1/desktop (stable) | release 2.7 | ~amd64 vers stable (avec des paquets testing) | GMT


Last edited by pti-rem on Tue Mar 31, 2020 8:00 am; edited 2 times in total
Back to top
View user's profile Send private message
pti-rem
Guru
Guru


Joined: 14 Oct 2011
Posts: 334
Location: Grande Aquitaine, FRANCE

PostPosted: Tue Mar 31, 2020 7:41 am    Post subject: libvncserver, sys-auth/rtkit, wine-vanilla et binutils Reply with quote

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.

downgrade en stable de sys-auth/rtkit:
n73sm ~ # emerge -p sys-auth/rtkit
[ebuild   R    ] sys-auth/rtkit-0.11-r2
n73sm ~ #

ajout de wine-vanilla:4.0.2 et retrait de wine-vanilla:4.0 (stables):
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.

Rétropédalage pour sys-devel/binutils:
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 ~ #

_________________
Il faut être léger pour voler sur les cailloux ! amd64/17.1/desktop (stable) | release 2.7 | ~amd64 vers stable (avec des paquets testing) | GMT
Back to top
View user's profile Send private message
pti-rem
Guru
Guru


Joined: 14 Oct 2011
Posts: 334
Location: Grande Aquitaine, FRANCE

PostPosted: Sat Apr 11, 2020 5:38 am    Post subject: sys-libs/glibc Reply with quote

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.

downgrade stable de glibc:
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

le nombre de paquets installés en ~amd64:
n73sm ~ # qgrep -JlNR -x "~amd64 +" | sort | uniq | wc -l
508
n73sm ~ #

_________________
Il faut être léger pour voler sur les cailloux ! amd64/17.1/desktop (stable) | release 2.7 | ~amd64 vers stable (avec des paquets testing) | GMT
Back to top
View user's profile Send private message
YetiBarBar
Guru
Guru


Joined: 23 Dec 2005
Posts: 510

PostPosted: Sat Apr 11, 2020 4:48 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
pti-rem
Guru
Guru


Joined: 14 Oct 2011
Posts: 334
Location: Grande Aquitaine, FRANCE

PostPosted: Sat Apr 11, 2020 6:36 pm    Post subject: Reply with quote

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 :

le 27 mars:
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 :

sys-libs/glibc/glibc-2.30-r6.ebuild de l'overlay local « g20 »:
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 ;)

YetiBarBar wrote:
En revanche, on ne downgrade JAMAIS glibc

C'est très clair. Merci.
_________________
Il faut être léger pour voler sur les cailloux ! amd64/17.1/desktop (stable) | release 2.7 | ~amd64 vers stable (avec des paquets testing) | GMT
Back to top
View user's profile Send private message
YetiBarBar
Guru
Guru


Joined: 23 Dec 2005
Posts: 510

PostPosted: Sun Apr 12, 2020 9:52 am    Post subject: Reply with quote

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).
Back to top
View user's profile Send private message
pti-rem
Guru
Guru


Joined: 14 Oct 2011
Posts: 334
Location: Grande Aquitaine, FRANCE

PostPosted: Sun Apr 12, 2020 5:12 pm    Post subject: Reply with quote

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.

Search ~amd64 ebuilds in the Portage tree:
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.

equery has repository g20:
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 ;)

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 :)

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)

emerge --version:
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 ~ #

_________________
Il faut être léger pour voler sur les cailloux ! amd64/17.1/desktop (stable) | release 2.7 | ~amd64 vers stable (avec des paquets testing) | GMT
Back to top
View user's profile Send private message
YetiBarBar
Guru
Guru


Joined: 23 Dec 2005
Posts: 510

PostPosted: Mon Apr 13, 2020 6:02 am    Post subject: Reply with quote

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
Code:
/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 ?
Code:
eix --installed-unstable
Back to top
View user's profile Send private message
pti-rem
Guru
Guru


Joined: 14 Oct 2011
Posts: 334
Location: Grande Aquitaine, FRANCE

PostPosted: Mon Apr 13, 2020 9:32 am    Post subject: Reply with quote

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 :

Code:
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 ;)

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.
_________________
Il faut être léger pour voler sur les cailloux ! amd64/17.1/desktop (stable) | release 2.7 | ~amd64 vers stable (avec des paquets testing) | GMT
Back to top
View user's profile Send private message
pti-rem
Guru
Guru


Joined: 14 Oct 2011
Posts: 334
Location: Grande Aquitaine, FRANCE

PostPosted: Mon Apr 13, 2020 4:41 pm    Post subject: Reply with quote

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 :

/root/emerge-pvuDN-world-2020-04-13-0.txt:
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 :

/etc/portage/package.mask/gentoo-2020:
#
# */*::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 ;)

Merci encore sebB & Merci bien YetiBarBar
_________________
Il faut être léger pour voler sur les cailloux ! amd64/17.1/desktop (stable) | release 2.7 | ~amd64 vers stable (avec des paquets testing) | GMT
Back to top
View user's profile Send private message
pti-rem
Guru
Guru


Joined: 14 Oct 2011
Posts: 334
Location: Grande Aquitaine, FRANCE

PostPosted: Mon Apr 13, 2020 5:50 pm    Post subject: Youpi ! Reply with quote

Youpi ! :
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]

_________________
Il faut être léger pour voler sur les cailloux ! amd64/17.1/desktop (stable) | release 2.7 | ~amd64 vers stable (avec des paquets testing) | GMT
Back to top
View user's profile Send private message
pti-rem
Guru
Guru


Joined: 14 Oct 2011
Posts: 334
Location: Grande Aquitaine, FRANCE

PostPosted: Tue Apr 14, 2020 12:11 pm    Post subject: Reply with quote

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.
_________________
Il faut être léger pour voler sur les cailloux ! amd64/17.1/desktop (stable) | release 2.7 | ~amd64 vers stable (avec des paquets testing) | GMT
Back to top
View user's profile Send private message
YetiBarBar
Guru
Guru


Joined: 23 Dec 2005
Posts: 510

PostPosted: Fri Apr 24, 2020 8:38 am    Post subject: Reply with quote

glibc-2.30-r8 est stabilisé!
Back to top
View user's profile Send private message
pti-rem
Guru
Guru


Joined: 14 Oct 2011
Posts: 334
Location: Grande Aquitaine, FRANCE

PostPosted: Fri Apr 24, 2020 10:31 am    Post subject: glibc-2.30-r8 est stabilisé! Reply with quote

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

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

emerge --version:
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

_________________
Il faut être léger pour voler sur les cailloux ! amd64/17.1/desktop (stable) | release 2.7 | ~amd64 vers stable (avec des paquets testing) | GMT
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index French All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum