Reprise du message précédent :
En meme temps avec une 4xxx tu ne demandes pas grand chose
 
Mais pour le reste, en tant que fidèle de Saint IGNUcius, je ne tourne qu'avec de l'AMD depuis les débuts de radeonhd.

Bon, bin j'affirme que Pacaur c'est mieux que Yaourt.
 
J'obtenais une erreur à la compilation de kodi-git avc yaourt, ça passe nickel avec Pacaur.

Et merde : http://www.phoronix.com/scan.php?p [...] -DC-DRM-No
Ca change tout

quelqu'un peut résumer le problème ?

pas tout compris dans l'article, que signifient les initiales DAL et DC ?

AMD publie le code kernel de son dernier driver pour l'inclure dans linux mais ça ne convient pas aux mainteneurs donc ça se fera pas (en l'état).
 
Ça bloque pas mal l'avenir des pilotes libres AMD.

 
Et ça ne convient pas parce qu'il y a une énorme couche d'abstraction afin qu'AMD puisse avoir un pilote commun avec d'autres OS (windows notamment), ce qui pose problème parce que ce genre de chose rend très difficile le partage de code entre pilotes linux ainsi que les grosses évolutions futures. La réponse est complètement dans la politique habituelle du noyau.

 
Bof, si tu lis les commentaires de bridgman, AMD/Mainteneurs Kernel trouveront une solution quoiqu'il arrive.

Oui, la réponse est sensée
 
 

Voilà, AMD était parfaitement au courant que leur code ne serait pas upstreamé en l'état, c'est simplement un quiproquo (une RFC qui a été interprétée comme un demande de merge) qui a aboutit à une engueulade entre développeurs : open source drama = gros titres sur Reddit et sur Phoronix...
 
Les commentaires qui rétablissent la vérité :
 
https://www.reddit.com/r/Amd/commen [...] s/db0hf4p/
https://lists.freedesktop.org/archi [...] 26698.html

Ce que je vois surtout c'est que ce merge va pas se faire dans un futur proche... y aura bien encore 3 ou 4 kernels sans. ( )  
Donc moi qui comptait dessus pour choper la future rx 49x et tourner full libre sous peu, je vais me renseigner sur l'état de nouveau pour les GTX 10xx...

Bah, il faudra tourner avec un noyau non officiel. M'enfin, ça fait un chier, voire beaucoup.
Néanmoins, techniquement, je ne vois pas de raisons à aller chez n'vidia, les cartes AMD sont toujours un peu plus "libres".

Et pour revenir plus haut les DRM intels sont présents dans le kernel 4.9 donc il ne devrait plus trop y avoir de problèmes avec skylake

Ou tourner sur leur module fermé en attendant l'inclusion... mais on connait la lenteur légendaire d'AMD pour sortir les mises à jour de leurs blobs (kernel, DDX..)
Je vais demander des retours d'XP sur les cartes nvidia récentes avec nouveau sur le topac linux. Si certains connaissent le sujet, venez y faire un tour

Si DAL/DC compte pour toi, tu peux toujours patcher ton kernel en attendant, ca ne prend pas tellement de temps avec les machines actuelles, et ca ne m'etonnerait pas que ca soit deja sur aur.

Xorg 1.19 est enfin dans testing, mais a priori il y a des soucis avec les vieux pilotes nvidia (300 et 340 ou un truc du genre).

Bin depuis le passage en Xorg 1.19 ma souris est trop rapide, et la régler dans le module KCM de Plasma n'y change rien, c'est chiant.

essaie de court-circuiter le module kcm de plasma en passant directement par un fichier de configuration de xorg :
 
https://wiki.archlinux.org/index.php/Mouse_acceleration
 

A tous les coups tu es passé avec le driver libinput pour ta souris et KDE sais pas configurer ce driver.
Repasser sur evdev est peut-être le plus simple.

j'aimerai savoir si vous avez un message d'erreur lorsque vous tentez d'ouvrir un fichier PDF avec gimp ?

je pense avoir détecté un bug de packaging dans le paquet gimp archlinux, le paquet "poppler-glib" aurait dû être une dépendance obligatoire pour gimp mais dans le PKGBUILD de gimp ce paquet est déclaré comme optionnel,

or gimp a été compilé avec le plugin PDF activé par défaut, ce plugin a besoin de la librairie poppler-glib, du coup dans la console quand on lance gimp et qu'on veut ouvrir un fichier PDF on a ce message :

j'ai ouvert un rapport de bug sur le site d'archlinux pour demander que le paquet poppler-glib soit une dépendance obligatoire pour gimp mais un modérateur a consideré que ce n'était pas un bug et a fermé mon rapport sur le champ  

ce modérateur ne voit aucun inconvénient à ces 2 messages d'erreur, je lui ai suggéré qu'il serait beaucoup plus "propre" de fournir un paquet gimp sans le plugin "pdf" ( pour éviter les messages d'erreur ) et de fournir ensuite un paquet optionnel "gimp-pdf-plugin" qui fournirait le fichier /usr/lib/gimp/2.0/plug-ins/file-pdf-load et installerait le paquet poppler-glib mais il n'a rien voulu savoir,

j'ai déjà eu affaire dans le passé à ce modérateur, quelqu'un d'un peu cassant/hautain et pas très diplomate sur le site archlinux, mais je lâche pas l'affaire : j'ai contacté par mail directement l'auteur du paquet gimp pour avoir son avis sur cette manière de packager gimp

Pas de problème chez moi puisque j'ai cette lib d'installée, obligatoire pour d'autres usages. Apparemment ce ne serait pas nouveau : https://bugs.archlinux.org/task/29753
 
Pour ceux que ça intéresse : J'ai pu tester des machines avec du nvidia sur pc portable. Les 960m hybrides sur asus gl552 c'est une catastrophe, le bios n'a jamais la même configuration. Par contre une gtx 1060 sur gl502, ça passe sans soucis. Le package nvidia 375 sous archlinux n'est pas fonctionnel à l'heure actuelle : les applications opengl ne fonctionnent pas avec ! Sur les dépôts manjaro, le package nvidia est encore à la 370 dans les dépôts manjaro ce qui résout les problèmes

 
ok, merci d'avoir fait la recherche, je ne suis donc pas le premier à trouver bizarre ce type de packaging ( fournir délibérément des binaires avec des librairies manquantes )
 
c'est assez crade comme procédé, laisser des erreurs de type "cannot open shared object file: No such file or directory" ça me choquerait si j'étais packageur, pour bien faire il faudrait compiler le paquet en spécifiant dans le "./configure" qu'on désactive certaines fonctionnalités, ou encore déporter certains plugins dans un paquet optionnel

En gros il faudrait aller sur chaque package et regarder ce qui est optionnel. C'est vrai c'est plus que moyen !
Il est listé deux fois ici : https://www.archlinux.org/packages/extra/x86_64/gimp/ make et optionnel !
 
Et ici en required by gimp : https://www.archlinux.org/packages/ [...] pler-glib/
 
Pour ce package là ça ne me dérange pas trop vu que j'utilise atril mais ça fait peur concernant d'autres paquets ...

C'est le PB d'une distribution binaire. Soit tu as 50 versions avec les différentes possibilité de plugin. Soit tu as une version compilée sans rien, et à charge de l'utilisateur de recompiler les plugins qu'il veut, soit tu fais un compromis: tu compiles les plugins mais tu ne forces pas l'utilisateur  à les utiliser. Et dans ce cas là ben t'as le problème sus cité.

La situation actuelle me parait meilleure que celle que tu proposes:

Ici il y a des messages d'erreurs mais qui au final ne sont pas plus embêtant que des messages d'attentions.
L'utilisateur qui veut cette fonctionnalité installera la librairie qui va bien.
Avec ta solution, il devra recompiler le paquet, après avoir tout de meme installé la librairie.
Je ne vois pas ce que ca apporte, sauf si ca change la taille du paquet suffisamment.
Je pense que c'est la le principe des dépendances optionnelles.

Passer le support de la librairie dans un second paquet est propre, mais hélas pas toujours faisable.

Je pense que c'est dans le code de gimp qu'il faudrait rajouter quelque chose pour désactiver les fonctionnalités manquantes quand les librairies ne sont pas disponibles.

en fait la solution que je préconise pour le cas gimp :

- soit ajouter comme dépendance obligatoire poppler-glib : ça ne prend que 2 méga-octet supplémentaire à l'utilisateur pour l'espace disque

- soit compiler gimp avec toutes les options, puis ensuite déplacer les plugins jugées optionnels dans des packages séparés ( genre "gimp-pdf-plugin", "gimp-toto-plugin" etc... ), et mettre ensuite ces paquets dans la catégorie "opt-depend" du PKGBUILD

le cas actuel est assez crade comme situation puisqu'il entraîne un message d'erreur dans la console mais aussi surtout au niveau de l'interface graphique de gimp,  l'utilisateur va pas aimer et croira à un bug de gimp alors que ça vient du packageur archlinux :

il faudrait regarder comment ont fait les autres distributions pour packager gimp ( debian, ubuntu, fedora ), pour ubuntu et debian le paquet libpoppler-glib8 est indiqué comme dépendance obligatoire dans la liste des fichiers et le plugin pdf est fourni :
http://packages.ubuntu.com/yakkety/gimp

- Tu oublies que poppler-glib depend de poppler
  Apres c'est surement plus un soucis théorique que pour ce paquet exactement.
 
- Pas dit que ca soit faisable facilement.

poppler ne fait que 4 Mo

sinon je viens de tester le fait de supprimer le fichier /usr/lib/gimp/2.0/plug-ins/file-pdf-load --> ça fonctionne, gimp ne se plaint pas d'un plug-in manquant, la possibilité de charger un fichier PDF est alors retirée de la liste déroulante "fichiers", aucun message d'erreur dans la console,

donc on pourrait théoriquement créer un package pour chaque plugin qu'on souhaite déporter,

sinon il faut faire comme ubuntu/debian : ne pas se prendre la tête et tout donner à l'utilisateur niveau plugins, la version originale/intégrale de gimp, afin de respecter la vision de l'auteur de gimp

Ca a l'air parfait comme cela

Linux 4.8.15 est sorti et on n'a toujours pas 4.8.14 dans testing
(Ne parlons pas de 4.9)

Sous Manjaro, ils sont présents  
 

Oooh je croyais que les paquets de Manjaro venait d'Arch.

Manjaro a un dépôt spécifique pour certains paquets particuliers : tout ce qui est thèmes de fenêtres et d’icônes, et sans doute aussi le noyau, puisque ce dernier est étiqueté « *-MANJARO » et non pas « *-ARCH ».

 
malheureusement le modérateur du bugzilla ne l'entend pas de cette oreille, je balance son nom : Doug Newgard ( aka Scimmia ), j'ai envie de le baffer  
 
j'ai tenté une réouverture de mon rapport de bug en lui expliquant qu'il existe une manière beaucoup plus propre de packager gimp, et que les autres distributions linux mettent bien poppler-glib comme dépendance obligatoire,  
rien à faire, il a quand même fermé le rapport de bug, avec un laconique "not a bug", et il ne répond pas sur le fond du problème,
 
pour moi ça reste un bug et un mauvais packaging dans la mesure où la fonctionnalité "plugin-pdf" de gimp entraine un message d'erreur brutal "plugin crashed" dans l'interface graphique, vu l'absence de poppler-glib,
 
ce qui est enervant c'est qu'il ferme le rapport de bug alors que l'auteur du paquet gimp n'est même pas encore au courant de l'existence de ce rapport de bug, ce Doug se permet de décider à la place du packageur  

Ce n'est pas parce qu'il n'a pas le même point de vue qu'il faut s'énerver.
 
Ce genre d'erreur est le propre des opt-dep pour les packages binaires.
 
Je ne sais pas combien de plugins a Gimp, mais s'il y en a beaucoup, l'approche que tu proposes, bien qu'intéressante devient vite non maintenable.
 
Pour le coup, quand tu installes Gimp, tu SAIS que tu dois installer poppler-machin pour utiliser le plugin, donc le packager a fait son travail.

si le packageur avait vraiment bien fait son travail alors il aurait mis "poppler-glib" dans la rubrique "depends" et non pas dans "optdepends", le combo poppler + poppler-glib ne prenant que 6 méga-octets d'espace disque,
ouvrir et enregistrer l'image au format pdf fait partie des fonctionnalités de gimp, le cheminement intellectuel qui a poussé ce packageur à exclure poppler-glib ( tout en gardant le plugin pdf dans le paquet    ) me semble incompréhensible,

j'ai déjà crée des paquets archlinux ( pour usage perso ) et je peux te certifier que sa façon de faire est crade et pas justifiée ( il a de la chance que gimp n'ai pas planté quand il n'a pas trouvé la librairie poppler, dans bien des cas un "can not load shared library" est sanctionné par un arrêt du logiciel ),

ce Doug Newgard ayant clôturé le bug-report je n'aurai jamais la réponse du packageur de gimp sur ses motivations

Comme dit au dessus c'est 6Mo pour ce couple, mais quid des autres optdepends? Par exemple ghostcript...
Et puis si tu as cela, moi je veux mon mpv avec support de vapoursynth (bon pour mpv et VS il faut recompiler mpv donc c'est un peu different...), et d'autres demanderont d'autres trucs.. et on en finira jamais.

Bien que ca ne soit pas la façon habituelle de faire, tu peux toujours tenter d'envoyer un email/mp au mainteneur, ou un email sur une liste d'Arch.

Je crois que c'est la sa fonction sur Arch, de filtrer les trucs qui arrivent aux mainteneurs, afin qu'ils aient plus de temps pour les trucs importants et moins pour les trucs inutiles.

Les drivers proprio aussi sont différents. Chez nvidia, on est à la 370.x alors que sous Arch c'est la 375.x buggy

Il n'y a pas que le tranchant qui est saignant.

Vu ça sur Reddit :  
 
https://i.redd.it/dblkxmj0ix4y.png

Un manchot qui fait du delta plane?

 
Hop, résolu en créant un fichier /etc/X11/xorg.conf.d/50-mouse-acceleration.conf dans lequel j'ai mis ça (profil d'accélération "flat" pour libinput) :
 

 
cf : https://wiki.archlinux.org/index.php/Mouse_acceleration