Reprise du message précédent :
Si, j'ai un dual boot avec Windows 7.

A partir du moment où ton noyau démarre c'est que la problématique BIOS/UEFI est déjà hors de cause

j'ai installé le paquet "zynaddsubfx" qui est un synthétiseur virtuel très connu,
 
http://www.linuxmao.org/ZynAddSubF [...] +Logiciels
 
malheureusement le simple fait de lancer le programme fait freezer tout le PC, xorg est figé ( seul le curseur de souris bouge ) et le clavier est bloqué, du coup impossible de basculer vers une console, ni d'utiliser les "magic keys" pour faire un reboot logiciel :
 
https://bugs.archlinux.org/task/44031
 
dans ces conditions pourquoi archlinux n'a pas retiré le paquet puisqu'il génère un énorme bug avec perte de données puisqu'un reset est la seule solution ?
 
à quoi bon laisser ce paquet en liberté ?
 
les autres distributions linux ont-ils le même comportement quand ils savent qu'un paquet est inutilisable suite à un énorme bug ?
 
si quelqu'un connaît une alternative gratuite en terme de synthétiseur virtuel je suis preneur

A tout hasard, parce que ça ne plante probablement pas chez tout le monde ?

as-tu essayé ?
 
la version 2.5.0 du paquet est relativement récente ( 27 février 2015 ) et comme on est sur une rolling release je suis quasi persuadé que tout le monde aura le bug vu que c'est xorg qui plante,
 
faudrait faire le test dans une machine virtuelle pour ne pas perdre de données sur son PC principal vu que ça freeze tout le système

Alors j'ai tenté. Et tout a pété

j'avais pourtant prévenu
 

Non mais tu avais besoin d'un test, je l'ai fait (j'ai rien perdu ya pas de souci)

Ok
 
sinon j'ai trouvé une alternative, il suffit d'installer le paquet AUR "zynaddsubfx-git" qui utilise une autre interface qui ne fait pas boguer xorg :
 
https://aur.archlinux.org/packages/zynaddsubfx-git/
 
comme c'est du AUR le PKGBUILD est mal écrit, car il génère un dossier "/usr/lib64" dans l'archive xz, or pacman va refuser l'installation car il existe un lien symbolique "/usr/lib64" dans le système de fichiers ( conflit de fichiers ),
 
la solution c'est d'ajouter ça à la fin du pkgbuild dans la rubrique "package" :
 

En même temps il vient de community ton paquet, c'est aussi peu fiable que l'AUR

cette mésaventure me fait penser qu'il faudrait que pacman ait une nouvelle fonctionnalité : pouvoir afficher le statut d'un paquet,

un truc du style :

et si on tape :

comme ça on saura d'emblée si le ou les paquets qu'on veut installer/mettre à jour est vraiment utilisable

une base de données interrogeable à distance pour connaître le statut en temps réel de chaque paquet officiel pourrait rendre service aussi ( ça évite d'incorporer le statut dans l'archive xz )

Du coup tu fais quoi, dans ces cas-là ? Tu mail le mainteneur / fais un rapport de bug ?

en fait je suppose qu'à ce moment là un rapport de bug est déjà ouvert quand un paquet officiel a le statut "marche pas/bogué",
 
je vois la chose comme ça : dès qu'un utilisateur crée un rapport de bug sur le site d'archlinux concernant un paquet officiel alors ça changera automatiquement son statut dans la base de données "statut" que pacman interrogera à chaque installation/mise à jour d'un paquet,
 
cette fonctionnalité de vérification de statut pourra bien sûr être désactivée dans le fichier pacman.conf pour ceux qui ne veulent pas être embêtés par les avertissements ( ou qui sont un peu kamikazes )

Non mais je veux dire, le gros bug de zynaddsubfx, tu l'as fait remonter ?

La fièvre de l’AUR ?

la ruée vers l'AUR

 
il y a déjà un rapport de bug sur le site d'archlinux :
 
https://bugs.archlinux.org/task/44031
 
mais je ne sais pas si sur le site officiel de zynaddsubfx il y a un rapport de bug

Je viens de tenter, ma machine ne gele pas.
Par contre ca m'a delogue de Xorg (j'imagine que Xorg a du redemarrer).

tu as peut-être une configuration de xorg différente de la mienne ?
 
peut-être une option qui demande à xorg de redémarrer automatiquement en cas de plantage ?
 
je précise que je n'utilise pas le dépôt testing, j'utilise KDE4 et le pilote libre radeon

Aucune idee, mais sur le flyspray, quelqu'un d'autre a le meme comportement.
 
Apres je trouve que ca reste un soucis de Xorg ou Linux, ce n'est pas acceptable qu'un programme non-root puisse casser la machine a ce point la... Il pourrait etre interessant d'aussi poursuivre dans cette voix, mais comme je n'utilise pas ce programme et je suis deja sur un autre soucis avec radeonsi, je passe.

d'après le forum russe d'archlinux ça pourrait venir de xorg 1.17 :
 
http://archlinux.org.ru/forum/topic/14597/
 
traduction approximative :
 
https://translate.google.fr/transla [...] edit-text=

ca parait possible en effet.

Nouveau bug sur systemd-219 (qui est pour le moment en testing):
Je peux me monter une ISO, la demonter pas de soucis.
Mais apres je ne peux plus rien monter jusqu'au prochain reboot.
Ca fonctionne bien en -218, ou en -git.
 
Il est improbable a ce moment qu'Arch backport le patch de git, donc attention avec systemd-219. Je reste sur 218 en attendant 220.

merci de l'info
 
il faudrait peut-être créer un rapport de bug afin de dissuader les mainteneurs de passer la version 219 dans le dépôt stable

C'est deja fait.

 
Il y a plein de backport de patch de systemd avec des versions 217-x par exemple et ce depuis un moment.

Soit, il n'empeche que pas pour ce bug.

Sur Arch avec Plasma 5, j'ai souvent le clic droit sous Firefox qui ne fonctionne plus. Obligé de redémarrer Firefox, ça remarche, pendant quelques minutes, puis ça ne marche plus à nouveau.

On a pas encore de 3.19.x en stable, mais au vu de la tête du changelog du 3.19.1 c'est moyennement étonnant, j'ai rarement lu un truc aussi long pour une version x.y.1 !
 
Par contre, on est toujours bloqué en 3.18.6 en stable au lieu de 3.18.9

je suis en 4.0 deja

Question un peu noob (et plus liée à Linux en général qu'à Arch en particulier) : j'ai Arch Linux et Chakra installées sur la même machine, sur le même disque dur ; toutes deux ont une partition / séparée, mais partagent la même partition /home (un home chakra et un home arch sur la même partition, donc) ; est-ce qu'il est possible (facilement ) d'accéder à un répertoire en particulier, en lecture et écriture, du home de l'utilisateur chakra depuis arch ?

oui

Hein ? C'est la même partition ou pas ?
La formulation semble contradictoire.

Ben non, les root ont chacun leur partition, mais /home est cumulative.

Dans ce cas pourquoi il demanderait si il peut avoir accès au home de l'un depuis l'autre S'il a fait pointer les deux installations vers un /home commun, il doit bien être au courant non ?

J'imagine qu'il a des utilisateurs differents pour chaque OS.

En fait oui, les deux /home sont sur la même partition (physique). Mais ce sont bien deux /home de deux utilisateurs de deux distros séparées. C'est plus clair ou pas ?

 
Ok, et si je te demande "est-ce que tu peux me dire comment faire ?", tu vas simplement me répondre "Oui" aussi ?

peut-être en créant un groupe commun à ces 2 utilisateurs, groupe qui aura ensuite les droits en lecture et écriture ( et aussi exécution s'il y a des scripts ) sur cette partition home, tout utilisateur appartenant à ce groupe pourra alors y acceder

Après une longue infidélité avec Debian je suis de retour, l'installation a bien changée depuis Oo

C'est ça qu'on aime