Recherche
Filtre actif, cliquez pour en enlever un tag :
Cliquez sur un tag pour affiner votre recherche :
Résultat de la recherche (11 notes) :
Installation de Android Studio sous Fedora
Dans le Projet 17 - Créer un POC de création d'une app smartphone avec Capacitor, il semble que j'ai besoin d'installer Android Studio.
J'ai exploré la méthode Asdf / Mise, mais j'ai rencontré des difficultés : 2024-11-19_1029 et 2024-11-19_1102.
J'ai ensuite constaté ici que RPM Fusion ne propose pas de package Android Studio. J'ai ensuite cherché sur Fedora COPR, mais j'ai trouvé uniquement de très vieux packages.
J'ai lu ici qu'Android Studio est disponible via Flatpak sur Flathub : https://flathub.org/apps/com.google.AndroidStudio. Je n'avais pas pensé à Flatpak 🙊.
Après réflexion, je trouve cela totalement logique que Android Studio soit distribué via Flatpak.
Voici le repository GitHub de ce package : https://github.com/flathub/com.google.AndroidStudio. Il semble être bien maintenu par Alessandro Scarozza « Senior Android Developer, Android Studio Flatpak Mantainer and old Debian Linux user ».
Le package contient la version 2024.2.1.11 d'Android Studio, j'ai vérifié, elle correspond bien à la dernière version disponible sur https://developer.android.com/studio.
Voici ce que donne l'installation :
$ flatpak install com.google.AndroidStudio
Looking for matches…
Remotes found with refs similar to ‘com.google.AndroidStudio’:
1) ‘flathub’ (system)
2) ‘flathub’ (user)
Which do you want to use (0 to abort)? [0-2]: 1
com.google.AndroidStudio permissions:
ipc network pulseaudio ssh-auth x11 devices multiarch file access [1]
dbus access [2]
[1] home
[2] com.canonical.AppMenu.Registrar, org.freedesktop.Notifications, org.freedesktop.secrets
ID Branch Op Remote Download
1. [✓] com.google.AndroidStudio.Locale stable i flathub 5,6 Ko / 57,2 Ko
2. [✓] com.google.AndroidStudio stable i flathub 1,3 Go / 1,3 Go
Installation complete.
Journal du jeudi 07 novembre 2024 à 13:38
Même après l'upgrade vers Fedora 41, je rencontre toujours le même bug depuis août 2024.
Pendant une longue période, comme conseillé dans ce commentaire, je suis resté sur un kernel 6.9 jusqu'à la sortie des kernel 6.11.
Je pensais que la résolution de cette issue avait corrigé le problème : 7840h/780m system crash after update to linux kernel 6.10 (#3497).
Mais, je constate que non.
J'ai décidé de prendre un peu de temps pour soumettre au meilleur rapport de bug, que je souhaite dans un premier temps publier dans un commentaire, dans le thread suivant : Persistent System Crashes and Performance Issues on Fedora 40 with ASUS Vivobook 15 - Fedora Discussion.
Aujourd'hui, j'ai eu deux crash de gnome-shell.
À 13:13:33, au moment où j'ai branché le câble USB-C de mon moniteur externe sur mon laptop.
Voici-ci les logs du kernel :
13:13:33 t14s kernel: retire_capture_urb: 58 callbacks suppressed
...
13:13:54 t14s kernel: amdgpu 0000:33:00.0: [drm] REG_WAIT timeout 1us * 100 tries - dcn31_program_compbuf_size line:141
13:13:54 t14s kernel: ------------[ cut here ]------------
13:13:54 t14s kernel: WARNING: CPU: 12 PID: 30057 at drivers/gpu/drm/amd/amdgpu/../display/dc/hubbub/dcn31/dcn31_hubbub.c:151 dcn31_program_compbuf_size+0xd1/0x230 [amdgpu]
...
Version plus complète de ces logs : https://gist.github.com/stephane-klein/dff0d32c20af4307c3b85bbbf03b7b59
J'ai retrouvé la ligne 151 du fichier code source qui génère le warning : drivers/gpu/drm/amd/display/dc/hubbub/dcn31/dcn31_hubbub.c#L151
J'ai fait une recherche sur le gestionnaire d'issues du projet drm/amd avec dcn31_program_compbuf_size comme mot clé et je suis tombé sur cette issue : AMD GPU screen blanking for seconds with a warning
I run Fedora 40 on a ThinkPad T14 Gen3 - comes with AMD Ryzen 7 PRO 6850U with Radeon Graphics. I have my monitor connected via the ThinkPad dock, which is over a USB-C connection.
Yesterday, I updated to F41 with the 6.11.5-300.fc41 kernel. The screen blanking shot up to maybe 30x per minute, with 1-2s blanking each time, effectively giving me an unusable display.
J'ai le même hardware que cette personne et j'ai l'impression que je rencontre le même problème.
Toutefois, j'ai l'impression d'avoir eu des crashes de gnome-shell même sans l'action de brancher un moniteur externe en USB-C 🤔. Je pense être victime de plusieurs bugs.
4 secondes plus tard, Discord génère un coredump :
#JaiDécouvert la commande coredumpctl :
$ coredumpctl list --since "2024-11-07"
TIME PID UID GID SIG COREFILE EXE SIZE
Thu 2024-11-07 10:09:21 CET 352125 1000 1000 SIGTRAP present /app/main/mattermost-desktop 10.6M
Thu 2024-11-07 13:13:58 CET 54929 1000 1000 SIGABRT present /usr/lib64/discord/Discord 56.9M
Voici le contenu de :
$ coredumpctl info 54929 # /usr/lib64/discord/Discord
https://gist.github.com/stephane-klein/56b9097e1a22390ef3350757bf3132dc
Et celui de :
$ coredumpctl info 352125 # /app/main/mattermost-desktop
https://gist.github.com/stephane-klein/1b3790d45aef6383f98341f31ea40444
Voici le message que j'ai posté sur Discourse Fedora : https://discussion.fedoraproject.org/t/persistent-system-crashes-and-performance-issues-on-fedora-40-with-asus-vivobook-15/128526/20
Qu'est-ce que RPM Fusion et pourquoi ce nom ?
Jusqu'à ce soir, j'installais sous Fedora des packages qui vennait du dépôt RPM Fusion sans vraiment avoir étudié ce qu'était-ce repository. Je viens de me renseigner et voici ce que j'ai appris.
"RPM Fusion" est l'équivalent des dépôts "contrib et non-free" chez Debian ou "universe et multiverse" chez Ubuntu.
Le terme "Fusion" dans "RPM Fusion" fait référence à l'origine du dépôt. RPM Fusion est né de la fusion de plusieurs dépôts tiers qui existaient avant sa création en 2007-2008, tels que : Livna, Freshrpms et Dribble.
Journal du mercredi 14 août 2024 à 14:23
Je dois passer par un VPN pour accéder à un projet professionnel.
Ce VPN est propulsé par OpenVPN.
Ma workstation tourne sous Fedora, sous GNOME.
J'ai réussi à configurer facilement l'accès OpenVPN via NetworkManager-openvpn via l'import de fichier .ovpn.
Cependant, cette méthode de configuration m'a posé un problème : le routage par défaut était dirigé vers le VPN. Conséquence, l'intégration de mon accès à Internet passait par le réseau VPN qui était bien plus lent que mon accès Internet.
Ceci était très frustrant.
De plus, cette configuration ajoutait une charge réseau supplémentaire inutile au VPN.
J'ai essayé d'utiliser l'option "N'utiliser cette connexion que pour les ressources sur ce réseau" mais cela n'a pas fonctionné.
Peut-être un problème DNS 🤔.
J'ai donc choisi une autre stratégie. J'ai configuré cela sans GUI.
Voici le skeleton de mon dossier de connexion au VPN : https://github.com/stephane-klein/openvpn-client-skeleton (celui-ci ne contient aucun secret).
Ce projet me permet :
- D'utiliser le serveur DNS présent dans le réseau privé seulement pour un certain type de sous domaine.
- Le VPN est utilisé uniquement pour les serveurs qui se trouvent à l'intérieur du réseau privé. Par exemple, je ne passe pas par ce VPN pour accéder à Internet.
- La totalité de cette configuration est basé sur des fichiers et est scripté (pratique GitOps)
- OpenVPN client est managé par SystemD
Voir aussi 2024-08-14_1511.
Journal du mardi 13 août 2024 à 16:32
Je suis victime du bug suivant depuis 2 ou 3 jours sous ma Fedora :
Unexpected Logouts and System Instability: The second, more critical issue I’ve been facing is unexpected system logouts. Over the past two days, my screen has suddenly gone black as if the system has shut down. After less than a second, the login screen reappears, and upon logging in, I find that all my applications have closed. Yesterday, August 11, 2024, this happened twice within a three-minute span. Today, August 12, 2024, while studying with only Firefox open, I suspended my laptop and left.
-- from
J'en apprends plus ici :
A new regression for AMD APU’s is present in kernel 6.10 that wil cause intermittent full system crashes in combination with Mesa 24.1.5. The only option is to power down and restart the machine.
Kernel 6.9 is unaffected.
Issue upstream : https://gitlab.freedesktop.org/drm/amd/-/issues/3497
Je vais donc reboot sous un kernel 6.9 🤷♂️.
Je suis sûr qu'Alexandre va me dire qu'il n'a aucun problème sous ArchLinux ! Mais je ne le croirai pas, c'est un bug upstream !
Voir aussi ma doctrine Linux Desktop.
2024-08-22 : J'ai posté ce message AMD APU regression (full halt) on kernel 6.10 - how to best report?
2024-09-12 : J'ai posté ce message How to list Mesa versions included in my flatpak applications?
2024-10-15 : J'ai posté ce message.
Journal du mardi 21 mai 2024 à 11:58
Dans ce thread je lis :
Linus Torvalds himself uses Fedora
et aussi un peu plus bas, je lis :
the second guy in linux (greg k.-h.) uses arch though 😊
Linus vient s'ajouter aux nombreux developeurs mainstreams qui utilisent Fedora.
#JaimeraisUnJour commencer à dresser cette liste (chose que j'ai commencé à faire avec cette note).
Upgrade de ma workstation de Fedora 39 vers 40
Fedora 40 version stable est sortie le 23 avril 2024 et presque un mois plus tard, j'ai upgrade mon Thinkpad T14s de la version 39 vers la version 40.
Que ce soit par le passé avec MacOS et maintenant avec Fedora, pour éviter d'être impacté par des bugs, ou des régressions, j'ai pris l'habitude d'attendre quelques semaines avant d'effectuer un upgrade d'OS majeur de ma workstation.
J'ai suivi la méthode officielle de mise à jour :
# dnf install dnf-plugin-system-upgrade
# dnf upgrade --refresh
# dnf clean all
# dnf system-upgrade download --releasever=40
# dnf system-upgrade reboot
et cela c'est déroulé avec succès.
Après 1h d'utilisation, je n'ai observé aucune régression.
Journal du lundi 29 janvier 2024 à 20:00
Sujet : Doctrine Linux Desktop.
Suite aux bugs décrits dans ma note du 2024-01-28, je pense que si je devais installer un Linux Desktop pour des amis non hackers, comme ma petite amie ou ma mère, je choisirais une version de Fedora n-1.
La dernière version de Fedora est actuellement la numéro 39, donc j'opterais pour la version 38.
Les versions de Fedora sont maintenues pendant un an.
Après six mois, les mises à jour se concentrent exclusivement sur les corrections de bugs et de sécurité, sans mise à niveau du kernel ou des autres composants principaux.
Bien que la version la plus récente de Fedora soit très stable, les mises à jour sont fréquentes et proches des versions upstream.
Cela peut exposer les utilisateurs à des bugs upstream, comme cela m'est arrivé récemment.
Repository de packages Flatpak.
Dernière page.