Reprise du message précédent :
pour ceux qui sont passés à plasma 5 : est-il possible d'installer et d'executer un logiciel 100% KDE4 dans plasma 5 ?

par exemple le logiciel kaffeine qui permet de regarder des vidéos et la télé depuis une carte tuner :

https://www.archlinux.org/packages/ [...] /kaffeine/

essayez  un "pacman -S kaffeine" sans valider à la fin juste pour voir si un conflit est détecté,

à noter qu'il n'existe pas de version KF5 de kaffeine

Oui les applis KDE4 marchent sans probleme.
 
Je viens de tester, j'ai pas de conflit pour kaffeine.

ok, bonne nouvelle, car j'avais peur de ne plus pouvoir utiliser kaffeine lorsque je migrerai vers plasma 5, car toujours pas de version KF5 et le developpement de cette application est au ralenti ( 4 années séparent la version 1.3 de la version 1.2 ),

c'est le seul qui soit vraiment orienté "user-friendly" avec une interface claire et des fonctions proches de "pouchintvmod" ( logiciel windows ), les autres sont moins faciles à prendre en main ( vlc, smplayer, mplayer ) en ce qui concerne la visualisation de chaines de la TNT et son enregistrement,

à noter que la version 1.3 bogue beaucoup et qu'il est préférable d'utiliser la version 1.2 en utilisant ce site pour remonter dans le temps :

ftp://seblu.net/archlinux/arm/2015/

attention si vous utilisez samba, un bug empêche le lancement de la version 4.3.0-1

https://bugs.archlinux.org/task/46240
https://bbs.archlinux.org/viewtopic.php?id=202204

solution : taper en root la commande : "chmod 755 /var/cache/samba/msg"

bug important non détecté par les auteurs de samba qui empêche d’exécuter les démons samba ( nmbd et smbd )

Attention
 
Un nouveau ncurses est dans testing et arrivera surement bientot dans core, celui-ci m'a bien mis en rade ma machine et au reboot plus de DRI, plus de mpv etc..
Mon probleme vient surement du fait que j'utilise des pilotes qui viennent de repos non-officiels, mais si d'autres font pareil, je prefere prevenir!

Quel rapport avec ncurses ?

A vrai dire je n'en sais rien, mais meme Xorg.log.0 evoquait ne pas pouvoir ouvrir l'ancienne lib ncurses (qui n'etait donc plus la).

Je comprends pas pourquoi c'est lié à ncurses, mais dans tous les cas c'est toi qui as déconné. Tu as des drivers externes, c'est à toi de les recompiler si leurs dépendances subissent un bump.

Aucune dependance directe, c'est indirecte (enfin j'imagine), donc pas de mise en garde de pacman...

Ce n'est pas la rôle de pacman ! Quand tu décides de passer par des packages maison ou externes, tu dois gérer ça toi même. pacman ne sait pas faire et n'a pas à faire cette vérification.
Et je ne parle pas de dépendance au niveau du package, mais au niveau binaire.
 
Essaie d'invoquer ldd sur tes drivers /usr/lib/xorg/modules et /usr/lib/xorg/modules/dri, idem sur la libgl, etc... tu verras les dépendances. Si elles deviennent non résolues, tu dois recompiler.

Ah en effet, je n'avais pas pense a ldd, bien vu!

Comment controles-tu cela?
Je n'arriverai jamais a me rappeler de toutes les dependances binaires de mes paquets... Y'a-t il des scripts pour cela?
Je veux dire afin de pouvoir savoir cela avant d'installer la mise a jour.

Arch fait justement partie de ces distro qui ne versionnent pas les dépendances (sauf quelques exceptions) donc tu as pas vraiment moyen de le savoir... Sauf à vérifier manuellement ou dans un script, ou dans ta tête

Hmmm, donc je ne peux me faire qu'un script de reparation (genre qu'est ce qui depend de XXX et qui n'est pas mis a jour).
Je vais tenter cela avant que je remette a jour, car konsole sans kwin, c'est sympa, mais pas evident pour utiliser un navigateur et debogger en meme temps.. L'heure de gloire de lynx peut etre?

La théorie c'est que tant que tu fais des -Syu complets, tout est toujours cohérent et compatible entre les packages et leurs dépendances dans les repos officiels. En théorie les devs te le garantissent (sauf rares ratés ou sur testing)
Si par contre tu as des packages externes dont les versions ne sont pas contrôlées car non officiels, ça pétera un jour ou l'autre puisqu'ils sont en dehors du contrôle "centralisé" des repos.
 
Donc si l'ABI casse, faut recompiler toi-même.
 
Tu peux effectivement faire un script qui itère sur les packages externes (-Qm) , extrait la liste des binaires de chaque package (-Ql + file) et vérifie que tout est bien lié avec ldd par exemple...
Ou peut-être jouer avec namcap, il doit savoir détecter ça je pense, à voir si c'est applicable.
 
Ou bien réparer ça en tty à posteriori (le moins chiant IMO ) et surtout minimiser le nombre de packages externes...

J'ai pas mal de paquets externe (ou maison...) mais tant que c'est un truc sans importance ca se repare facilement (genre mpv), la j'ai l'impression que presque tout l'OS depend indirectement de ncurses..

Ca m'étonne beaucoup quand même pour ncurses...
Tu as la sortie de ldd sur tes drivers qui sont linkés avec ?

voila un example, derniere ligne:

Question (bête sûrement) : Mesa 11.0, c'est pas encore dans les dépôts ? C'est pas la version extra/mesa 10.6.7-1 ?

On dirait que pas encore.

OK, merci.

Pour connaître l'état du repo master c'est sur la page d'accueil d'arch hein

(Merci C'est ça ? https://www.archlinux.org/packages/?sort=-last_update )

Oui c'est ça, et tu vois que quelqu'un l'a déjà taggé comme périmé.  
La 11 arrivera probablement dans testing d'abord puis passera dans extra.

Salut,
 
J´ai un soucis de transfert USB lent avec des clés USB 2 ou 3. Quand je transfert des fichiers entre ~400Mo et ~1,5Go, la barre de transfert monte vite puis bloque pendant plusieurs minutes, voir dizaines de minutes.  
 
J´ai créer un fichier /etc/tmpfiles.d/local/conf comme dit ici : https://wiki.archlinux.org/index.ph [...] ge_devices. Par contre, à part devoir créer le fichier, il n´y a rien d´autre à faire pour le « mettre en service » ?
J´ai réglé vm.dirty_ratio et vm.dirty_background_ratio comme dit ici : https://wiki.archlinux.org/index.ph [...] ual_memory, il y a du mieux, plus de gros blocages, mais les transferts commencent à ~20Mo/s et déclines jusqu´à ~12Mo/s, alors que sous W7 ça tourne plutôt à 30Mo/s constant.
 
Vous avez une idée ?

Donne la sortie de mount quand ta clé est (auto?)montée.
La vitesse changeante fait penser à du cache qui délire, et comme tu as joué avec le writeback, ça me semble possiblement lié...

 
Le problème était présent avant que je touche quoique ce soit. D´ailleurs vm.dirty_ratio et vm.dirty_background_ratio étaient au double de ce que le wiki annonce ; respectivement 20 et 10.
 
Voici la sortie de mount quand je monte une clé (insertion > visible dans thunar > clic dessus pour la monter)

 
La ligne interessante est celle-ci non ?

concernant la copie de fichier entre un périphérique lent ( clé usb ) et un périphérique rapide ( disque dur ) il me semble qu'il y a une subtilité sous linux :

- le taux de transfert indiqué dans la petite fenêtre ( par exemple le truc de KDE qui donne la vitesse de transfert ) ne correspond pas à la réalité, car il y a une histoire de copie en cache mémoire qui fausse la barre de transfert ( pas sûr à 100% )

en réalité le transfert est beaucoup plus lent ( car clé USB 2.0 = périphérique lent, surtout en écriture, genre 1.5 Mo/sec pour les clés USB 2.0 les moins performantes ), il se produit alors un malentendu : l'utilisateur voit dans son interface graphique que le fichier a été copié ( explorateur de fichier, barre de progression qui donne l'impression que l'opération est terminée ), mais en fait c'est pas le cas, le transfert continue toujours ( led de la clé USB qui clignote ),

on s'aperçoit du problème lorsqu'on veut démonter la clé, un message d'erreur apparait "impossible de démonter la clé, une opération est en cours", il faut alors patienter, surtout si le fichier à copier était de taille importante ( plusieurs centaines de méga-octets ),

en gros "it's not a bug, it's a feature", le monitoring de la vitesse n'est pas fiable quand un des deux périphériques est trop lent, le seul indicateur valable c'est la led de clignotement de la clé USB et du disque dur

Oui.
Le flush c'est toi qui l'a ajouté ?
Si tu montes la clé à la main avec toutes les mêmes options sauf le flush, ça donne quoi ?

C'est vrai que c'est chiant ce comportement, je me suis jamais penché dessus mais ça me semble quand même pas terrible, ca fait pareil sur les montages réseau
iostat ou nmon donnent de bonnes infos si nécessaire.

 
Non, je n´ai rien touché des options de montage, c´est thunar qui doit s´en occuper tout seul je pense.
Donc en faisant sudo mount -o rw,nosuid,nodev,relatime,uid=1000,gid=100,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,errors=remount-ro,uhelper=udisks2 /dev/sdc1 /media/win, ça ne change rien. Au début du transfert d´un fichier de ~1Go, ça commence à ~200Mo sans vitesse d´affichée, puis à environ 400Mo j´ai une vitesse qui s´affiche ( ~70Mo/s) et qui chute jusqu´à ~10Mo/s. J´ai chronométré un temps de transfert de 55s, soit ~18Mo/s.
(Attention, avec les modifs du wiki, ça va beaucoup mieux que avant hein (ça devait mettre 5min/Go), c´est juste que ce n´est pas aussi rapide que sous W7 et c´est bizarre je trouve.)
 
Autre chose, qui n´est peut-être pas en rapport : le dongle de ma souris est branché sur le hub USB3 de mon écran ; quand je mets une clé USB sur l´écran et que je copie, la souris lag. Je comprends bien que c´est « normal » car ça passe par le même câble, mais une souris ça ne doit pas utiliser beaucoup de « bande passante ». Ça veut dire que les données passent alternativement par le câble ? (paquets données copiées, paquet souris, etc.)
 

 
Ça fait quinze plombe que ça me le fait sans que je ne m´en soucie mais là j´ai craqué, d´où mes recherches et maintenant mes questions  

Ah
Moi j'ai pas ce problème (je l'ai avec les transferts réseau par contre )

Essaie un autre port, ça ne devrait pas faire ça !
Oui l'USB fonctionne par adressage sur un bus, donc avec des paquets comme tu le décris

...

 
J´évite de brancher directement sur l´écran du coup ; je branche sur les ports de façade de la tour, mais ce n´est pas pratique vu comme mon bureau est fait.

il suffit d'acheter une rallonge USB, tu la brancheras sur un des ports USB arrière de ton PC, puis tu plaques l'extrémité USB du câble sur le rebord de ton bureau pour faciliter l'accès quand tu brancheras un périphérique USB,

sinon aujourd'hui en faisant un "pacman -Syu" vous aurez probablement cette erreur :

https://lists.archlinux.org/piperma [...] 39844.html
https://bbs.archlinux.org/viewtopic.php?id=202562

à priori un défaut lié à la manière dont les mises à jour sont faites, bash et ncurses qui sont mis à jour en même temps alors que c'est encore l'ancienne version de bash qui est utilisée quand on lance cette commande pacman -Syu, bash ne sera pas au courant que la librairie ncurse a été mise à jour puisqu'on a pas encore relancé la nouvelle version de bash ( qui est liée à la nouvelle version de ncurse ), il ira chercher la mauvaise version ( 5 au lieu de 6 ),

Ah les couillons
Ceci dit vu le modèle de versionnement des libs et le Rolling Release, c'est difficilement contournable.

attention il y a un problème avec la dernière version du paquet lirc arrivée dans le dépôt stable ce lundi :

https://bugs.archlinux.org/task/46457

lirc est un paquet pour gérer les télécommandes infrarouges ( carte tuner TV notamment ),

cette version "lirc-1:0.9.3-1" pose 3 problèmes :

- le boot de KDE ( ou gnome ) peut être très lent ( chez moi avec kde 4.x lorsque le bureau est affiché il y a une pause de 30 secondes où il ne se passe rien, comme si KDE attendait la fin du chargement du service lircd )

- quand on redémarre ou quand on arrête le PC systemd affiche le message d'erreur "a stop job is running for lircd" pendant une minute trente

- un utilisateur a remarqué que la gestion de certains boutons est incorrecte avec cette version de lirc

le moyen de contournement que j'ai trouvé est de revenir à la version précédente de lirc ( lirc 1:0.9.2.a-1 )

j'ai trouvé un autre moyen de contourner le problème en utilisant un autre fichier de configuration pour lirc concernant ma télécommande :
 
https://www.mythtv.org/wiki/Winfast_DTV1000_remote
 
on dirait que la version 0.9.3 a un bug quand le fichier de configuration est conçue d'une manière précise,
 
ceci n'est pas normal vu qu'avec la version 0.9.2 le même fichier de configuration n'entraine pas de bugs,  
 
j'ai crée un rapport de bug sur le site officiel de lirc

Ça dort là-dedans !
 
Question aux possesseurs de SSD sous Arch : vous avez configuré quelque chose pour utiliser au mieux le SSD ? Genre un trim, un paramètre dans le fstab, que sais-je encore...

J'ai juste mis les paramètres noatime, nodiratime, et surtout discard sur les partition des SSD, rien de plus

Eventuellement changer le scheduler, mais il me semble que sur le wiki y a tout bien expliqué.

 
Merci, c'est quoi "discard" ?

C'est l'option pour activer le trim automatique