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.

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

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.

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.

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.

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 😊

Greg Kroah-Hartman

---

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).

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.

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.

Je suis victime d'un bug Fedora :

• Random resume (after suspend) issue on ThinkPad T14s AMD Gen3 (Radeon 680M, Ryzen 7)
• Thinkpad T14S AMD Gen3 - drm/amd firmware bug since Kernel 6.6.8