moi1392 a écrit 725 commentaires

Un point important signalé sur le bug tracker debian :

BTW, all those who added symbolic links to make FF 108 work
should remove them before upgrading the firefox package, otherwise
there is a risk to have the same kind of issue.

Pour ceux qui ont mis en place ce workaround, n'oubliez pas de virer vos liens symboliques lorsque firefox sera mis à jour.

J'ai déjà eu le souci de vouloir installer un paquet au moment où ses dépendances étaient cassé dans sid.

De mon expérience, si vraiment tu ne veux pas attendre, ce qui marche le mieux c'est d'aller chercher une version plus ancienne dans les archives debian (les .deb) de de l'installer à la main.
Il faut 2 ou 3 passages de téléchargement manuel par les archices pour aller chercher toutes les dépendances qui ne sont cassées, et se taper quelques coups de dpkg pour voir ce qu'il manque, et le reste viens depuis l'archive par apt.

Vous êtes violent dans votre IUT… bon après j'ai une policy par défaut en drop sur les paquets tcp de connexion en entrée, c'est pour ça que je ne me gêne pas trop là dessus ;)
Mais oui c'est un coup à le faire par réflexe un jour ou sur une machine où je serai moins safe, je vais m'efforcer de changer cette habitude, merci :)

mais xhost + est une très mauvaise idée

Oui c'est vrai. Je ne sais pas pourquoi mais quand je tente un xhost +localhot ça ne marche pas comme je m'y attends.
Dans le temps j'étais un peu plus bourrin et je copiais le cookie d'authentification (.Xauthority) depuis le home de l'user connecté vers l'autre. Je ne suis pas certain que ça soit une meilleur pratique et j'ai arreté.
Je vais rententer ça en m'appliquant un peu plus.

Sinon ssh -X te fait passer en indirect rendering pour OpenGL et tu te retrouves avec de l'OpenGL 1.1 (ça à peut-être changé depuis), en plus certaines applis alakon (firefox pour ne pas le nommer) trouv(ai)ent le moyen de foutre la merde et de se lancer localement avec l'utilisateur local, au final ça ne m'a jamais vraiment convenu sauf pour des trucs simples.

PS: Pour firefox j'avais essayer un ssh -X à travers internet depuis un ami vers chez moi pour essayer de me connecter à un site avec mon ip de chez moi et pas celle de chez lui.
Je hais les application qui essayent de faire des trucs "intelligent" en ne se comportant pas comme leur environement leur indique…

je me doutais bien que c'était la solution, mais je ne voulais pas le faire sans savoir pourquoi.
En regardant de plus près, le fichier /dev/dri/renderD128 utilise des attributs de filesystem étendu et l'user logué est ajouté en rw sur ce fichier. Je n'ai pas creusé pour savoir qui fait ça, je suppose que c'est dans la stack Xorg/dri quelque part.

De plus, la doc officielle debian indique bien que ce groupe sert à l'accès au périphérique de rendu.

Donc voila, j'ai ajouté mes utilisateurs dans le groupe et le problème est réglé ;)

C'est marrant parce que de ce que tu décris de l'image, je ressens le contraire de ce que tu dis.
Tout d'abord, je précise que je n'ai pas vu l'image, et je ne suis pas du tout au courant de la réalité de la vie en Cote d'Ivoire dans sa globalité.
Mais :

Pourquoi montrer un des quartiers les plus pauvres de Dakar, sans montrer les plus modernes et urbains ?

Par ce qu'il y avait de la place que pour une image ? Parce que c'est une image pour illustrer un problème, donc on montre le problème ?
Je fais la différence entre une image d'illustration, et une image de justification. En effet, dans ce contexte une image ne peut pas justifier un problème général, mais elle peut l'illustrer. donc si problème il y a bien (et ça, je n'en sais rien), l'image joue parfaitement son rôle.

Aucune information sur les quartiers riches et touristiques, comme la petite côte ou la pointe d'Amaldie.
Pas une seule ligne sur les richesses naturelles et minières du Sénégal, que nous exploitons pourtant.

Tout pays a des endroits et des richesses, si tu veux illustrer quelquechose de négatif et que tu montres des trucs positifs, c'est tes images qui sont déplacées et qui trompent.

Je trouve la présentation partielle et malsaine, comme une justification de la colonisation entre les lignes.

Du coup (je déteste cette expression et je l'utilise beaucoup trop…) je ne vois pas comment tu arrives à cette conclusion. Si comme tu l'as fait remarqué, il aurait été plus honnete de montrer les quartiers riches et les richesses du pays, tu aurais plutôt fait l'apologie de la colonisation et du pillage des richesses avec toutes les choses "bien" qu'elles ont apporté. En sous entendant au passage que les quartiers riches de Dakar sont quelque chose de "bien", donc que le projet de colonisation, sans parler de sa réalisation, était une bonne idée au final.
Alors qu'en illustrant les endroits les moins agréables, tu montres justement qu'un pays qui pourtant possède des richesses a une population qui vit dans une grande pauvreté et précarité. Du coup à bat les colonisateurs et les pilleurs !
Au final, et sans l'avoir vu mais seulement avec ta description, l'image illustre plutôt bien ce que tu dénonces, de mon point de vue biaisé à moi.

Je pense que OpenGL fonctionne parce qu'il obtient l'accès au GPU via X/GLX alors que Vulkan requiert l'accès direct.

Je pense que c'est ça aussi.

Il faut que ton user2 soit dans le groupe render.

Tu as vu cette info quelque part ou tu réponds avec les infos de mon message ? Si tu as lu jusqu'au bout, ni user1, ni user2 sont dans le groupe render et je n'ai aucune idée de comment l'user logué dans la session graphique arrive à ouvrir ce fichier.
Il faudrait en effet que je creuse de ce coté là mais j'espérais qu'il y aurait un moyen "officiel" (à la xhost par exemple) que quelqu'un connaitrait ici.

tu peux faire le test toi même avec glxgears pur OpenGL et vkcube pour Vulkan.
vkcube est compilé avec X sous debian.

bien joué :)
T'as fait comment pour libpng ? je l'ai fixé chez moi si tu as besoin.

quand j'essaie de le lancer sur un système 64-bit, le terminal m'informe gentiment que mon fichier n'existe pas

ça c'est une erreur classique pas classique du tout, c'est généralement quand tu fais l'édition de lien dans un environnement chelou, et que la lib ld.so référencée par ton executable n'est pas trouvée ou n'est pas de la bonne plateforme (32 vs 64 bits).

tu peux essayer de l'ouvrir (l'executable, pour toi le fichier "wesnoth") avec un éditeur de texte (évite les trucs graphique, less est très bien pour ça) et pas loin du début tu vas voir le chemin en dur vers la lib "ld.so.quelquechose" (par exemple /lib64/ld-linux-x86-64.so.2 pour les binaires de ma distribution)
vérifie que le chemin existe et qu'il pointe bien vers un loader 64 bits (c'est souvent un lien symbolique)
s'il n'existe pas, facile, tu crées un lien symbolique vers le bon fichier, s'il existe et pointe vers du 32 bits… hheeuu… bonne chance. Je te déconseille fortement de le remplacer, tu auras juste TOUS tes binaires 32bits qui ne démarrerons plus, y compris les outils standards (ls, cp, …) ton système deviendra juste complètement inutilisable.

je m'auto-auto répond (pour une auto-auto-satisfaction récursive !)
c'est un

#include <algoritm>

qui manque dans src/campaign_server/campaign_server.cpp

au passage, il manque aussi un #include dans src/campaign_server/campaign_server.cpp et un #include "../unit_map.hpp" dans src/editor/editor_main.cpp (à ajouter au premier patch, j'avais pas activé les tools à la compilation du coup je ne l'avais pas vu)

Une fois ces problèmes fixés, je tombe sur un souci d'api avec la libpng de ma machine, et pas trop le temps de creuser là… tu peux toujours compiler une vieille libpng comme tu as fait pour freetype2, mais à mon avis c'est simplement fixable avec une libpng plus récente (mais est-ce que c'est ce que tu veux faire ?)

#inclide <algorithm>

au début du fichier src/server/game.cpp (avec les autres #includes, mets le en dernier)
Sérieux quel message d'erreur à la con, j'ai buggué 10 minutes avant de comprendre…

Si tu veux compiler toi-même,

je résiste encore et toujours à l'envahisseur freetype2 des années 2000, tu ne m'auras pas si facilement :p

Finalement je te mets le patch ici, ne me crédite pas tu peux mettre ton nom ça me va, (il est en licence "BCET" : Balec Complet Et Total)
c'est un patch git sur le tag 1.2.8
Si tu as d'autres soucis de compilation après ça, je compilerai freetype2 pour alle rau bout du build et les fixer aussi. Quand j'aurais la motiv…

From fecd2c59ddf91d47901a90ecc7d81d353374cef8 Mon Sep 17 00:00:00 2001
From: plop <plop>
Date: Tue, 1 Nov 2022 19:04:04 +0100
Subject: [PATCH] Fix unit/unit_map include circular dependency

---
 src/actions.hpp        |  1 +
 src/ai_dfool.hpp       |  1 +
 src/config_adapter.cpp |  1 +
 src/game_events.hpp    |  1 +
 src/pathfind.cpp       |  1 +
 src/preferences.cpp    |  1 +
 src/unit.hpp           | 13 ++-----------
 src/unit_abilities.cpp |  1 +
 src/unit_map.hpp       | 11 +++++++++++
 src/upload_log.cpp     |  1 +
 10 files changed, 21 insertions(+), 11 deletions(-)

diff --git a/src/actions.hpp b/src/actions.hpp
index 0191f8b05f6..0a9a287a3ef 100644
--- a/src/actions.hpp
+++ b/src/actions.hpp
@@ -23,6 +23,7 @@ struct combatant;

 #include "map.hpp"
 #include "unit.hpp"
+#include "unit_map.hpp"

 #include <deque>

diff --git a/src/ai_dfool.hpp b/src/ai_dfool.hpp
index ec043c470ca..d0f407669b3 100644
--- a/src/ai_dfool.hpp
+++ b/src/ai_dfool.hpp
@@ -5,6 +5,7 @@

 #include "ai_interface.hpp"
 #include "map.hpp"
+#include "unit_map.hpp"
 #include <vector>
 #include <map>
 #include <string>
diff --git a/src/config_adapter.cpp b/src/config_adapter.cpp
index 9fd56aef144..2726804948b 100644
--- a/src/config_adapter.cpp
+++ b/src/config_adapter.cpp
@@ -12,6 +12,7 @@
 */

 #include "global.hpp"
+#include "unit_map.hpp"

 #include <sstream>
 #include "config_adapter.hpp"
diff --git a/src/game_events.hpp b/src/game_events.hpp
index 4e0280d57a4..dd2b8cc38cb 100644
--- a/src/game_events.hpp
+++ b/src/game_events.hpp
@@ -21,6 +21,7 @@ class display;
 #include "map.hpp"
 #include "team.hpp"
 #include "unit.hpp"
+#include "unit_map.hpp"
 #include "variable.hpp"

 #include <vector>
diff --git a/src/pathfind.cpp b/src/pathfind.cpp
index 6a61b4b5483..4f2c841ccbf 100644
--- a/src/pathfind.cpp
+++ b/src/pathfind.cpp
@@ -19,6 +19,7 @@ See the COPYING file for more details.
 #include "log.hpp"
 #include "pathfind.hpp"
 #include "util.hpp"
+#include "unit_map.hpp"
 #include "wassert.hpp"

 class gamestatus;
diff --git a/src/preferences.cpp b/src/preferences.cpp
index c71ffeffc32..e3f8d8515ed 100644
--- a/src/preferences.cpp
+++ b/src/preferences.cpp
@@ -24,6 +24,7 @@
 #include "preferences.hpp"
 #include "sound.hpp"
 #include "util.hpp"
+#include "unit_map.hpp"
 #include "video.hpp" // non_interactive()
 #include "wassert.hpp"
 #include "wesconfig.h"
diff --git a/src/unit.hpp b/src/unit.hpp
index c23006d32d0..dbc31cf7fe7 100644
--- a/src/unit.hpp
+++ b/src/unit.hpp
@@ -19,9 +19,9 @@
 #include "team.hpp"
 #include "unit_types.hpp"
 #include "image.hpp"
-#include "unit_map.hpp"

 class unit;
+class unit_map;
 class display;
 class gamestatus;

@@ -396,16 +396,7 @@ void sort_units(std::vector< unit > &);

 int team_units(const unit_map& units, unsigned int team_num);
 int team_upkeep(const unit_map& units, unsigned int team_num);
-unit_map::const_iterator team_leader(unsigned int side, const unit_map& units);
-std::string team_name(int side, const unit_map& units);
-unit_map::iterator find_visible_unit(unit_map& units,
-       const gamemap::location loc,
-       const gamemap& map,
-       const std::vector<team>& teams, const team& current_team);
-unit_map::const_iterator find_visible_unit(const unit_map& units,
-       const gamemap::location loc,
-       const gamemap& map,
-       const std::vector<team>& teams, const team& current_team);
+

 struct team_data
 {
diff --git a/src/unit_abilities.cpp b/src/unit_abilities.cpp
index 4fa0f6a12ef..8bd4460a056 100644
--- a/src/unit_abilities.cpp
+++ b/src/unit_abilities.cpp
@@ -12,6 +12,7 @@
 */

 #include "unit.hpp"
+#include "unit_map.hpp"
 #include "unit_abilities.hpp"

 #include "wassert.hpp"
diff --git a/src/unit_map.hpp b/src/unit_map.hpp
index e71203af275..555271fd0f0 100644
--- a/src/unit_map.hpp
+++ b/src/unit_map.hpp
@@ -149,4 +149,15 @@ private:
    std::map<gamemap::location,std::pair<gamemap::location,unit>*> map_;
 };

+unit_map::const_iterator team_leader(unsigned int side, const unit_map& units);
+std::string team_name(int side, const unit_map& units);
+unit_map::iterator find_visible_unit(unit_map& units,
+       const gamemap::location loc,
+       const gamemap& map,
+       const std::vector<team>& teams, const team& current_team);
+unit_map::const_iterator find_visible_unit(const unit_map& units,
+       const gamemap::location loc,
+       const gamemap& map,
+       const std::vector<team>& teams, const team& current_team);
+
 #endif // UNIT_MAP_H_INCLUDED
diff --git a/src/upload_log.cpp b/src/upload_log.cpp
index 0718249e9e9..bcf38fcc0d2 100644
--- a/src/upload_log.cpp
+++ b/src/upload_log.cpp
@@ -23,6 +23,7 @@
 #include "upload_log.hpp"
 #include "wesconfig.h"
 #include "wml_separators.hpp"
+#include "unit_map.hpp"

 #include "SDL_net.h"

-- 
2.37.2

j'ai réussi à m'emmerder plus de 10 minutes, du coup j'ai fait compiler, au moins une partie, je me suis arreté au soucis de compatibilité avec freetype2 car un peu la flemme de le compiler (et pas plus de 10 minutes à investir)
où est ce que je peux te poster un patch sans avoir à créer de compte ?

ok, je suis allé voir le code comme un grand, et il y a une dependance circulaire, je me demande comment ce code a pu compiler un jour…

Si demain j'ai la motiv je me lance dans la correction et je le fais compiler. Bien noter le gros SI au début de la phrase…

en effet, c'est le type "unit" qui n'est pas défini, j'ai lu un peu vite désolé.
Du coup il faut les sources pour résoudre ça, tu trouves dans quel fichier "unit" est défini, cherche un truc du genre :

class unit {
ou

struct unit {
et tu inclues le fichier correspondant à la place de utility.
J'avais prévenu que ça n'étais pas une bonne idée de se lancer dedans si tu n'as pas l'habitude de faire du c++

pour la première erreur

const type get_type() const { return val_.type_; };

tu vires le "const" de gauche (le premier mot de la ligne) qui ne sert à rien.

pour la seconde, tu ajoutes un

#include <utility>

en tête du fichier unit_map.hpp, en fin des autres "#include"

ça va résoudre les 2 soucis de compilation que j'ai vu postés par ton pseudo sur le forum (tu aurais pu les mettre ici au passage)
Par contre tu risques d'en avoir plein d'autres. Le C++ évolue, mais pas seulement, les compilateurs aussi, et deviennent de plus en plus strictes avec les versions, ce qui fait que du code qui compilait avec un ancien compilateur se retrouve souvent avec des tas d'erreurs de compilation "triviales" (pour un habitué) mais parfois un peu plus complexes avec un compilateur récent.

Cela étant dit, je ne pense pas que ce soit une bonne idée de te lancer la dedans si tu n'es pas un développeur c++ et que tu ne comptes pas soumettre un patch. Et même dans ce cas, si la version 1.2 n'est plus maintenue, ton patch risque simplement de ne pas être accepté.

Pas d'idée à priori, mais si ça passe à tous les coups avec un strace, il y a des chances que ça soit lié à une race condition.
Genre le filesystem qui met du temps à valider un nouveau fichier (je ne vois pas pourquoi mais bon…) et qui du coup, en passant par le strace, tu es sur que l'opération et finie et que ton fichier est bien présent.
ça peut être nimporte quelle race condition du genre, en général c'est une notif qu'un boulot fait pas un autre process est fini (process se termine, pipe se ferme, …), mais quand tu vas chercher le résultat trop vite derrière, il n'est pas encore là.

Je ne sais pas trop comment débuguer ce genre de chose à la ligne de commande, je tenterais vraiment des trucs au cas par cas.

Une dernière idée si tu veux tenter d'autres trucs, c'est de :
1) tenter de compiler une version debug de dpkg-deb et voir si tu as toujorus le crash
2) remplacer le lancement de dpkg-deb par un appel à "gdb --batch --args dpkg-deb $#" et n'oublie pas de placer un .gdbinit quelque part avec la commande run

quand le sous process va planter (s'il plante) tu auras le prompt gdb et tu pourras tenter de voir ce qu'il se passe.

C'est une solution qui demande un peu d'expérience, et qui a de fortes chance de ne pas marcher cas ça ne plantera pas depuis gdb.
Si c'est le cas et que la version debug crash quand même, tu peux tenter la solution (plus compliquée, et sur android je ne saurais pas comment faire perso) d'installer un crash handler qui va attacher à gdb le process qui plante une fois le crash survenu.

Voila, c'est vraiment si t'as envie de t'amuser tout ça….

Est ce qu'il y a un risque à remplacer ceux de Mint par ceux de Fedora, qui sont peut être plus récents ? Je ne crois pas qu'ils soient spécifiques à la distribution ou au driver utilisé.

Pour le driver, c'est pas sûr que la version firmware ne soit pas importante, tu peux tenter mais garde les tiens en réserve au cas où, même si je pense que ça ne changera rien.

Ce que tu peux tenter ensuite, c'est de voir si le pilote kernel (amdgpu chez moi) à bien chargé le firmware.
Tu filtres dans le log kernel (dmesg, par exemple) les lignes qui contiennent amdgpu et firmware, et tu peux comparer le résultat de ta distribution avec celui de la fedora qui marche

En dernier recours tu peux essayer de voir ce que glxinfo te dit, s'il ne te manque pas des bouts de mesa, que ça soit la partie pilote X ou glx.

Si ça ne t'aide pas, je sèche un peu là.

Pour la puce radeon vega 7 integrée également à un chip rizen, il faut un firware amd pour avoir l'accéleration 3D
Sous debian c'est dans le paquet firmware-amd-graphics
les firmwares installées se retrouvent dans /lib/firmware/amdgpu/xxx.bin

j'ai aussi une balcklist que je récupère de temps en temps du log fail2ban et que j'ajoute dans mes regles de parefeu.
je garde la liste complete des ip dans une coin, et j'ai un petit bout de code qui les lis et fusionne dans une ip de classe supérieure à partir d'un certain nombre de classe inférieur (configurable, j'utilise 5, quand j'ai 5 ips dans la même classe qui me foutent la merde, je banni toute la classe sans pitié)
ça réduit la taille de la blacklist.

Pareil, et au bout de 2 erreurs je banni 3 jours (d'ailleurs je devrais bannir à vie…)
en cas d'erreur de ma part, j'attends de rentrer me reconnecter en direct pour unban

Ça s’installe dans /opt/qxmledit et pour l’instant je n’observe pas d’intégration (menu ou PATH). Peut-être au prochain redémarrage… Donc en attendant, je dois faire

tu peux aussi mettre ça dans un petit script tout fait, et créer un fichier .desktop qui référence ton script et que tu intègres à ton menu ;)
(sous KDE, click droit -> éditer les applications, il y a certainement des équivalents sur les autres environements de bureau)

checkinstall, je connais pas. À l‘occasion je regarderai…

ça fait un "make install" dans un fakeroot et construit un .deb avec le résultat.
ça te permet de facilement l'installer et désinstaller de ton système sans laisser trainer des fichiers et en évitant les conflits avec d'autres paquets s'il y en a.
Dans le temps il fallait être root pour le lancer, ce que je trouve dommage. Je ne sais pas si ce point s'est amélioré depuis.

Quand ça fonctionne, c’est cool. Mais il suffit de quelque galères pour être ensuite découragé à l’avance.

Oui, quand ça merde et qu'on n'a pas l'habitude de compiler, c'est vite décourageant…

Je suis allée voir le répo, et il y a un script compile.sh qui fait ce qui va bien, tu aurais pu directement le lancer ou t'en inspirer.
Il ne faut pas hésiter à lire les README et autres INSTALL avant de se lancer dans la compilation, souvent quand il y a un ou deux trucs pas habituels, ils sont explicités dedans ;)

Si tu sais faire, tu peux simplement te le compiler toi même.
Je fais ça très souvent quand un logiciel opensource n'est pas dispo dans les dépot et je n'ai eu que rarement des soucis que j'ai toujours su résoudre, mais il faut un peu d'expérience en compilation.
Ensuite soit tu le lances depuis le dossier de compilation, soit tu utilises "checkinstall" qui te crée un deb (ça fait hyper longtemps que je ne l'ai pas utilisé celui là tiens…)

Attention, si c'est un fichier temporaire, il se peut qu'il soit supprimé par dpkg quand dpkg-split échoue.
Pour être sur qu'il est bien manquant, fait le test depuis ton script dpkg-split que tu as mis en place pour creuser le problème.