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: 344
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 | 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: 344
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 | 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: 344
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 | 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: 344
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 | 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: 344
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 | 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: 512

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: 344
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 | 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: 512

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: 344
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 | 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: 512

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: 344
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 | 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: 344
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 | 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: 344
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 | 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: 344
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 | 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: 512

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: 344
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 | 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: 344
Location: Grande Aquitaine, FRANCE

PostPosted: Wed Aug 05, 2020 1:03 am    Post subject: quelques nouvelles Reply with quote

Bonjour,

Le remplacement des versions unstable / testing des paquets continue progressivement.
Code:
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 :
Code:
# 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 :
Code:
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 ;-) C'est pas ça qui va faire dérailler le train !

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.97
_________________
Il faut être léger pour voler sur les cailloux ! amd64/17.1/desktop | 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: 344
Location: Grande Aquitaine, FRANCE

PostPosted: Tue Aug 18, 2020 10:48 pm    Post subject: iptables et iproute2 deviennent stables Reply with quote

Bonjour,

net-firewall/iptables et sys-apps/iproute2 deviennent stables depuis le repo gentoo.
=media-video/mkvtoolnix-48.0.0 également.

eix-diff a écrit :
[*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

emerge dev-libs/zziplib a écrit :
>>> 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.

Code:
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 »

Code:
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
_________________
Il faut être léger pour voler sur les cailloux ! amd64/17.1/desktop | 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: 344
Location: Grande Aquitaine, FRANCE

PostPosted: Sun Aug 30, 2020 8:46 am    Post subject: ça avance... Reply with quote

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

entre autres, eix-diff montre :
[*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

Code:
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 ~ #

_________________
Il faut être léger pour voler sur les cailloux ! amd64/17.1/desktop | 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: 344
Location: Grande Aquitaine, FRANCE

PostPosted: Sun Sep 13, 2020 5:09 am    Post subject: un peu coincé sur ce coup là Reply with quote

Bonjour,

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

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

Code:
!!! 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

Code:
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.

Code:
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.
_________________
Il faut être léger pour voler sur les cailloux ! amd64/17.1/desktop | 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: 344
Location: Grande Aquitaine, FRANCE

PostPosted: Sun Nov 01, 2020 8:19 am    Post subject: Reply with quote

Bonjour,

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

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

eix-diff :
[*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 :
eix-diff :
[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.
_________________
Il faut être léger pour voler sur les cailloux ! amd64/17.1/desktop | 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