| View previous topic :: View next topic |
| Author |
Message |
pti-rem
Guru
Joined: 14 Oct 2011
Posts: 472
|
 Posted: Fri Mar 27, 2020 11:34 am Post subject: Rebasculer de ~arch vers arch (sans ACCEPT_KEYWORDS) |
 |
|
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.
| sebB wrote: | Par le jeu des dépendances, ça va vite devenir bloquant si tu n'es pas vigilant.
Le but étant d'éviter les downgrade, donc jouer avec le package.accept_keywords un bon moment encore.
Il faut que, soit tes paquets instables deviennent stable, soit qu'une version stable supérieure arrive. |
Ce sujet est là pour aider en cas de pépin ou lors de questionnement relatif aux choix qui seront amenés à faire.
Je ne suis pas inquiet car mon système répond bien et je veux bien prendre le temps pour voir venir.
Je compte actualiser l'arbre de Gentoo et faire une mise à jour chaque matin.
Pour faire le eix-sync -a (dont emerge --sync) ; C'est bien une fois par 24h maximum pour ne pas être banni temporairement ?
| https://www.gentoo.org/support/rsync-mirrors/ wrote: | Sync netiquette
Please note: common gentoo-netiquette says you should not sync more than once a day.
Users who abuse the rsync.gentoo.org rotation may be added to a temporary ban list. |
Merci !
Last edited by pti-rem on Sun Apr 26, 2020 8:05 am; edited 1 time in total |
|
| Back to top |
|
 |
pti-rem
Guru
Joined: 14 Oct 2011
Posts: 472
|
| Posted: Sat Mar 28, 2020 9:22 am Post subject: dev-ruby/xmlrpc |
|
|
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 » 
Last edited by pti-rem on Sun Mar 29, 2020 4:17 pm; edited 1 time in total |
|
| Back to top |
|
|
pti-rem
Guru
Joined: 14 Oct 2011
Posts: 472
|
| Posted: Sun Mar 29, 2020 11:13 am Post subject: eix, gcc, python 3.6, binutils : en versions stables |
|
|
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.
Last edited by pti-rem on Tue Mar 31, 2020 8:00 am; edited 2 times in total |
|
| Back to top |
|
|
pti-rem
Guru
Joined: 14 Oct 2011
Posts: 472
|
| Posted: Tue Mar 31, 2020 7:41 am Post subject: libvncserver, sys-auth/rtkit, wine-vanilla et binutils |
|
|
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 ~ # |
|
|
| Back to top |
|
|
pti-rem
Guru
Joined: 14 Oct 2011
Posts: 472
|
| Posted: Sat Apr 11, 2020 5:38 am Post subject: sys-libs/glibc |
|
|
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 ~ # |
|
|
| Back to top |
|
|
YetiBarBar
Guru
Joined: 23 Dec 2005
Posts: 532
|
| Posted: Sat Apr 11, 2020 4:48 pm Post subject: |
|
|
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 |
|
|
pti-rem
Guru
Joined: 14 Oct 2011
Posts: 472
|
| Posted: Sat Apr 11, 2020 6:36 pm Post subject: |
|
|
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. |
|
| Back to top |
|
|
YetiBarBar
Guru
Joined: 23 Dec 2005
Posts: 532
|
| Posted: Sun Apr 12, 2020 9:52 am Post subject: |
|
|
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 |
|
|
pti-rem
Guru
Joined: 14 Oct 2011
Posts: 472
|
| Posted: Sun Apr 12, 2020 5:12 pm Post subject: |
|
|
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 ~ # |
|
|
| Back to top |
|
|
YetiBarBar
Guru
Joined: 23 Dec 2005
Posts: 532
|
| Posted: Mon Apr 13, 2020 6:02 am Post subject: |
|
|
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 |
|
|
pti-rem
Guru
Joined: 14 Oct 2011
Posts: 472
|
| Posted: Mon Apr 13, 2020 9:32 am Post subject: |
|
|
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. |
|
| Back to top |
|
|
pti-rem
Guru
Joined: 14 Oct 2011
Posts: 472
|
| Posted: Mon Apr 13, 2020 4:41 pm Post subject: |
|
|
| 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 |
|
| Back to top |
|
|
pti-rem
Guru
Joined: 14 Oct 2011
Posts: 472
|
| Posted: Mon Apr 13, 2020 5:50 pm Post subject: Youpi ! |
|
|
| 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] |
|
|
| Back to top |
|
|
pti-rem
Guru
Joined: 14 Oct 2011
Posts: 472
|
| Posted: Tue Apr 14, 2020 12:11 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
YetiBarBar
Guru
Joined: 23 Dec 2005
Posts: 532
|
| Posted: Fri Apr 24, 2020 8:38 am Post subject: |
|
|
| glibc-2.30-r8 est stabilisé! |
|
| Back to top |
|
|
pti-rem
Guru
Joined: 14 Oct 2011
Posts: 472
|
| Posted: Fri Apr 24, 2020 10:31 am Post subject: glibc-2.30-r8 est stabilisé! |
|
|
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 |
|
|
| Back to top |
|
|
pti-rem
Guru
Joined: 14 Oct 2011
Posts: 472
|
| Posted: Wed Aug 05, 2020 1:03 am Post subject: quelques nouvelles |
|
|
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 planter le système.
Aussi, il faudrait peut-être que je mette à jour mon noyau sys-kernel/gentoo-sources en 4.19.120 ou 4.19.129 (stables) mais c'est toujours pareil,
quasi-impossible de trouver une version stable pérenne ; c'est agaçant pour tout dire.
Je ne sais pas trouver le statut de mon noyau actuel 4.19.97
Last edited by pti-rem on Tue Apr 26, 2022 8:15 am; edited 1 time in total |
|
| Back to top |
|
|
pti-rem
Guru
Joined: 14 Oct 2011
Posts: 472
|
| Posted: Tue Aug 18, 2020 10:48 pm Post subject: iptables et iproute2 deviennent stables |
|
|
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 |
|
| Back to top |
|
|
pti-rem
Guru
Joined: 14 Oct 2011
Posts: 472
|
| Posted: Sun Aug 30, 2020 8:46 am Post subject: ça avance... |
|
|
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 ~ # |
|
|
| Back to top |
|
|
pti-rem
Guru
Joined: 14 Oct 2011
Posts: 472
|
| Posted: Sun Sep 13, 2020 5:09 am Post subject: un peu coincé sur ce coup là |
|
|
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. |
|
| Back to top |
|
|
pti-rem
Guru
Joined: 14 Oct 2011
Posts: 472
|
| Posted: Sun Nov 01, 2020 8:19 am Post subject: |
|
|
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.
| emerge --version : | | Portage 3.0.9 (python 3.7.9-final-0, default/linux/amd64/17.1/desktop, gcc-9.2.0, glibc-2.32-r2, 4.19.97-gentoo x86_64) |
« Your system is consistent »
« Found 88 matches » unstables |
|
| Back to top |
|
|
pti-rem
Guru
Joined: 14 Oct 2011
Posts: 472
|
| Posted: Thu Mar 11, 2021 9:59 am Post subject: dev-python/zstandard |
|
|
Bonjour,
Je commence la mise à jour quotidienne et je rencontre un questionnement.
| eix-diff : | | [?] == dev-python/zstandard (0.15.1@07/03/2021; (~)0.15.1^t -> 0.14.1^t): Zstandard Bindings for Python |
| emerge -pvuDN dev-python/zstandard : | n73sm ~ # emerge -pvuDN dev-python/zstandard
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild U ] x11-libs/libXt-1.2.1::gentoo [1.2.0::gentoo] USE="-doc -test" ABI_X86="32 (64) (-x32)" 767 KiB
[ebuild U ] x11-libs/libdrm-2.4.104::gentoo [2.4.103::gentoo] USE="-libkms -valgrind" ABI_X86="32 (64) (-x32)" VIDEO_CARDS="intel nouveau -amdgpu (-exynos) (-freedreno) (-omap) -radeon (-tegra) (-vc4) (-vivante) -vmware" 410 KiB
[ebuild U ] dev-libs/libevdev-1.11.0::gentoo [1.10.0::gentoo] USE="-doc -test" ABI_X86="(64) -32 (-x32)" 435 KiB
[ebuild UD ] dev-python/zstandard-0.14.1::gentoo [0.15.1::gentoo] USE="-test" PYTHON_TARGETS="python3_7 python3_8 -python3_9 (-pypy3%)" 0 KiB
[ebuild U ] media-libs/mesa-20.3.4::gentoo [20.2.6::gentoo] USE="X classic dri3 egl gallium gbm gles2 llvm zstd -d3d9 -debug -gles1 -lm-sensors -opencl -osmesa (-selinux) -test -unwind -vaapi -valgrind -vdpau -vulkan -vulkan-overlay -wayland -xa -xvmc -zink" ABI_X86="32 (64) (-x32)" VIDEO_CARDS="i915 i965 intel (-freedreno) -iris (-lima) -nouveau (-panfrost) -r100 -r200 -r300 -r600 -radeon -radeonsi (-v3d) (-vc4) -virgl (-vivante) -vmware" 13 920 KiB
[ebuild U ] media-libs/libepoxy-1.5.5::gentoo [1.5.4::gentoo] USE="X egl -test" ABI_X86="32 (64) (-x32)" 325 KiB
Total: 6 packages (5 upgrades, 1 downgrade), Size of downloads: 15 855 KiB
n73sm ~ # |
Je ne sais pas si je dois accepter sans crainte le downgrade de dev-python/zstandard
J'ai bien envie de le faire comme j'ai pu le faire plusieurs fois auparavant pour d'autres paquets plus "évidents"
Mais ce paquet dev-python/zstandard est quand même un peu particulier, non ?
Qu'en pensez-vous ?
Bon... Vu que la version (~)0.15.1^t a été installée récemment, le 07/03/2021 dernier, je vais faire selon ce que me préconise Portage.
« Your system is consistent »
« Found 56 matches » installed-unstable
Last edited by pti-rem on Thu Mar 11, 2021 11:05 am; edited 1 time in total |
|
| Back to top |
|
|
YetiBarBar
Guru
Joined: 23 Dec 2005
Posts: 532
|
| Posted: Thu Mar 11, 2021 10:59 am Post subject: |
|
|
Bonjour,
Que lui trouves-tu de particulier? Qui en dépend?
| Code: | | equery depends dev-python/zstandard |
(Ce paquet n'est pas installé sur ma machine) |
|
| Back to top |
|
|
pti-rem
Guru
Joined: 14 Oct 2011
Posts: 472
|
| Posted: Thu Mar 11, 2021 11:13 am Post subject: |
|
|
Bonjour YetiBarBar,
Rien que le nom "zstandard" de Python.
| Code: | n73sm ~ # equery depends dev-python/zstandard
* These packages depend on dev-python/zstandard:
dev-vcs/mercurial-5.6.1-r1 (dev-python/zstandard[python_targets_python3_7(-)?,python_targets_python3_8(-)?,-python_single_target_python3_7(-),-python_single_target_python3_8(-)])
n73sm ~ # |
Encore une commande que je ne connaissais pas, merci.
Je ne sais plus trop pourquoi - comment j'ai dev-vcs/mercurial dans mon système ni à quoi il sert.
J'ai dû mettre un USE il y a longtemps. Faut croire que je voulais expérimenter...
| Code: | n73sm ~ # grep -R mercurial /etc/portage/package.use/ | grep -v "#"
/etc/portage/package.use/petit-paquet:>=app-portage/layman-2.4.3::gentoo git cvs mercurial subversion
/etc/portage/package.use/python-upgrades:dev-vcs/mercurial PYTHON_TARGETS: python2_7 python3_6
n73sm ~ # |
Tel que je vois la chose là, le USE mercurial pour >=app-portage/layman-2.4.3::gentoo est à enlever maintenant.
Last edited by pti-rem on Fri Mar 12, 2021 6:09 am; edited 1 time in total |
|
| Back to top |
|
|
YetiBarBar
Guru
Joined: 23 Dec 2005
Posts: 532
|
| Posted: Thu Mar 11, 2021 11:26 am Post subject: |
|
|
Du coup, on vait faire un mode récursif^^!
A mon avis, soit c'est juste un USE flag "mercurial" qui traine quelquepart dans ta conf. (soit make.conf, soit dans le profil, soit au niveau des package.use)
En tout cas, sauf si tu as un besoin primordial d'accéder à mercurial ou que tu utilises un overlay basé sur mercurial, tu ne risques rien!
Que dis la commande:
|
|
| Back to top |
|
|
|
|
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
|
|
French
