Reprise du message précédent :
J'ai encore l'ancienne version de chromium (84.0.4147.135), car je mets à jour mon système qu'une fois par semaine, pas de soucis graphique avec cette version.

Celle dont parle Minux est sortie qu'hier. il faudrait voir si en downgradant le paquet le problème disparaît.

Peut-être un souci de pilote graphique chez lui, surtout s'il utilise un pilote propriétaire, mais le problème devrait alors se produire aussi avec les autres applications.
Si c'est pas ça alors peut-être suspecter un problème de miroir pas à jour, des bibliothèques attendues par chromium qui auraient dû être à une version N, mais qui sont chez Minux à une version N-1 si son miroir n'est pas à jour, ou qu'il utilise un panachage de miroirs dans son fichier de configuration.

Je vais tenter de downgrader et tester (pilotes llibres amd), je vous dirai

Downgrade effectué en 84.0.4147.135, plus aucun problème sur Chromium, c'est donc bien la dernière version qui est bugguée

En effet, je viens de maj le paquet et je constate des bugs graphiques (chromium me sert de depannage quand un site ne fonctionne pas sous ff), pilote libre AMD egalement (5700xt)

Aucun souci chez moi avec Chromium 85, processeur Intel i3-3225 et environnement de bureau Mate
 
Et LibreOffice 7 est dispo !

Tu as une carte graphique AMD ou nvidia ?
 
Peut-être que le bug ne se produit que sur du amd.

Pas de carte graphique dédiée, uniquement le chipset Intel
CPU: Intel i3-3225 (4) @ 3.300GHz
GPU: Intel HD Graphics

Le fichier PKGBUILD de la dernière version de chromium a connu beaucoup de changements, des patchs qui ont disparu :

https://github.com/archlinux/svntog [...] d9db127101

peut-être ouvrir un rapport de bug pour signaler le problème.

Un début de réponse ici :
 
https://bbs.archlinux.org/viewtopic [...] 44031&p=16
 

Bon, comme dit ici, après la résolution victorieuse du problème sur mon portable, j’ai donc fini par faire la MAJ de pam et pambase sur le fixe, pensant que je pourrais donc éviter les soucis liés à cette version en réglant donc ce fichu fichier « /etc/security/faillock.conf » sur « deny = 0 »…
 
Ben, non : cette fois, ça n’a pas marché. XScreenSaver m’a refait le coup de l’authentification échouée quand j’ai voulu déverrouiller la session, et au redémarrage (en me connectant en root depuis un TTY), au lieu d’utiliser le thème « gtk2 » défini par la variable « QT_QPA_PLATFORMTHEME=qt5ct » dans  « /etc/environment », VLC (comme exemple de logiciel Qt5) s’affiche avec le thème Fusion (le thème par défaut des logiciels Qt5)…
 
J’ai vraiment tout vérifié, tout comparé entre les deux machines : il n’y a aucune différence dans les fichiers de configuration. Je n’ai pas de « .pam_environment », je n’ai plus d’appel à pam_tally2.so dans « etc/pam.d/system-login », pas de fichier « .pacnew » dans le dossier, faillock.conf n’avait que cette ligne « deny = 0 » de rajoutée… Et c’était tout ce qu’il avait fallu à mon portable pour retrouver un comportement normal de XScreenSaver, des applis Qt5, et même permettre à nouveau à PostgreSQL de se connecter à la base de données du logiciel Karaoke Mugen !
 
Je sais plus quoi faire…

Je n'ai pas bien compris le problème. Pas plus de soucis que ça ici, j'ai juste eu un problème de sortie de veille hier, mais comme c'est déjà arrivé, je ne m'alarme pas plus que ça. Je reboote et c'est marre.
 
Sinon, j'ai une question de noob.
 
Je voudrais installer ungoogled-chromium comme second navigateur, les fois où j'ai essayé, j'ai avorté l'installation car ça moulinait des heures (pas bien compris si c'était la compilation ou un bug).  
Ça ne m’intéresse pas trop de compiler moi-même, car de une, je ne l'ai jamais fais et de deux, pour maintenir à jour ça ne me semble pas ce qu'il y a de plus pratique, surtout si la compilation est longue.
 
Sur reddit j'ai vu que ça parlait de paquets pré-compilés sur un dépôt alternatif "archlinuxcn".

1- Est-ce que l'installation sera différente de ce que j'ai déjà essayé avec AUR ?
2- si oui, peut-on modifier pacman.conf de façon à prendre uniquement les fichiers concernant ungoogled-chromium sur ce dépôt ?
 
 

Je crois que la compilation d'un navigateur prend beaucoup de temps si le PC n'est pas très puissant, c'est un peu comme vouloir compiler libreoffice, gimp, c'est long.

Tu peux télécharger le paquet binaire avec un navigateur, puis l'installer avec pacman, avec l'option" -U nom_du_fichier_du_paquet".
Pour des scénarios d'utilisation compliqués essaie de jeter un coup d’œil sur la page wiki de pacman :
https://wiki.archlinux.org/index.php/pacman

Pour le problème de Trit : essaie de créer un nouvel utilisateur, pour tester avec, il aura un dossier home vierge, et donc une configuration par défaut, afin de voir si le problème disparaît.
Peut-être qu'il faudrait abandonner ces configurations manuelles, pour passer à un centre de configuration dirigé par ton environnement de bureau, ça serait peut-être un peu plus fiable, avec plasma il y a le programme "configuration du système", avec une section "Apparence, apparence des applications, style de l'application, style des applications "gnome/GTK", symétriquement il y a peut-être la même chose pour les applications Qt5 quand on utilise un environnement de bureau basé sur gnome.

Sinon lire ça :
https://wiki.archlinux.org/index.ph [...] plications

 
1- L'installation non, ca restera un paquet Arch Linux au final. Par contre tu n'auras rien a compiler toi-meme ce qui est pratique.
2- Non, mais tu peux ordonner des dépôts par priorité, et ungoogled n'est pas sur les dépôts standard.

à vous 2, je vais regarder de plus près.
 
j'avais regardé le wiki, Dans le wiki il est dit qu'on peut ajouter un serveur dans pacman.conf

Mais j'ai eu peur d'avoir mal compris et en plus j'utilise Reflector pour la liste des miroirs.
 
Faut que je regarde en ligne de commande, lancer une commande à chaque mise à jour, ça pourrait être jouable.

reflector n'a rien avoir dans ce ca.

Il n'agit que sur les

Il y a pareil pour archlinuxcn par contre mais je ne crois pas que reflector supporte autre chose que les serveurs de base.

Bon alors, j'ai juste ajouté en fin de pacman.conf

Puis j'ai actualisé les bases de données dans Pamac, qui a bien été voir le nouveau serveur et là j'avais le paquet ungoogle-chromium de archlinuxcn.
Mais le souci est que j'avais aussi un autre paquet à mettre à jour avec ce serveur, "Qt4" en l’occurrence.
 
Donc je suis passé sur yay (yay ungoogled-chromium) et j'ai installé le soft seul en rien de temps :-). J'ai même récupéré ma config Chromium d'avant.
 
Il y a une clé à charger avant avec "sudo pacman -Syy && sudo pacman -S archlinuxcn-keyring"
 
Puis j'ai remis pacman.conf comme avant pour ne pas faire de mise à jour hasardeuse sur les autres paquets.
 
Donc ce n'est pas vraiment top s'il faut faire la manip à chaque fois

Rien ne t’empêche d'ignore Qt4 dans pacman.conf ou meme de le mettre a jour.

Le seul risque, avec un dépôt tiers, c’est qu’il te propose une version obsolète (par rapport aux dépôts officiels, s’entend) d’un paquet. Mais pour ça, il faut avoir déclaré ledit dépôt tiers au-dessus de la liste des dépôts officiels dans pacman.conf (ce qu’il ne faut jamais faire, pour cette raison), et non après.
 
Mais si tu laisses ce dépôt activé (tu peux le commenter, si tu veux le désactiver sans le supprimer complètement), il ne fera ensuite que te proposer les MAJ des paquets qu’il contient et que tu as installés sur ta machine (comme le font les dépôts officiels, en fait), rien de plus. Il ne te fera pas télécharger des paquets dont tu ne veux pas, à l’exception des éventuelles dépendances.
 
Je vois pas vraiment pourquoi tu paniques comme ça, en fait…
 
Sinon, l’alternative, si tu veux pas avoir à ajouter un dépôts à pacman.conf, c’est d’aller justement sur l’adresse du dépôt (https ://repo.archlinuxcn.org/x86_64/, ici), et d’aller télécharger toi-même l’archive du paquet qui t’intéresse (https ://repo.archlinuxcn.org/x86_64/ungoogled-chromium-84.0.4147.125-1-x86_64.pkg.tar.zst, donc). Un coup de « sudo pacman -U /chemin/de/ungoogled-chromium-84.0.4147.125-1-x86_64.pkg.tar.zst » et c’est bon. Mais ça nécessitera d’y retourner à chaque MAJ du paquet…
 
Au passage : Qt4 est abandonné depuis le début de l’année. Donc, à moins que tu aies un logiciel qui en a besoin pour fonctionner (j’en ai un…), je te conseille vivement de le désinstaller sans tarder (non, ça n’a rien à voir avec le fait que la version que tu viens d’installer vient d’un dépôt tiers chinois : s’il appartient à un utilisateur de confiance, il doit être propre).

C'est pas que je panique, mais je fais gaffe à ne pas faire n'importe quoi (c'est pas toi qui m'avait grondé pour reflector ?). Ce que je veux c'est juste avoir ungoogle-chromium sans compiler et qui soit gérè comme les autres softs, c’est-à-dire avec Pamac en général, voir yay. Pas trop m'emmerder pour un navigateur secondaire aussi.
 
Oui j'ai juste commenté pour dé-commenté si besoin.
 
Donc pour Qt4, on m'a proposé une version plus récente qui n'existe pas sur les miroirs que j'utilise d'habitude, pour un soft obsolète. Je l'ai viré.
Ce que je crains c'est ce genre de chose, une version qui n'existe pas sur les dépôts habituels, je ne suis pas assez bon pour savoir quelles en seraient les conséquences.

Ah, ça… Je vois sur AUR que la dernière version de Qt4 en date est la 4.8.7-32 (c’est-à-dire la 32e MAJ du paquet de la version 4.8.7, pour ce qui concerne Arch), sortie le 10 mai dernier. Si tu t’es vu proposer une 4.8.7-33, effectivement, c’est bizarre.
 
Pour Reflector, je crois pas, mais je pense me rappeler avoir dit de ne pas multiplier les miroirs, oui. Vaut mieux en garder un en décommenté dans /etc/pacman.d/mirrorlist.

 
Si tu ordonnes proprement des depots, il est impossible d'avoir une version différente d'un paquet sur les depots officiels (par contre un absent comme Qt4 oui).
 
Apres pour le 4.8.7-33 ce n'est pas forcement bizarre, les depots secondaires de ce genre n'offrent pas toujours des paquets qui proviennent d'aur, parfois ils ont leur propre paquet. Bon par contre la dernière mise a jour sur archlinuxcn est aussi du 10 Mai... Peut-être est-ce une difference pour aller avec les autres paquets de ce depot?

Oui c'était Qt4 4.8.7-32 et il y avait bien une version 33 sur le dépôt chinois.
J'en ai plus besoin, il était nécessaire pour un petit soft qui existe en qt5, donc je l'ai remplacé.
 
Donc a priori, ça devrait aller avec pacman.conf, je vais pouvoir laisser dé-commenté. c'est cool

J'ai encore un souci avec la gestion bizarre des diférents packages Eclipse dans AUR : je ne peux pas mettre à jour eclipse-jee, ça me dit que tous les fichiers sont déjà présents dans le système de fichier...

Ha bnah c'est bon, il fallait désinstaller eclipse-common et eclipse-jee à la main avant de réinstaller seulement eclipse-jee...

J'avais eu le même problème avec eclipse-java qui me disait que les fichiers étaient utilisés par eclipse-common

Au final ça s'est résolu avec un clean build de eclipse-java  

N'oubliez pas les solutions alternatives telles que l'installateur officiel d'éclipse ou l'extraction d'un gros zip dans le home :
https://www.eclipse.org/downloads/packages/installer

elles sont parfois plus pratiques et plus simples que les paquets AUR d'archlinux, tout s'installe dans le home sans polluer le /usr/bin et /usr/lib.

L'utilisation d'un zip permet d'avoir plusieurs installations/versions d'eclipse sur son PC, car une version récente d'éclipse n'est pas toujours la meilleure solution par rapport au projet surlequel on travaille.

À voir aussi les éventuelles solutions de type appimage, flatpak, docker, si des images existent pour eclipse.

Problème de mise à jour du paquet calibre :

- pacman va proposer de remplacer calibre-common par community/calibre, j'ai répondu "oui"
- puis lorsqu'il va desinstaller calibre-common il y aura cette erreur :

Le problème vient du fait que dans une fonction post_remove il y a une commande "rm" qui tente de supprimer le dossier /usr/lib/calibre, mais l'option "-rf" n'a pas été donnée à la commande rm, ce qui fait que la commande échouera si le dossier /usr/lib/calibre n'est pas vide.

Le plus simple, pour contourner ça en attendant une version corrigée du PKGBUILD, ce serait de désinstaller soi-même Calibre, puis installer la nouvelle version ensuite. Plus de problème de répertoire non vide ne pouvant être supprimé, dans ce cas.

J'ai crée un rapport de bug sur archlinux, mais le créateur du paquet calibre refuse de croire qu'il y a un problème, il a fermé très vite le rapport de bug avec la mention "not a bug", l'impression qu'il veut cacher la poussière sous le tapis.

Sur d'autres bugzilla ils laissent le temps aux utilisateurs de répondre, là sur archlinux ça ferme immédiatement le rapport de bug dès que le packageur a posté son avis, pas de possibilité de poster un commentaire supplémentaire lorsque le ticket est fermé, c'est un aspect assez frustrant dans le système de tickets d'archlinux, ça n'encourage pas la création de rapport de bugs et la discussion avec l'auteur du paquet.

Sur celui du kernel linux même si le ticket est fermé tu peux continuer à poster des messages, des infos, voir même réouvrir le ticket.

L'explication d'Eli ne me parait pas mauvaise.

Il y aurait moyen d'améliorer son script bash pour éviter l'erreur,
en vérifiant que le répertoire qu'on veut supprimer ne contient pas de fichiers, s'il y en a alors supprimer d'abord les fichiers, puis ensuite le répertoire vide, ou encore plus simple : utiliser l'option "-rf" avec rm.

Un truc tout bête de type :

plutôt que ce code qui peut potentiellement planter :

tu vires l'instruction if et la commande "rmdir", tu remplaces tout ça par un unique "rm -rf" qui va virer le répertoire /usr/lib/calibre et les sous-répertoires qu'il y a à l'intérieur, y compris les fichiers, et grâce à l'option "-f" même si le répertoire /usr/lib/calibre n'existe plus alors ça ne générera pas d'erreur.

Je crois que justement il ne veut pas enlever des fichiers qu'il n'attend pas et préfère laisser cela a l'administrateur.

Ça n'a pas trop de sens dans le cas d'une désinstallation de paquet, s'il y a des fichiers rajoutés par l'utilisateur dans un dossier du paquet (ce qui ne devrait jamais arriver) alors tant pis pour l'utilisateur, une desinstallation c'est : tu vires tous les fichiers du paquets, y compris les fichiers "clandestins" qui se seraient immiscés dans les dossiers du paquet (/usr/bin/<nom du paquet>, /usr/lib/<nom du paquet>, /var/<nom du paquet> etc...).

Quand un utilisateur fait une désinstallation du paquet il s'attend à ce que tous les dossiers parent crées par le paquet dans "/usr" soit supprimés, l'objectif étant de revenir à une situation d'avant l'installation du paquet.

S'il y a vraiment besoin d'informer l'utilisateur d'une anomalie : tu fais une commande "echo "attention fichiers clandestins trouvés" dans le post_remove(), tout en faisant en sorte que le code dans la fonction post_remove() ne plante pas quand un scénario précis se produit, il doit être robuste.

Dans le cas d'une désinstallation ca me parait plus que correcte, pour une purge totale la je serais d'accord avec virer tout (ce qui en effet nécessiterait un changement du script).

Le but d'avoir un système de packages c'est justement de pas a avoir à exécuter des "rm -rf /usr/lib/package" à la désinstallation.
 
Je connais pas le package en question mais le vrai fix serait probablement de comprendre pourquoi il y a des fichiers hors package dans le répertoire d'installation, pas d'ajouter un hook en post-remove pour faire le ménage

Oui c'est pas faux, bizarre ces rm dans une fonction post_remove(),

un packageur (les paquets AUR) malintentionné ou distrait pourrait faire des dégâts, à moins qu'il y ait un filet de sécurité dans pacman (par exemple empêcher les rm qui ciblerait des dossiers parents qui n'appartiennent pas au paquet ?)

C'est une très bonne question, je suis curieux de la réponse.

En tout cas s'il s'agit de trouver un lien symbolique, ce serait mieux de faire

Dites les pros, je voudrais installer Arch sur ma machine principale qui est full Windows 10, en dual boot avec Win 10. Sauf que j'ai très peur de la gestion de l'UEFI et du gestionnaire d'amorçage, j'ai pas envie de faire n'importe quoi et de me retrouver incapable de booter mon Windows ou quoi que ce soit, parce que j'aurais fait une connerie lors de l'install du bootloader.

Du coup je me demandais s'il était possible d'installer Arch sur une partition d'un disque secondaire, et d'installer le bootloader seulement sur ce disque là (quitte à débrancher tous les autres lors de l'installation), pour qu'il ne voie même pas que WIndows existe, je veux qu'ils se foutent la paix et surtout ne se mélangent pas ; je ne veux pas que mon installation de Linux écrive quoi que ce soit dans la partition de boot WIndows / EFI, et l'idéal serait de simplement changer l'ordre de boot des disques au démarrage lorsque je voudrais lancer Arch (et de rechanger quand je voudrais booter Win 10), c'est possible ou pas ?

Si tu es en EFI, la procédure de boot lis la partition EFI qui contient ce qui peut être boot  
 
Donc non je ne vois pas comment tu peux empecher une écriture sur la partition EFI.
 
Ce que j'avais fait moi :  
1) Install d'arch classique (via le tuto de fred bezies)
2) Consulter les articles suivants :  
https://wiki.archlinux.org/index.ph [...] _partition
https://wiki.archlinux.org/index.ph [...] _Interface
https://wiki.archlinux.org/index.php/Arch_boot_process
3) J'ai utilisé en bootloader :
- Grub : pas de différence avec une install "BIOS", menu de boot à chaque boot
- Refind : idem
- Systemd-boot : j'ai préféré celui là au final car il n'y a aucun menu au boot, le pc démarre sur l'entrée UEFI qui est définie par défaut (Win ou Arch au choix) et pour changer, il suffit d'utiliser le menu de boot de l'UEFI (F9 sur les pc HP par exemple).
 
Edit : A noter qu'il n'est pas nécessaire d'avoir 1 partition UEFI par système (même si techniquement faisable) ... 1 seule partition partagée entre les OS suffit amplement.

Merci de ta réponse, je vais réfléchir car je ne suis pas super chaud d'installer un dual boot sur cette machine qui est ma plus "sensible", avec un Bios classique ça n'aurait pas posé trop de problème, mais l'UEFI j'y comprends rien donc j'ai pas envie de faire de connerie.