Reprise du message précédent :

Il faut modifier le fichier /usr/share/sddm/scripts/Xsetup et mettre ça à l'intérieur :

Tu relances SDDM et tu auras le bon agencement.

 
 
Je n'ai pas le ondemand de disponible....
 
Visiblement ce serait un problème lié à haswell : https://bugzilla.kernel.org/show_bug.cgi?id=93521

il faudrait désactiver "intel_pstate" qui semble bogué pour ton processeur, afin d'utiliser à la place cpupower et le "ondemand" :
 

 
https://bbs.archlinux.org/viewtopic.php?id=184817
 
pour désactiver intel_pstate il suffit d'ajouter cette option de boot du noyau dans ton gestionnaire de boot comme grub  :
 

 
ça permet alors d'utiliser le classique cpupower avec le ondemand

De retour sur Arch en mode paresseux (antergos+openbox) après quelques années de Windows / Debian.

Posté sur le fil Firefox de la section Windows :
 
Si vous utilisez la version Web de TweetDeck et que vous n'arrivez plus à vous y connecter depuis Firefox, voici comment réparer ça (en attendant que le bug soit corrigé, car je sens que dans quelques versions, l'astuce deviendra impossible à réaliser) :
 
https://twitter.com/jbfavre/status/666688795325112320
 

Bonjour,
 
J'ai installé dernièrement une arch linux pour faire ma propre distribution avec Linux From Scratch.
Ils demandent d'utiliser obligatoirement le kernel 2.6.32 de linux mais j'ai la dernière version qui est beaucoup plus récente.
Est-ce que vous savez comment installer un kernel plus ancien sur un archlinux ? Je peux utiliser la fonction downgrade de Archlinux ?
 
Merci,

archlinux est une distribution de type "rolling-release", elle est conçue de manière à ce que les paquets soient toujours les plus récents possibles,

ça va donc poser problème si tu veux figer une version d'un paquet ou installer une version plus ancienne, car des paquets peuvent exiger une certaine version d'un autre paquet en tant que dépendance,

archlinux c'est un système où il faut respecter le coté "récent, paquets frais", il sera difficile de faire cohabiter des vieux paquets avec des récents si ces paquets sont importants ( bibliothèque du C, xorg, noyau linux etc... )

Il n'y a pas une histoire de kernel stable et du dernier release au choix à installer dans arch

Je comprends mais pourtant dans ce témoignage la personne qui a fait la LFS avait bien la distribution archlinux.
 
http://sixgun.org/forum/viewtopic.php?id=4135

Donc je peux utiliser cette méthode pour installer un kernel pluis ancien et l'utiliser le temps de la LFS ?
https://wiki.archlinux.org/index.ph [...] raditional

Je ne sais pas c'était une question suite à ton interrogation. Je vais chercher il me semble que j'ai vu ça quelque part

Le mieux reste la doc, tu peux choisir ton kernel ici   : https://wiki.archlinux.org/index.php/Kernels

Si ton arch c'est juste le temps de compiler ton lfs, osef complètement de sa version de noyau.

j'utilise encore KDE4 avec des applications KF5,

la conséquence c'est que le lancement "à froid" des applications KF5 ( kate, dolphin, konsole, gwenview ) prennent du temps car les librairies QT5 ne sont pas préchargées par défaut, vu que j'utilise KDE4 ( qui utilise les librairies QT4 ), j'ai comme une impression que le système supprime du cache mémoire les librairies QT5 dès que je ferme une application KF5, d'où la lenteur lorsque je lance 30 minutes après la même application KF5 ( obligation de recharger depuis le disque dur les librairies QT5 ),

est-ce qu'il existe un moyen de forcer le cache mémoire de garder en mémoire les librairies QT5 afin d'éviter ce problème de lenteur ?

je pense que sous plasma 5 ce problème n'existe pas vu que les librairies QT5 sont constamment utilisées par plasma 5, donc tout le temps en mémoire cache, ce qui bénéficie aux applications KF5 ( démarrage un peu plus rapide à froid et à chaud )

Akonadi demarre bien chez vous ? Ça fait un bail que c'est cassé chez moi et je comprends pas comment ça peut marcher ailleurs. Akonadi et mariadb me semblent juste incompatibles

 
Chez moi ça marche, hormis les habituels problèmes de "Ressource Unreachable" récurrents avec Kmail qui m'obligent à faire des "akonadictl restart" de temps en temps.

Par contre ça, je sais pas si c'est normal :
 

 
Je suis passé de ~16 secondes à ~28 secondes pour démarrer, à cause de man-db.service.

akonadi, baloo, man-db.service et update-db.service : ce sont les premières choses que je désactive pour éviter la lourdeur ( lenteur au démarrage ),

pour man-db et update-db comme ce sont des timers on ne peut pas désactiver les services, il faut en fait les masquer ( commande mask de systemctl )

Mais j'utilise(ais) kmail  
Moi mariadbd (mysqld) refuse un des arguments qu'akonati utilise pour spawner le serveur local.
Je peux pas être le seul touché et pourtant je trouve aucune info, je comprends pas. Ou bien tout le monde le désactive, ou n'utilise le backend mysql, je sais pas

J'utilise pas le backend mysql (mysqld n'est pas lance par defaut sur mon ordi) par contre je sais pas ce qu'il utilise a la place

Hum, dans ~/.config/akonadi/akonadiserverrc j'ai pourtant l'air d'avoir mysql de configure...

Ha en fait j'ai un process mysql qui est lance par akonadi:

/usr/bin/mysqld --defaults-file=/home/xxx/.local/share/akonadi/mysql.conf --datadir=/home/xxx/.local/share/akonadi/db_data/ --socket=/tmp/akonadi-xxx.CQBBiU/mysql.socket

Donc chez moi ca marche

mysqld
EDIT: AH l'edit fourbe.
Tiens étrange, il y a pas le "--defaults-file=" qui est l'argument qui fait quitter mon mysqld

EDIT 2: AH bein si en fait il y est (wow je suis bigleux) du coup je comprends pas pourquoi toi ton serveur quitte pas avec une erreur

Tu peux me donner :
pacman -Qo /usr/bin/mysqld
 
et un pacman -Qi de ce paquet ?

Oh ! Mon paquet en testing est une version mineure supérieure (10.1.9).
Ils ont donc probablement viré cette option.
Bon j'ai un rapport de bug à faire en fait

Merci

le dépôt testing c'est le mal

sauf si on accepte d'être cobaye et de prendre conscience qu'on sera parmi les premiers à expérimenter le bug

Si personne n'utilisait testing, tu te plaindrais encore plus de bogs en stable...

Bon, ma copine a définitivement des soucis avec sa clé USB qu'elle utilise pour partager des fichiers entre son PC portable de la maison sous Arch / Plasma 5, et les ordis du collège (elle est prof) qui tournent sous Windows (7, d'après elle).

Déjà, il faut savoir qu'il y a un très vieux bug sous KDE qui fait que parfois (souvent), KDE / Dolphin ne parvient pas à copier des fichiers vers une clé USB. En particulier, si on copie un répertoire contenant des fichiers et des sous-répertoires, soit Dolphin affiche un message d'erreur et ne copie rien, soit il ne copie que les répertoires, mais les laisse vides. On se retrouve donc sur la clé avec le répertoire parent, les sous-répertoires, et AUCUn fichier. Bizarre. Mais en copiant les fichiers uniquement, ça passe...

Ensuite, j'ai tout essayé pour le formatage de la clé : FAT32, NTFS, ExFAT, et bien à chaque fois, elle a des soucis pour faire reconnaitre la clé sous les Windows du collège. Elle me dit qu'elle obtient des erreurs du style "le système de fichier comporte des erreurs...", et elle ne peut pas ouvrir ou  modifier les fichiers sur la clé.

Je précise que ce n'est pas la clé qui a un problème, elle est neuve, elle fonctionne très bien sur MON Windows 10 à moi, et elle avait déjà des problèmes similaires avec son ancienne clé.

Du coup, je sais pas bien quoi faire. Déjà, lui faire utiliser un autre navigateur de fichiers que Dolphin, pour la copie de fichiers, ça aide, on ne trouve pas le bug de copie. Ensuite, le fait que la clé semble fonctionner correctement sur mon Windows me fait penser qu'il y a un problème ou une mauvaise configuration sur ceux du collège. Mais bon, moi je peux pas aller y jeter un oeil...

Vous avez des expériences comme ça, de problèmes de "cohabitation" (ou co-utilisation) de clés USB entre un Linux et un Windows ? Et si oui, d'éventuelles solutions ou astuces (par exemple, quel est le format de fichier le plus "sûr", même si je pense avoir tout essayé) ?

il est possible qu'il n'y ait pas de bugs, mais plutôt une erreur "interface utilisateur", ta copine qui fait le barbare avec la clé USB  

car il y a une subtilité sous linux quand on copie des fichiers vers une clé USB :

--> une histoire de cache mémoire qui fait que l'utilisateur a l'impression que la copie de fichiers est terminée en un temps record ( barre de progression à 100% dans la petite applet graphique de KDE pour la copie de fichiers ), mais en réalité la copie continue encore ( c'est lent une clé USB 2.0, genre 1 à 5 Mo/sec si plein de petits fichiers à copier avec plein de répertoires ),

du coup l'utilisateur risque de retirer la clé comme un barbare ( sans passer par l'étape du démontage de la clé --> le lien "retirer la clé en toute sécurité" ) alors que la copie n'est pas encore terminée ( led de la clé USB qui clignote ), le système de fichiers sera alors corrompu par la faute de l'utilisateur,

sous windows il n'y a pas ce problème je crois, quand windows annonce "copie terminée" la copie est vraiment terminée sur la clé USB, sous linux les interfaces graphiques pour la gestion de copie de fichiers peuvent induire en erreur l'utilisateur avec la barre de progression déjà à 100%,

à noter que si on tape la commande de copie dans une console ( "mv", "cp" ) on a pas ce souci car le prompt redevient disponible que si la copie est finie,

j'utilise KDE4 et j'ai remarqué que même après avoir eu l'autorisation de retirer la clé ( je clique toujours sur l'icône permettant de démonter proprement la clé ) la led de ma clé continue de clignoter pendant encore 3 secondes, signe que la copie continue encore malgré le feu vert de KDE4

il faut donc passer sur le grill ta copine pour savoir comment elle s'y prend quand elle utilise une clé USB, est-ce qu'elle passe par l'icône "retirer la clé en toute sécurité" ou bien est-ce qu'elle arrache la clé du port USB dès quand elle a le sentiment ( erroné ) que la copie est finie ?

Normalement, elle démonte bien la clé avant de la retirer, elle utilise l'icône d'éjection. Elle sait qu'il faut faire ça. En revanche, c'est possible qu'elle la retire immédiatement après, et qu'il y ait un bug sous Plasma 5 qui fait qu'il faille attendre un peu plus. Je lui demanderai. Malheureusement, la clé USB n'a pas de led témoin.

Sinon, pour une co-utilisation d'une clé USB entre Windows et Linux, vous préconisez quel filesystem pour la clé ? Fat 32 / NTFS / EXFAT ?

Fat 32 avec formatage effectué sous Windows.

je dirai fat32 pour les clés USB, c'est ce que j'ai sur une clé USB de 4 Go,
 
à priori c'est le meilleur choix car ça permet une utilisation sans problème entre windows et linux, surtout que windows ne sait pas gérer les systèmes de fichiers linux ( ext3, ext4 etc... ),
 
de plus le système fat32 est un peu plus rapide que le NTFS car pas de système de gestion de droits utilisateurs, de système d'index ou de fonctionnalités avancées, c'est pas indispensable sur une clé USB

D'accord, c'est important que le formatage soit fait sous Windows, alors ? Car j'ai déjà essayé le FAT32 effectué sous Linux avec Gparted et ça posait des problèmes.

à priori ça devrait rien changer le fait que le formatage soit fait sous linux, c'est qui est plutôt délicat c'est de réparer un système de fichiers fat32 sous linux, là il serait préférable d'utiliser windows pour faire le "chkdsk" ( ou le scandisk sous windows 9.x )

la commande pour avoir du fat32 :

mkfs.vfat -F 32 /dev/sdx

il faut avoir préalablement installé le paquet dosfstools,

j'utilise du fat32 sur quelques partitions de mes disques dur ( vieux disques où windows XP se trouvait ) sous archlinux et j'ai jamais eu de problèmes,

je pense que le problème doit être ailleurs ( KDE qui donne l'autorisation de retirer la clé alors que la copie n'est pas encore terminée, un utilisateur trop pressé, ou bien un problème matériel même si la clé est neuve, des cellules flash instables )

Je me souviens avoir eu il y a un paquet d’années des problèmes avec une clef Fat32. À partir du moment où j’ai décidé de formater sous Windows (XP), ben j’ai plus eu de problème.
Donc, oui, pour mon cas, le fait de formater sous Windows a changé la donne.

 
Je viens de voir que mariadb est passe en 10.1.9 sur les depots stables.
C'est corrige le bug? C'est pour savoir si je mets a jour ma machine au boulot ou pas  

dans le pire des cas tu peux toujours downgrader vers la version inférieure si tu constates le bug ( un pacman -U nom_du_fichier_xz  dans le dossier /var/cache/pacman/pkg ),

à condition que l'ancienne version du paquet se trouve bien dans /var/cache/pacman/pkg

Faut aussi que toutes les dépendances soit downgradable sans tout péter.
Et non, à ma connaissance c'est pas "corrigé" mais il y a encore des doutes sur le bug...
Tu peux toujours essayer et aider la science