Reprise du message précédent :

Firefox et Thunderbird mettaient "vraiment" beaucoup de temps à se lancer, Simplescan aussi, depuis la grosse mise à jour python. Résolu après désinstallation de  xdg-desktop-portal-gnome et de gnome-desktop-4 devenu orphelin. Rien à voir avec python. Je suis sous Cinnamon.  
J'avais ce paquet installé depuis 2021 (41.1) mis à jour (43.1-1 -> 44.1-2) le 07/05. A propos de xdg-desktop-portal-gnome : https://wiki.archlinux.org/title/XDG_Desktop_Portal . Je n'utilise ni Wayland, ni flatpak?
J'ai trouvé la solution dans ce sujet: https://bbs.archlinux.org/viewtopic.php?id=275618  
A toutes fins utiles à d'autre  

En passant:
 
https://forum.endeavouros.com/t/arc [...] 21st/40391
https://lists.archlinux.org/archive [...] WA76SM3IO/
 
"Arch passe à  Git le week-end du 19 mai au 21 mai.
Les packages Arch vont passer à Git et, par conséquent, les packages et les services de synchronisation miroir seront fermés ce week-end. Il n'y aura pas de déploiement de mises à jour ce week-end."

J'ai quelques softs qui mettent effectivement plus de temps à se lancer depuis quelques jours, je ne sais pas si c'est lié à la mise à jour dont tu parles.
Firefox et Thunderbird en font partie, et aussi Evince (plusieurs secondes pour ouvrir un pdf c'est assez pénible, alors qu'avant c'était quasi-immédiat, et j'ai une vieille machine).
Mais ça n'atteint quand même pas les 25 secondes d'un timeout dbus (heureusement!)

 
Nouveau SSD qui arrive d'ici fin de semaine, je voulais refaire une install arch clean ce week-end. J'espère qu'il arrivera demain que je puisse faire ça tranquille jeudi férié du coup.
 
Par contre il y a un article qui explique pourquoi le passage à git et les avantages qui en découlent (si il y a) ?

 
Un extrait traduit de ce post en anglais: https://forum.endeavouros.com/t/arc [...] ng/40387/7 .  
"AUR utilise déjà git. Les dépôts officiels utilisent SVN et le convertissent en git et l'enregistrent sur github. Maintenant, cette étape sera terminée et les dépôts officiels pousseront directement vers git et enregistreront tout sur gitlab.
Peu de temps après, le rapport de bogue se produira également sur la page gitlab au lieu d'utiliser le système de rapport de bogue actuel. Les utilisateurs pourront également créer des pull requests."
 
Cette migration va faciliter le travail des devs en supprimant une étape, et si j'ai tout compris facilitera aussi la collaboration.
L'annonce officielle avec le planning: https://lists.archlinux.org/archive [...] WA76SM3IO/

Salut,
Jettes un œil au post de gee du  06-05-2023, la page d'avant, à tout hasard... Dans mon cas, je ne devais pas être loin des 25 secondes d'un timeout dbus!
rebuild-detector est dans les dépôts.

Non c'était bien un problème de timeout dbus avec xdg-desktop-portal-gnome comme dans le thread que tu citais au-dessus, sauf qu'il a été ramené à moins de 25 secondes quelque part (c'est juste la valeur par défaut en général).
J'ai remplacé xdg-desktop-portal-gnome par xdg-desktop-portal-gtk et c'est bon (j'avais xdg-desktop-portal-gnome par facilité pour d'autres dépendances mais en fait je n'en ai pas vraiment besoin).
Voir aussi :
* https://bbs.archlinux.org/viewtopic.php?id=285590
* https://gitlab.gnome.org/GNOME/xdg- [...] /issues/74

 
Pour suivre l'avancement de la migration:
https://md.archlinux.org/utjjQ-bQTsipIKntPrpf8g#

hé ben, sacré planning !

Clair, je ne m'attendais pas à autant, impressionnant pour des volontaires!

Si on va voir sur le site, on voit qu’ils n’hébergent désormais plus les PKGBUILD sur GitHub, mais sur un Gitlab maison. Exemple avec Pacman (qui vient de recevoir une MAJ qui apporte un pacman.conf reconfiguré → attention à bien rétablir les éventuels dépôts ajoutés manuellement ou Multilib, quand elle sera installée !) :
https://gitlab.archlinux.org/archli [...] ges/pacman

Migration terminée, système de MAJ relancé (attention à vos miroirs, même s’ils doivent être synchronisés, maintenant), les instructions sont ici :
 
https://archlinux.org/news/git-migration-completed/
 
En gros, ça se résume à ça :

Et un tour dans les fichiers « /etc/pacman.conf » et « /etc/pacman.conf.pacnew » pour fusionner les éventuelles différences entre les deux.
 
Perso, après avoir réactivé le paramètre « Color » et le dépôt Multilib, un petit coup de « sudo pacman -Syy » suivi d’un « time yay » n’a remonté aucune erreur, donc ça devrait être bon pour moi.

Je vais laisser les autres essuyer les plâtres pendant quelques petits jours

Idem ici, modif faite sans aucun souci

Y a pas d’histoire d’« essuyer les plâtres » : le plan de migration prévoyait de profiter de l’occasion pour fusionner les dépôts Extra et Community, en reversant le contenu du deuxième dans le premier (et répartir les dépôts Testing entre leurs canaux Core et Extra respectifs).

De fait, Community n’existe plus (Pacman le considère comme vide), et ne restent donc que Core, Extra et Multilib, ainsi que leurs pendants Testing. Le remplacement de pacman.conf est nécessaire pour bien remettre la configuration des dépôts officiels d’aplomb. Si t’es sur le canal Stable, c’est pas vital à faire, mais ça reste plus propre (et obligatoire sur Testing, puisque les dépôts ont changé de nom sur ce canal). Ça se fait en deux minutes si on n’avait pas trop personnalisé ce fichier, et une fois que c’est fait, y a plus rien à faire d’autre que de refaire les MAJ comme avant (Yay n’est aucunement affecté par le changement, c’est déjà ça).

Alors, pas expérience, depuis presque 40 ans, je n'installe jamais les OS day one, quelque soit leur origine et leur nature, que ce soit de la pomme, du pingouin ou de la fenêtre. La liste des défaillances est longue comme un jour sans pain.  
 
Néanmoins je comprends l'excitation de tester quelque chose de nouveau, mais c'est sans moi.  
 

Y a rien de nouveau, juste une migration de serveurs, soit ça marche, soit ça marche pas, dans le pire des cas, pas de mise à jour proposée par pacman    
 
En tout cas je n'ai ressenti aucune excitation à supprimer deux lignes de mon pacman.conf et relancer la mise à jour  

Ben, oui, voilà : c’est pas une question de nouveauté à tester, juste de régler le dispositif de mises à jour de l’OS après sa migration en amont ce week-end. C’est juste de la maintenance de base, rien de plus. Et c’est pas du test, vu que c’est déjà en prod (en amont, toujours).
 
Quant à l’excitation… Honnêtement, je me passerais bien de devoir mettre ainsi les mains dans le cambouis, à une époque où justement tout l’écosystème est devenu mature et stabilisé au point que les nouvelles versions ne consistent guère plus qu’en des améliorations de l’existant et que les ruptures se feront désormais rares à l’avenir. Quand on voit que la prochaine « rupture » annoncée par Intel est la sortie d’une architecture x86 64 bits débarrassée de la prise en charge des modes 16 et 32 bits ; ou que, côté navigateurs, la révolution à venir est la fin de la prise en charge des cookies tiers… C’est clair que tout ce qui pouvait être à faire en termes de réelles innovations l’a déjà été, au moins dans un avenir prévisible.

 
Tux est un Manchot, c'est un faux ami.
Manchot => Penguin
Pingouin => Auk

En gros la seule modif à faire (pour ceux qui n'utilisent pas le dépôt testing, et qui sont dans le cas général d'utilisation des dépôts stables) c'est de supprimer cette ligne ?

Car je n'ai pas vu d'autres différences importantes dans mon fichier de configuration par rapport au nouveau.

Les seuls dépôts que j'utilise :

Et j'ai vu l'apparition d'une nouvelle option :

Oui, rien de plus

Oh, la m××de… >__<
 
Si vous avez un GPU AMD et que vous utilisez le pilote Radeon (pas AMDGPU, donc), vous pourriez avoir (mais pas forcément) un affichage foiré après avoir mis à jour le paquet « mesa » en 23.1.0 :
 
https://bugs.archlinux.org/task/78598
 
Signalé en amont :
https://gitlab.freedesktop.org/mesa/mesa/-/issues/9034
 
Solution : revenir et rester en 23.0.3

Ah , je suis passé entre les gouttes apparemment : Radeon HD 7310, mesa-vdpau 23.1.0, pas de problème.
 
PS: @Trit' tes liens sont cassés à cause de balises br

Pas concerné je suis sur AMDGPU sur ma 6900XT ...

Merci pour le signalement, c’est corrigé (le triple clic sur les lignes des liens avait manifestement pris en compte les retours à la ligne…).
 
Ici, RAS avec la Radeon Mobility HD 4530 du portable. Mais j’ai le bug avec la R7 240 du fixe…
 
Pour voir si on est touché, c’est très facile : il suffit d’ouvrir MPV à vide ou le panneau de configuration de XScreenSaver et choisir l’écran de veille « GLSlideShow ». Si le logo de MPV au milieu de sa fenêtre  et l’aperçu du diaporama de XScreenSaver sont OK, c’est bon. Sinon, ça se manifeste par des lignes de couleurs, des images toutes blanches… Bref, de la corruption d’affichage comme on n’aime pas. Un simple retour en arrière de « mesa » et éventuellement « lib32-mesa » (et évidemment, blocage des mises à jour du ou des paquets dans pacman.conf…) suffit à remettre les choses en ordre. Mais ça veut dire qu’il faut récupérer les versions 23.0.3 en local (et les mettre à un endroit où ils ne seront pas supprimés après un « sudo pacman -Scc »).
 
Il est souhaitable que ce bug soit corrigé dans une prochaine version de Mesa, parce qu’on peut pas rester indéfiniment sur un paquet en version bloquée…

Ah, ça ne toucherait pas que les GPU AMD : les Intel i915 aussi sont concernés !
 

Pas de souci aussi avec une radeon HD4650 PCIe,

pour aider les développeurs à résoudre le problème : on peut utiliser la fonctionnalité "git bisect" de git pour trouver le commit qui a introduit le bug,
https://galadrim.fr/blog/trouver-lo [...] git-bisect

dans le cadre d'un paquet archlinux : on télécharge les sources du paquet archlinux, on fait le git bisect, à chaque itération on crée avec makepkg le paquet correspondant à cette version d'essai,
puis on installe le paquet, si le bug disparait/revient alors le git bisect aura trouvé le commit coupable,

une fois le commit coupable trouvé : on peut créer (en attendant que les développeurs trouvent la solution définitive) un fichier patch destiné à défaire les changements introduits par ce commit bogué, puis on modifie le PKGBUILD de la dernière version du paquet mesa pour que le patch soit appliqué sur le code source,

je l'avais fait à l'époque sur le paquet mesa, mais c'était il y a très longtemps, j'avais utilisé un script bash pour automatiser la création du paquet,
d'autres ne passent pas par l'étape de création de paquet, ils font un make, et utilisent une variable d'environnement qui pointe vers le dossier de compilation (là où se trouvent les binaires et les bibliothèques mesa) de cette version de mesa pour que le système l'utilise directement.

Genre, je vais compiler Mesa sur mes bécanes de 2009¹…
 
Mais oui, ça semble ne toucher que les GPU « récents » (je me comprends), pas ceux qui datent d’il y a plus de 10 ans.
 
¹ En plus récent, je n’ai que deux netbooks de 2010 et 2012, une Surface RT 1ère version et un Chromebook Asus EOL depuis un an, donc ils ne comptent pas.

Après tu peux compiler sur une machine plus récente, et uploader ensuite le paquet vers le vieux PC.

Le git bisect c'est surtout quand tu sens que le développeur ne veut pas s'embêter à résoudre le bug, lorsque celui-ci ne touche qu'un nombre réduit d'utilisateurs, il y a des développeurs qui pensent que l'utilisateur n'a qu'à upgrader son matos, le bug risque alors d'être jamais résolu si on ne met pas de pression sur le développeur, si tu l'aides en lui montrant le commit défectueux ça peut débloquer la chose.

Je viens de dire que je n’avais pas (et non, je ne prévois pas d’acheter tant que le matos actuel marche encore)…
 

1. Dans le cas de Mesa (qui doit avoir plus qu’un dev pour être maintenu), je pense qu’il est trop tôt pour le dire.
 
2. Un des principaux mainteneurs d’Arch lui-même a mentionné le bug sur FreeDesktop.
 
Ah, il se pourrait que ce soit corrigé dans Mesa 23.1.1 (encore dans Extra-Testing pour le moment). À voir.

j'ai la même stratégie ,
mon PC principal est toujours basé sur un CPU de 2008 (intel quad core Q9650 3 Ghz) et une carte graphique de 2009 (radeon HD4650),

mais j'ai un peu triché : j'ai ajouté une carte contrôleur PCIe USB3, je suis passé au SSD, et au maximum permis par la carte mère en terme de mémoire vive (8 Go), et j'évite les usages trop modernes type vidéo 4K, jeux récents, calcul scientifique.

Je pourrais acheter un PC récent, mais si on garde les mêmes usages de 2009 (surf internet, bureautique, retouche photo, vidéos HD) alors on ne verra pas vraiment de différence, j'ai fait le test sur un PC du boulot qui a un CPU de 2019, pas vraiment de boost de performance sur les usages courants, libreoffice, firefox ont à peu près la même réactivité.

Ce qui me poussera à changer c'est la panne du PC, l'envie de faire de la 4K (montage vidéo, compression matérielle avec une carte graphique récente), et une baisse des prix du matos PC.
Et bien sûr l'obsolescence programmée, si les développeurs linux décident de ne plus supporter du trop vieux matos.

C'est le cas du logiciel Blender, les versions récentes ne s'exécutent plus quand on a une trop vieille carte graphique, ça demande une version minimale d'OpenGL, un choix des développeurs, ils ne veulent plus faire de bidouilles pour assurer la rétro-compatibilité.

Comme annoncé, c’est corrigé avec Mesa 23.1.1 sur les GPU AMD utilisant le pilote Radeon. Vérifié en ouvrant MPV et le panneau de configuration de XScreenSaver.

Mais toujours buggué sur les Intel i915, semble-t-il…

Hello,
 
Suite à la mise à jour des dépots, j'ai ce message:

 
J'ai fusionné pacman.conf.new et pacman.conf
et executer
pacman -Syu "pacman>=6.0.2-7"
 
extra ne devrait plus exister, non ?

Tu devrais plutôt poster ça sur le TU Manjaro (qui dispose de ses propres dépôts).
 
Mais s’ils ont suivi la même procédure qu’Arch, alors c’est Community qui a disparu, avec tout son contenu déplacé dans Extra.

oui, merci

Quant à savoir maintenant pourquoi tu as un paquet (normalement apporté par l’installation de Manjaro) dans une version supérieure à celle qui est dans les dépôts, ça…
 
Tu as trois possibilités pour régler ça, sauf qu’il faut t’assurer que ça ne va pas causer de problèmes avec les dépendances :

• forcer l’écrasement de la 0.7.0-6 par la 0.7.0-5 (le trait d’union indiquant que c’est juste une recompilation du paquet, peut-être à cause de la MAJ d’une dépendance).
• désinstaller et réinstaller le paquet (mais attention s’il veut aussi en désinstaller d’autres en même temps).
• Désinstaller purement et simplement manjaro-hello (c’est juste l’écran de bienvenue, c’est ça ?)

J'ai désinstallé puis réinstallé depuis le software Center, en vérifiant les version.

J'ai remarqué que la dernière version de firefox entraine une hausse du % CPU quand je lis des vidéos youtube, comme si l'accélération graphique était désactivée, j'entend le ventilateur qui turbine à fond, puis la vitesse du ventilateur baisse quand j'arrête de lire la vidéo.

J'ai une vieille carte graphique (radeon HD4650).

Comme on t’a répondu sur le TU Firefox, pour savoir si c’est bien à cause de ce dernier et pas du fait que YouTube utilise par défaut du VP9 depuis des années, as-tu essayé de regarder ta vidéo en ayant installé l’extension h264ify (qui force l’utilisation des formats H.264 au lieu de VP9, mais ça limite donc les choix à 360p et 720p) ? Ou en passant par une instance Invidious (remplace la chaîne « www .youtube .com » par « invidious .fdn .fr », sans les espaces, évidemment), qui privilégie aussi par défaut les formats H.264 ?

Oui c'est possible que ça soit dû à l'usage par défaut du codec VP9 par youtube.

edit: trompage de topic.