- Fedora-Fr
- À propos de Fedora-Fr
- Historique
- Statistiques
- Télécharger
- Obtenir Fedora
- Toutes les méthodes de téléchargement
- Support
- Aide sur IRC
- Forums
- Documentation
- Sous-projets
- Plateforme de blog
Dernière news : Fedora 34 n'est plus maintenu
Pages : 1
Bonjour,
J'ai un problème avec ma Fedora 25. Je suis incapbable de lire un flux MMS windows avec Totem, il finit par bloquer. J'ai installé tous les packages gstreamer (ugly, bad, non-free etc.) il n'y a rien y faire. Quelqu'un pourrait-il m'aiguiller ?
Merci.
Hello, Edouard,
En fait c'était surtout pour introduire le logiciel alien car on rencontre beaucoup plus souvent de deb pour ces petits logiciels "confidentiels" que de rpm, et partir à zéro ça rebute plus d'un débutant. Moi je ne savais pas du tout comment on construisait un rpm, et en décortiquant le spec généré par alien ça m'a permis de comprendre très vite. Et comme alien, comme beaucoup de convertisseur, ne tient pas forcément des particularités, il faut toucher au spec et comprendre pourquoi (par exemple la différence de répertoire des packages python entre Debian et Fedora).
Pour gnome-appfolders-manager, je vais voir pour le proposer, mais il me faut faire un spec en béton, avec changelog et tout :)
Si comme moi vous aimez le Gnome Shell "vanille", mais que vous ne supportez pas le foutoir, sachez qu'il existe un programme qui simplifie la création de "sous-tiroir" d'application, c'est le projet gnome-appfolders-manager.
Malheureusement, il n'existe pas de rpm pour les dernières versions. C'est alors que je me suis décidé d'en créer un et de vous le partager.
D'abord, pour simplifier le travail, je suis parti du deb déjà existant. Il existe un programme qui convertit les deb en rpm, c'est alien, plus d'explication ici : https://www.maketecheasier.com/convert-deb-files-rpm/
Ensuite, j'ai dû modifier le fichier SPEC grâce à rpmrebuild pour intégrer les dépendances nécessaires (qui ne sont pas utile chez Debian). Et là où il faut faire très attention, c'est que Debian n'installe les modules python au même endroit. Debian, c'est /usr/lib/dist-packages, Fedora c'est /usr/lib/site-packages. Pendant l'édition du SPEC, j'ai renommé dans ~/.tmp (là où travaille rpmbuild) le dossier dist-packages en site-packages, et remplacer en conséquence toutes les occurrences de dist-packages dans le fichier SPEC. ENregistrement du SPEC, et voilà, le tour est joué :)
J'espère que cela aidera certains.
Et voici en cadeau le rpm de gnome-appfolders-manager : http://dl.free.fr/bssYvhdIj
En tuant la session gdm tty1, tout va bien, pas de comportement instable. En fermant sa session Gnome, gdm réapparaît sur tty1 (on y rebascule automatiquement) comme si on venait fraîchement de booter, simplement, en reconnectant la même session, je crois que certains processus sont "dédoublés", notamment ceux qui sont placés en autostart.
Un workaround serait de créer un service qui va tuer automatiquement gdm à la connexion, je vais voir si je peux le faire.
Une autre possibilité est d'utiliser lightdm, mais je crois qu'il ne gère pas correctement wayland.
C'est-à-dire ? En tuant gdm sur le tty2 et en lançant une session Xorg sur le tty1 ou ça n'a pas d'importance ?
Apparemment, même problème signalé ici : https://www.reddit.com/r/Fedora/comment … ession_to/
En conclusion, c'est a priori "normal" mais pas très sécurisant, causé par l'utilisation de systemd, mais qu'à l'avenir ça devrait être "corrigé".
C'est super déconcertant car les tty n'apparaissent plus en faisant un ps -ft tty.
Voici :
# ps aux | grep gdm
root 813 0.0 0.0 483596 6516 ? Ssl 00:12 0:00 /usr/sbin/gdm
root 862 0.0 0.0 372060 720 ? Sl 00:12 0:00 gdm-session-worker [pam/gdm-launch-environment]
gdm 969 0.0 0.0 66088 3564 ? Ss 00:12 0:00 /usr/lib/systemd/systemd --user
gdm 989 0.0 0.0 99188 4 ? S 00:12 0:00 (sd-pam)
gdm 994 0.0 0.0 449940 944 tty1 Ssl+ 00:12 0:00 /usr/libexec/gdm-wayland-session gnome-session --autostart /usr/share/gdm/greeter/autostart
gdm 1008 0.0 0.0 56636 1312 ? Ssl 00:12 0:00 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
gdm 1022 0.0 0.0 691332 3148 tty1 Sl+ 00:12 0:00 /usr/libexec/gnome-session-binary --autostart /usr/share/gdm/greeter/autostart
gdm 1047 0.0 0.6 1910068 54532 tty1 Sl+ 00:12 0:03 /usr/bin/gnome-shell
gdm 1290 0.0 0.0 249892 5072 tty1 Sl+ 00:12 0:00 /usr/bin/Xwayland :1024 -rootless -noreset -listen 4 -listen 5 -displayfd 6
gdm 1312 0.0 0.0 344748 512 ? Ssl 00:12 0:00 /usr/libexec/at-spi-bus-launcher
gdm 1317 0.0 0.0 56304 0 ? Sl 00:12 0:00 /bin/dbus-daemon --config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork --print-address 3
gdm 1320 0.0 0.0 223372 1196 ? Sl 00:12 0:00 /usr/libexec/at-spi2-registryd --use-gnome-session
gdm 1326 0.0 0.0 1395316 3028 ? S<l 00:12 0:00 /usr/bin/pulseaudio --start --log-target=syslog
gdm 1357 0.0 0.0 459984 528 tty1 Sl 00:12 0:00 ibus-daemon --xim --panel disable
gdm 1360 0.0 0.0 382576 400 tty1 Sl 00:12 0:00 /usr/libexec/ibus-dconf
gdm 1363 0.0 0.0 567328 3872 tty1 Sl 00:12 0:00 /usr/libexec/ibus-x11 --kill-daemon
gdm 1369 0.0 0.0 441556 116 ? Ssl 00:12 0:00 /usr/libexec/xdg-permission-store
gdm 1385 0.0 0.0 1261392 7380 tty1 Sl+ 00:12 0:00 /usr/libexec/gnome-settings-daemon
gdm 1400 0.0 0.0 187400 660 ? Sl 00:12 0:00 /usr/libexec/dconf-service
gdm 1406 0.0 0.0 308776 320 tty1 Sl 00:12 0:00 /usr/libexec/ibus-engine-simple
root 1495 0.0 0.0 394868 724 ? Sl 00:12 0:00 gdm-session-worker [pam/gdm-password]
fiedor 1521 0.0 0.0 449940 884 tty2 Ssl+ 00:12 0:00 /usr/libexec/gdm-wayland-session gnome-session
root 16926 0.0 0.0 119372 956 pts/0 S+ 22:59 0:00 grep --color=auto gdm
Bonjour à tous,
Je voulais savoir si c'était normal d'avoir deux sessions GDM qui démarre sur la Fedora 25 et pourquoi la session principale est sur le tty2. Avant, on pouvait modifier cela par le inittab, mais là, avec systemd, je sèche.
Cordialement.
C'est bon a priori un reboot a réglé la chose.
Bonjour les fédoriens,
Voilà j'ai un problème avec lirc. J'ai d'abord dû créer un utilisateur lirc (sans login) et le groupe lirc. J'ai dû aussi créer le dossier
/var/run/lirc
propriété de lirc.
Malgré tout, quand je lance le service je reçois une alerte SELinux et le service se bloque et s'arrête.
Processus source : lircd
A tenté l'accès suivant : getattr
sur ce sock_file : /run/lirc/lircd
La procédure pour débloquer la protection est celle-ci :
SELinux is preventing lircd from getattr access on the sock_file /run/lirc/lircd.
***** Plugin catchall (100. confidence) suggests **************************
If vous pensez que lircd devrait être autorisé à accéder getattr sur lircd sock_file par défaut.
Then vous devriez rapporter ceci en tant qu'anomalie.
Vous pouvez générer un module de stratégie local pour autoriser cet accès.
Do
allow this access for now by executing:
# ausearch -c 'lircd' --raw | audit2allow -M my-lircd
# semodule -X 300 -i my-lircd.pp
Additional Information:
Source Context system_u:system_r:lircd_t:s0
Target Context system_u:object_r:var_run_t:s0
Target Objects /run/lirc/lircd [ sock_file ]
Source lircd
Source Path lircd
Port <Unknown>
Host fedora-alex
Source RPM Packages
Target RPM Packages
Policy RPM selinux-policy-3.13.1-225.6.fc25.noarch
Selinux Enabled True
Policy Type targeted
Enforcing Mode Enforcing
Host Name fedora-fiedor
Platform Linux fedora-fiedor 4.9.6-200.fc25.x86_64 #1 SMP Thu
Jan 26 10:17:45 UTC 2017 x86_64 x86_64
Alert Count 1
First Seen 2017-02-08 12:41:10 CET
Last Seen 2017-02-08 12:41:10 CET
Local ID 5c4b01fa-c2f0-4193-9661-b8ee1a942b0e
Raw Audit Messages
type=AVC msg=audit(1486554070.171:927): avc: denied { getattr } for pid=9290 comm="lircd" path="/run/lirc/lircd" dev="tmpfs" ino=884817 scontext=system_u:system_r:lircd_t:s0 tcontext=system_u:object_r:var_run_t:s0 tclass=sock_file permissive=0
Hash: lircd,lircd_t,var_run_t,sock_file,getattr
J'exécute bien les deux commandes suivantes :
# ausearch -c 'lircd' --raw | audit2allow -M my-lircd
# semodule -X 300 -i my-lircd.pp
mais toujours impossible de lancer le service lircd, l'alerte revient systématiquement.
Quelqu'un pourrait-il m'aider ?
Merci d'avance.
Pages : 1