J’ai eu du mal à retrouver le sujet, ce nouveau forum est plus compliqué que l’ancien…
J’ai refait des tests, alors je n’ai pas eu le problème à nouveau. Cependant, j’ai utilisé Teamviewer du PC Fedora vers le PC Windows pour un autre usage, et là j’ai perdu le “SHIFT”
Je pense donc que le souci n’est pas RDP mais Teamviewer que j’avais du utiliser simultanément ou juste avant sans me rendre compte du dysfonctionnement entre temps !
Bonjour,
Avant de déclarer un bug (et je ne sais pas à qui pour le moment, GNOME ou Fedora ou client RDP) je voulais avoir si déjà certains d’entre vous ont le même problème.
Cas d’usage :
Fedora Workstation 39 (avec GNOME)
J’ai activé l’accès distant dans l’environnement de bureau.
Quand je me connecte depuis un PC équipé de Windows 10 (avec le client RDP de Windows) aucun souci de prise de contrôle du PC Fedora. (RDP est utilisé comme prise de contrôle, c’est à dire qu’à travers le client RDP, je vois la même chose que le PC qui est contrôlé)
Cependant après déconnexion, sur le système Fedora, la touche “Shift” n’est plus fonctionnelle et donc je ne peux plus écrire “Bonjour” par exemple, le “B” majuscule n’est pas pris en compte.
Y a t il des utilisateurs de cette fonctionnalité de GNOME ? Avez-vous le même problème ?
Merci
Réglé en effet, je ne sais pas comment on met la balise résolu avec ce forum
OK.
RAS sur la Fedora 39, seule Rawhide (40) est concernée
J’ai donc ouvert le bug, j’avais peur que ça soit une config perso (ma Rawhide date de plus de 5 ans 😃 ) : https://bugzilla.redhat.com/show_bug.cgi?id=2239276
Bonjour,
Sur Rawhide, il semble que les applications GTK4/libadwaita ne veulent plus appliquer le thème sombre.
Avez-vous ce cas aussi ?
Je n’ai pas vu de bugs sur le bugzilla de Fedora à ce sujet. J’ai le souci sur ma VM de tests ET sur ma machine physique de test, les 2 sur rawhide.
Merci
Esxcellent, j’ai du installer ce paquet à la main comme indiqué dans https://fedoraproject.org/wiki/Changes/RetiredPackages (peut être c’est fourni par défaut maintenant)
J’ai testé pour Fedora 36, ça m’a supprimé jsoup-1.13.1-9.fc36.noarch
ça m’a laissé ceci :
clang12-resource-filesystem-12.0.1-4.fc36.x86_64
clang12-libs-12.0.1-4.fc36.x86_64
librttr-0.9.7-0.1git7edbd58.fc36.x86_64
libffi3.1-3.1-32.fc36.x86_64
L’outil était bien lent.
Je ne suis pas convaincu
Bonjour,
J’ai une installation (datant de Fedora 29) que j’ai mis à niveau au fur et à mesure de l’utilisation.
Je n’ai pas sauté de version lors des mises à niveau.
Cependant, je me retrouve avec plein de packages anciens :
adwaita-qt4-1.1.3-4.fc33.x86_64
nautilus-sendto-3.8.6-9.fc33.x86_64
adwaita-qt-1.1.3-4.fc33.x86_64
dain-snappy-0.4-12.fc34.noarch
julietaula-montserrat-fonts-common-7.210-5.fc35.noarch
libicu67-67.1-2.fc35.x86_64
julietaula-montserrat-base-web-fonts-7.210-5.fc35.noarch
ipw2200-firmware-3.1-22.fc35.noarch
ipw2100-firmware-1.3-29.fc35.noarch
wireless-tools-29-28.fc35.x86_64
clang12-resource-filesystem-12.0.1-4.fc36.x86_64
clang12-libs-12.0.1-4.fc36.x86_64
librttr-0.9.7-0.1git7edbd58.fc36.x86_64
libffi3.1-3.1-32.fc36.x86_64
jsoup-1.13.1-9.fc36.noarchQuelle est la “meilleure” méthode pour purger cela ?
dnf autoremove => n’en supprime aucun de ceux ci.
Supprimer à la main est une option, mais je ne pense pas la meilleure.
dnf distro-sync => ne supprime pas non plus, il va me mettre à niveau quelques paquets qui ne concernent pas la liste ci dessus.
Merci de vos lumières 🙂
Edit Nicosss : Correction balises Markdown -> FAQ
En fait, je pense que je vais procéder autrement.
l’idée du PATH me plait bien.
Je vais créer un lien symbolique de pigz dans /usr/local/bin qui est dans le $PATH AVANT /usr/bin (pour les utilisateurs et root)
Ainsi, ça ne va pas remettre en cause l’intégrité de gzip et ça sera prioritaire pour tous.
Merci pour les réponses.
Un alias gzip, ne fonctionne pas si je fais un tar -cvzf par exemple, ni si le tgz est généré par l’outil de compression graphique.
L’idée étairt de savoir si un moyen “propre” natif de cette implémentation sous Gentoo était possible : https://wiki.gentoo.org/wiki/Gzip#Parallelization
Sinon, je fais des liens symboliques et je les recréé à chaque mise à jour de gzip
Bonjour,
Existe-t-il une manière propre de remplacer gzip par pigz (qui est multithread) ?
Sous Gentoo, j’ai une alternative officielle qui remplace gzip par pigz (créé les liens symboliques qui vont bien).
/bin/gunzip -> gzip
/bin/gzip -> ../usr/bin/pigz
/bin/zcat -> gzip
A savoir que gzip et pigz sont parfaitement identiques au niveau des options.
Merci
Justement, je ne veux pas que les paquets soient notés manuellement installés.
Dans l’échantillon, une install classique initiale “dnf install httpd” fait :
httpd : installé manuellement
httpd-filesystem et httpd-tools : dépendances
dnf upgrade *.rpm : me conserve ce qui a été fait initialement, donc c’est parfait.
xylphute En effet dnf upgrade /var/tmp/dnf/*rpm fonctionne.
J’ai fait le test juste sur httpd* il m’a upgradé : httpd httpd-filesystem et httpd-tools
Si je tente un dnf autoremove httpd il me supprime bien httpd-filesystem et httpd-tools (considérés comme unused dependancies).
Note le dossier /var/tmp/dnf a été complètement vidé juste après.
Je vais creuser la piste, je pense que le dnf install par contre marque comme manuellement installé les paquets.
Bonjour,
Je souhaite mettre en place un processus de mises à jour maitrisé sur des serveurs.
Je réalise une extraction des MàJ avec
dnf check-update
Puis pour éviter de faire un repolocal, je fais un
dnf update --downloadonly --downloaddir=/var/tmp/dnf/
Comment puis-je faire pour quelques jours plus tard appliquer les mises à jour des RPM de ce dossier ?
Si j’installe avec
dnf install /var/tmp/dnf/*rpm
Je vais avoir des RPM notés comme manuellement installés.
On peut invoquer un dnf upgrade avec un dossier spécifique ?
Je n’ai pas trouvé dans le man de dnf
Merci
Hello,
Quel look moderne maintenant !
Bravo pour le travail
* Tue Mar 17 2020 Uwe Klotz <uklotz@mixxx.org> - 2.3.0-0.1.alpha.20200316gite16b6a6
- New upstream snapshot 2.3.0-pre-alpha
- Replaced build system SCons with CMake
* Wed Feb 05 2020 RPM Fusion Release Engineering <leigh123linux@gmail.com> - 2.2.3-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_RebuildOui flatpak est en version 2.2.4 qui est la version stable. Je n'ai pas testé si ça fonctionnait bien avec mon matériel.raigoin wrote:Bonjour Adrien.D,
Je n'ai regardé dans les dépôts RPM fusion (car pas installé lesdits dépôts). Ce serait un choix étrange que de mélanger version stable et bêta de logiciels.
Cependant RPM Fusion ne semble pas être maintenu par Fedora : https://en.wikipedia.org/wiki/RPM_Fusion .
Sinon, la version flatpak est la 2.2.4 -> https://github.com/flathub/org.mixxx.Mixxx .