Reprise du message précédent :

Sauf si tu sauves tes paquets aur dans ton cache (ce que je fais) xz n'a pas vraiment d'intérêt.
C'est pratique pour telecharger mais localement..

Je ne crois pas mettre en cache les paquets    
De toute façon, je viens de retester, même en utilisant les 4 cœurs, la compression reste lente, surtout pour les "gros" paquets (les paquets de dev android )
Bon, bah ça sera tar tout court  
 
 
Sinon, sur un autre sujet : quelqu'un ici a réussi à installer opencv-contrib depuis l'AUR ?
Ça fait 4h que je suis bloqué par une variable non trouvée :

 
Je n'ai rien trouvé sur google en cherchant l'erreur, à part quelqu'un qui conseillait de ne pas compiler le module hdf, mais ça n'a pas marché.
 
Si vous aviez des idées ou si vous pouviez me dire où trouver de l'aide ça serait cool

Je ne pense pas que ça soit équivalent.
Le noconfirm il saura rien faire à une question de type remplacement ou choix de groupe je pense.

j'ai déjà eu cette erreur en voulant compiler le paquet opencv ( celui du dépôt officiel stable )

ça vient du packageur qui a mal précisé dans le PKGBUILD le nom du paquet dans les dépendances nécessaires à la compilation,

il faut que tu installes le paquet "hdf5-cpp-fortran", pacman t'annoncera ensuite un conflit de paquet et te demandera s'il faut désinstaller le paquet hdf5, il faut répondre oui,

le paquet "hdf5-cpp-fortran" une fois installé résoudra le problème

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

Si ma mémoire ne me fait pas défaut, il applique un « yes » automatique.
Sinon, il me suffira de le kill et de faire la MàJ à la main  
 

Merci, ça a résolu le bug de hdf
 
par contre maintenant j'ai le même bug que bokiscout à propos de la stdlib non trouvée    
 
Je sens que je suis pas sorti de l'auberge  
 
EDIT : il semblerait que ça vienne de g++ ( https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129 )

il y aurait une solution ici :
 
https://github.com/opencv/opencv/pull/6541
 
https://github.com/opencv/opencv/pu [...] 3ba859b4e2
 
cmake -DENABLE_PRECOMPILED_HEADERS=OFF ( en modifiant le PKGBUILD ) ou utiliser le patch
 
https://github.com/opencv/opencv/issues/6517

 
C'est en train de compiler là, supprimer les headers précompilés semble avoir fait l'affaire.
Merci beaucoup

est-ce que quelqu'un utilise netctl pour la gestion de la connexion internet ?
 
j'ai remarqué que tous les 10 à 20 démarrages le service netctl échouait ( un [FAILED] rouge de systemd au boot ), ce qui m'oblige à relancer manuellement le service netctl pour que la connexion internet se fasse :
 

 
est-ce un bug connu ? ( j'ai ce bug depuis la création de netctl )
 
est-ce qu'il existe un moyen de forcer systemd à retenter le rédemarrage d'un service lorsque son statut est "[FAILED]" ? ( une option de typ "retry = 5" pour l'obliger à faire 5 tentatives avant de jeter l'éponge )
 
dans le cas de netctl le bug est probablement lié au fait que mon routeur numéricable ( ou mon switch ) a temporairement une micro-panne réseau ( genre un quart de seconde ), ou bien c'est un bug 100% systemd si le service netctl dépend d'un autre service et que ce dernier n'a pas encore fini son initialisation

Xfce4-Terminal mis à jour en 0.8. Compilé avec VTK3 et encore une fois, me casse la compatibilité avec certains thèmes (surtout les thèmes sombres comme les Clearlooks qui ont des couleurs différentes, mais j’ai tout récemment trouvé une version noire d’Adwaita compatible avec les applis GTK3 ; mais la surbrillance est malheureusement limitée au bleu…).

un vieux bug de 3 ans de firefox que j'ai encore sous archlinux malgré le statut "corrigé" :
https://bugzilla.mozilla.org/show_bug.cgi?id=942356

plus en détails ici :
https://wiki.archlinux.org/index.ph [...] _my_plugin
https://bugzilla.mozilla.org/show_b [...] 109795#c16

si vous mettez à jour le plugin flash alors que firefox est en cours d'exécution alors firefox continuera de croire que vous avez l'ancienne version du plugin flash, même si vous refermez et relancez le navigateur,
la faute provient de la manière dont firefox stocke la version des plugins, il met ça dans un fichier pluginreg.dat dans le dossier profile, ce fichier n'est pas reconstruit quand il est présent, ce qui fait que firefox continue de lire des infos périmées au niveau de la version des plugins,

la seule solution c'est de fermer firefox, supprimer manuellement le fichier pluginreg.dat pour qu'il soit récrée automatiquement par firefox

visiblement une tentative de correction du bug a été faite dans les version béta de firefox mais a échoué :

https://bugzilla.mozilla.org/show_bug.cgi?id=1309267

De moins en moins de sites utilisent flash. Ils passent tous sur du html5. Je l'ai viré depuis un moment.
Quand j'ai besoin de flash cas très très rare, je vais sur chrome

Bah, Pluzz fait de la résistance (alors que même P××nHub est passé en HTML5, en tout cas sur mon Arch !)…  
 
De toute façon, comme je fais mres MAJ dès le démarrage de l’OS, et n’ouvre aucun autre logiciel avant que ce soit terminé, je contourne ce problème. Dommage que, contrairement à ce qui se passe sous Windows, il ne soit pas demandé de fermer les navigateurs avant de procéder à la mise à jour du plug-in.

attention il y a une manipulation à faire pour le paquet ttf-dejavu :
 
https://archlinux.fr/news/ttf-dejav [...] ise-a-jour
 
sinon vous aurez cette erreur :
 

Merci  
Le bug skype de la semaine dernière était pas mal aussi.

sinon depuis le dernier noyau linux 4.8.4-1 avez-vous remarqué que les pacman -Syu entrainaient une activité disque dur un peu plus longue avec tendance à accaparer les ressources systèmes ( % CPU, interface graphique qui ne répond plus par intermittence ) ?

j'ai remarqué ça depuis très peu de temps, des pacman -Syu qui mettaient plus de temps, la barre de progression de mise à jour pour les longs paquets qui mettent plus de temps à progresser, comme si la gestion du port SATA était moins bonne

j'ai une vieille carte mère avec des ports sata 2.0 qui ont une émulation IDE au niveau du bios

en fait le problème a lieu dès qu'une intense activité disque dur a lieu, comme par exemple la décompression d'un fichier zip de 700 Mo, je sens que l'icône de souris se déplace moins vite quand je bouge la souris, les ressources systèmes sont trop utilisées par le disque dur, ce qui fait que le reste des processus est moins réactif, c'est comme ça je ressens le problème,

j'avais ce problème en 2013, puis ça s'est résolu tout seul, et là c'est revenu depuis une récente mise à jour du noyau linux, peut-être un changement dans la façon dont le noyau linux gère le multi-tache, dès qu'un processus bouffe trop de CPU ça laisse moins de temps aux autres processus, un problème d'équilibrage,

comme carte mère c'est du socket 775 ( chipset intel P31 ), cpu intel dual core E6800 3.3 Ghz, les ports sata sur cette carte mère sont en mode 2.0, mais dans le bios ils sont émulées en mode IDE pour la compatibilité ( chose fréquente en 2007 chez les fabricants de carte mère, date de cette carte mère gigabyte )

Ca me fait penser aux options de compil du kernel (il y a trèèèès longtemps en années ...) où fallait augmenter "le HZ du kernel" (Linux Kernel Timer Interrupt Frequency me souffle qwant) si on voulait une machine type desktop plus réactive...

peut-être que le mainteneur archlinux du paquet linux a changé quelque chose au niveau de ce paramètre

Et, en faisant, un pacman-optimize (et un clean, histoire de dégager le cache...j'avais presque 100Go de cache sur le mien. )

j'ai fait le pacman-optimize et j'ai installé le nouveau noyau 4.8.6-1 disponible aujourd'hui, on verra si ça va mieux,

sinon un autre bug : parfois quand on insère une clé USB 2.0 elle n'est pas montée automatiquement ( pas de notification de plasma ), dans dmesg il y a la mention "new high-speed USB device number 6 using ehci-pci" mais pas de trace de la partition dans /dev,

en faisant un reboot le système retrouve la possibilité de monter automatiquement les clés USB, peut-être était-ce un bug du noyau 4.8.4-1, car après la mise à jour vers la version 4.8.6-1 je n'avais pas redémarré, c'était encore l'ancien noyau qui était utilisé

Ça, j'ai déjà vu.  
Quand on fait une mise à jour du noyau, les périphériques USB que l'on monte n'apparaissent jamais. C'est le cas chez moi et je l'ai vu à plusieurs reprises.Pas sur que cela soit lié au 4.8

A tous les coups il cherche vfat.ko qui match plus avec le kernel en cours donc il sait pas monter. Ou tout autre driver/fs/module.

ok merci de l'info,

donc il est vraiment conseillé de redémarrer ( et pas attendre le prochain démarrage à froid ) quand dans le pacman -Syu il y a une mise à jour du noyau

Seulement si tu as besoin de modules qui ne sont pas encore en memoire.

sinon mon problème de micro-freeze/lag de l'interface graphique est toujours présent avec le noyau 4.8.6-1,

ça apparaît que si le disque dur est mis à forte contribution ET que le %CPU est élevé, ça donne l'impression que le noyau n'est pas assez équilibré dans la gestion multi-processus, ou qu'une valeur dans le fichier .config du noyau relatif à la gestion multi-processus a changé ( Linux Kernel Timer Interrupt Frequency ?   )

je vais essayer le noyau "mainline" 4.9.x pour voir si le problème est encore présent

Un petit coup d'ABS, un coup d'oeil dans le menuconfig et un makepkg ferait l'affaire théoriquement.

une solution serait de changer de "scheduler"  :

https://wiki.archlinux.org/index.ph [...] schedulers

mais en regardant les commits d'archlinux pour le paquet linux le fichier config n'a pas vraiment évolué ces dernières semaines, il y a quelques semaines j'avais pas ce bug, il doit y avoir une régression quelque part dans cette branche 4.8.x, qui ne se produit peut-être que sur un matériel précis, genre vieux matos intel type dual core socket 775,

sur un PC assez lent toute imperfection/manque d'optimisation d'un algorithme se voit assez vite, sur des machines de guerre type core i7 avec 32 Go de ram, un SSD le bug doit être peu perceptible, sauf à utiliser un benchmark

BFQ et BFS (maintenant MUQSS) ont ete crees pour cela.
 
Apres pour les benchmarks, il y en a vraiment peu qui testent l'interactivité, ce qui est ce qui t'intéresse la.

Hello les experts, j'ai un soucis avec les maj de manjaro :

Si une âme charitable pouvais m'aider
---edit---
Bon en cherchant un peu j'ai trouvé me semble t'il la solution : https://forum.manjaro.org/t/invalid [...] ture/324/3
----redit-----
C'est la bonne solution toutes les mises à jours se sont bien installées

parfois il faut mettre à jour en premier le paquet "archlinux-keyring" pour être sûr d'avoir les dernières clés, un "pacman -Sy archlinux-keyring"

j'ai trouvé cette option dans le manuel de systemd.service :

en ajoutant "Restart=on-failure" dans le fichier du service netctl ça devrait permettre de relancer le service en cas d'erreur,

autre solution :

modifier le service du profil netctl :

en ajoutant un "TimeoutUp=10", ça laissera 10 secondes à la carte réseau pour se réveiller

Salut,

J'ai un laptop et j'ai un DAC branché en USB sur sa docking station. Avec foobar, pas de soucis pour sortir le son, par contre tout le reste sort sur les HP du laptop.
Je pourrais configurer mon .asoundrc pour utiliser mon DAC mais quand le laptop n'est pas sur la docking station ça ne va pas fonctionner (et mon DAC n'est pas sous tension en permanence en plus).

Est-ce que quelqu'un saurait comment solutionner ça :
- mettre une condition au .asoundrc genre if usb_card present use it else use onboard_card ;
- assigner mon DAC de façon temporaire comme carte son avec une ligne de commande ;
- ?

peut-être créer une règle udev dont le rôle est de surveiller si ton DAC usb est branché, dans la règle udev tu peux lui dire d'exécuter un script si le DAC est branché, script qui aura pour fonction de définir le DAC comme carte son principale, et dès qu'il est débranché alors un autre script sera exécuté pour définir une autre carte son,

c'est un peu compliqué à faire :

http://alsa.opensrc.org/Udev

https://doc.ubuntu-fr.org/udev
https://wiki.archlinux.org/index.php/udev

https://wiki.archlinux.org/index.ph [...] sound_card

une règle udev porte l'extension .rules et se met dans /etc/udev/rules.d/

exemple de règle udev chez moi pour mon imprimante canon usb, ça lance un script dès qu'elle est en marche :

tu devras trouver le nom donné à ton dac par le noyau, tout ce qui peut permettre à udev d'identifier ton périphérique,

mais il y a peut-être plus simple qu'une règle udev, je connais pas assez bien les trucs liés à alsa

Ca devrait etre facile avec PA.

 
Merci. Je vais me pencher là-dessus, mais ça a l'air complexe au premier abord.
 

 
   Je n'ai pas la référence là

Je suppose que PA = PulseAudio ( https://wiki.archlinux.org/index.php/Pulseaudio )

Si je ne me plante pas, il est plus évolué qu'ALSA en terme de fonctionnalités

 
   
Ah oui, je cherchais le lien entre solutionner et PA    
 
Apparemment, il y a ce que je cherche avec le module switch on connect

Sinon, tu pourrais dire « résoudre » : ça éviterait de faire saigner les yeux avec d’affreux barbarismes.

 
C'est Français quand même  

on dit « comme même »

et