Forum Flightgear France

Une communauté prend son envol

Vous n'êtes pas identifié(e).

Annonce

Futur nouvel inscrit, tu dois au préalable lire l'intégralité des 10 articles des règles, s'il te plaît. Tout nouveau compte qui ne respecte pas les règles sera supprimé par l'administration.

#76 12/07/2018 15:47:30

f-toro
Administrateur
Lieu : LFLA
Inscription : 16/12/2007
Messages : 2 511

Re : Script download_and_compile.sh

Ça doit bien sûrement se trouver par là...


André. anciennement taureau89_9
Debian Testing Amd64. CM Sabertooth 990FX, FX8350, 32 Go Ram DDR3 1866 Mhz, GTX 750ti 2Go, DD 2To Sata 3, THRUSTMASTER T.Flight StickX, FG 2019.2.0 Git.

Hors ligne

#77 12/07/2018 15:58:05

dany93
Administrateur
Lieu : Région Parisienne
Inscription : 5/07/2009
Messages : 2 997

Re : Script download_and_compile.sh

Il y a une ligne de commande qui permet de télécharger un seul ou tous les avions depuis SVN. Je suis en train de faire autre chose et je ne trouve pas immédiatement. Je continuerai après si tu n'as pas trouvé d'ici là


FG 2019.2.0, Linux Mint 18 (64b), Quad Q6600 (2.4 GHz), RAM 8Go DDR2, GEFORCE GTX 650 1GB, OSG 3.4.2
Boeing 787-8 (YASim, avec nickyivyca, aco)
DR400 JSBSim (PAF)
DC3 JSBSim (PAF)

Hors ligne

#78 12/07/2018 16:12:15

dany93
Administrateur
Lieu : Région Parisienne
Inscription : 5/07/2009
Messages : 2 997

Re : Script download_and_compile.sh

FGAddon > Obtaining Aircraft > Download > Command line.


FG 2019.2.0, Linux Mint 18 (64b), Quad Q6600 (2.4 GHz), RAM 8Go DDR2, GEFORCE GTX 650 1GB, OSG 3.4.2
Boeing 787-8 (YASim, avec nickyivyca, aco)
DR400 JSBSim (PAF)
DC3 JSBSim (PAF)

Hors ligne

#79 30/07/2018 11:02:28

PierreBM
Membre
Lieu : Canet en Roussillon
Inscription : 11/10/2013
Messages : 49

Re : Script download_and_compile.sh

Bonjour
A défaut d'arriver à un résultat satisfaisant par le script, je suis passé pendant quelques temps à la version téléchargée.
Je viens de reprendre, ou du moins essayer de reprendre, la méthode script-compilée, mais ça ne donne pas l'effet escompté.
Quelque chose m'a probablement échappé.
Voici le résultat de ma manip :

./download_and_compile.sh DATA
VERSION=$Id
APT_GET_UPDATE=y
DOWNLOAD_PACKAGES=y
COMPILE=y
RECONFIGURE=y
DOWNLOAD=y
JOPTION= -j4 
OOPTION=
BUILD_TYPE=RelWithDebInfo
***********************************
Considering a package alternative: libcurl4-openssl-dev libcurl4-gnutls-dev
Package alternative matched for libcurl4-openssl-dev
Considering a package alternative: libopenscenegraph-3.4-dev libopenscenegraph-dev libopenscenegraph-[0-9]+\.[0-9]+-dev
Package alternative matched for libopenscenegraph-dev
Considering a package alternative: libpng-dev libpng12-dev libpng16-dev
Package alternative matched for libpng12-dev
Considering an optional package alternative: qml-module-qtquick2
Optional package alternative matched for qml-module-qtquick2
Considering an optional package alternative: qml-module-qtquick-window2
Optional package alternative matched for qml-module-qtquick-window2
Considering an optional package alternative: qml-module-qtquick-dialogs
Optional package alternative matched for qml-module-qtquick-dialogs
Considering an optional package alternative: qtbase5-private-dev
Optional package alternative matched for qtbase5-private-dev
Considering an optional package alternative: qtdeclarative5-private-dev
Optional package alternative matched for qtdeclarative5-private-dev
DIRECTORY= /home/pierre/fgfs
***********************************
****************************************
************** FLIGHTGEAR **************
****************************************
****************************************
**************** DATA ******************
****************************************



pierre@pierre-Aspire-MC605:~$ cd fgfs
pierre@pierre-Aspire-MC605:~/fgfs$ ./download_and_compile.sh -j4 DATA
**************************************
*                                    *
* Warning, the compilation process   *
* is going to use 12 or more Gbytes  *
* of space and at least a couple of  *
* hours to download and build FG.    *
*                                    *
* Please, be patient ......          *
*                                    *
**************************************
Asking password for 'apt-get update'...
[sudo] Mot de passe de pierre : 
Atteint:1 http://deb.playonlinux.com trusty InRelease
Atteint:2 http://fr.archive.ubuntu.com/ubuntu xenial InRelease                 
Ign:3 http://dl.google.com/linux/earth/deb stable InRelease                    
Réception de:4 http://security.ubuntu.com/ubuntu xenial-security InRelease [107 kB]
Atteint:5 http://ppa.launchpad.net/opencpn/opencpn/ubuntu xenial InRelease     
Atteint:6 http://fr.archive.ubuntu.com/ubuntu xenial-updates InRelease         
Atteint:7 http://dl.google.com/linux/earth/deb stable Release                  
Réception de:8 http://fr.archive.ubuntu.com/ubuntu xenial-backports InRelease [107 kB]
Atteint:9 http://archive.canonical.com/ubuntu xenial InRelease                 
214 ko réceptionnés en 1s (158 ko/s)                                           
Lecture des listes de paquets... Fait
N: Le fichier configuré « main/binary-i386/Packages » ne sera pas pris en compte car le dépôt « http://dl.google.com/linux/earth/deb stable InRelease » ne supporte pas l'architecture « i386 »
Considering a package alternative: libcurl4-openssl-dev libcurl4-gnutls-dev
Package alternative matched for libcurl4-openssl-dev
Considering a package alternative: libopenscenegraph-3.4-dev libopenscenegraph-dev libopenscenegraph-[0-9]+\.[0-9]+-dev
Package alternative matched for libopenscenegraph-dev
Considering a package alternative: libpng-dev libpng12-dev libpng16-dev
Package alternative matched for libpng12-dev
Considering an optional package alternative: qml-module-qtquick2
Optional package alternative matched for qml-module-qtquick2
Considering an optional package alternative: qml-module-qtquick-window2
Optional package alternative matched for qml-module-qtquick-window2
Considering an optional package alternative: qml-module-qtquick-dialogs
Optional package alternative matched for qml-module-qtquick-dialogs
Considering an optional package alternative: qtbase5-private-dev
Optional package alternative matched for qtbase5-private-dev
Considering an optional package alternative: qtdeclarative5-private-dev
Optional package alternative matched for qtdeclarative5-private-dev
Asking password for 'apt-get install build-essential cmake git libcurl4-openssl-dev libarchive-dev libbz2-dev libexpat1-dev libjsoncpp-dev liblzma-dev libncurses5-dev procps zlib1g-dev libcgal-dev libgdal-dev libtiff5-dev libqt4-dev zlib1g-dev freeglut3-dev libboost-dev libopenscenegraph-dev libopenal-dev libudev-dev qt5-default qtdeclarative5-dev libdbus-1-dev libplib-dev libpng12-dev qml-module-qtquick2 qml-module-qtquick-window2 qml-module-qtquick-dialogs qtbase5-private-dev qtdeclarative5-private-dev fluid libbz2-dev libfltk1.3-dev libxi-dev libxmu-dev libxinerama-dev libjpeg-dev libxft-dev python3-pyqt5 python3-pyqt5.qtmultimedia libqt5multimedia5-plugins python-tk'...
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances       
Lecture des informations d'état... Fait
build-essential est déjà la version la plus récente (12.1ubuntu2).
libboost-dev est déjà la version la plus récente (1.58.0.1ubuntu1).
libbz2-dev est déjà la version la plus récente (1.0.6-8).
libjpeg-dev est déjà la version la plus récente (8c-2ubuntu8).
libjsoncpp-dev est déjà la version la plus récente (1.7.2-1).
liblzma-dev est déjà la version la plus récente (5.1.1alpha+20120614-2ubuntu2).
libncurses5-dev est déjà la version la plus récente (6.0+20160213-1ubuntu1).
libqt4-dev est déjà la version la plus récente (4:4.8.7+dfsg-5ubuntu2).
libqt5multimedia5-plugins est déjà la version la plus récente (5.5.1-4ubuntu2).
libxft-dev est déjà la version la plus récente (2.3.2-1).
libxi-dev est déjà la version la plus récente (2:1.7.6-1).
libxinerama-dev est déjà la version la plus récente (2:1.1.3-1).
libxmu-dev est déjà la version la plus récente (2:1.1.2-2).
qml-module-qtquick-dialogs est déjà la version la plus récente (5.5.1-1ubuntu1).
qml-module-qtquick-window2 est déjà la version la plus récente (5.5.1-2ubuntu6).
qml-module-qtquick2 est déjà la version la plus récente (5.5.1-2ubuntu6).
qtdeclarative5-dev est déjà la version la plus récente (5.5.1-2ubuntu6).
qtdeclarative5-private-dev est déjà la version la plus récente (5.5.1-2ubuntu6).
fluid est déjà la version la plus récente (1.3.3-7).
freeglut3-dev est déjà la version la plus récente (2.8.1-2).
libcgal-dev est déjà la version la plus récente (4.7-4).
libfltk1.3-dev est déjà la version la plus récente (1.3.3-7).
libgdal-dev est déjà la version la plus récente (1.11.3+dfsg-3build2).
libopenal-dev est déjà la version la plus récente (1:1.16.0-3).
libopenscenegraph-dev est déjà la version la plus récente (3.2.1-7ubuntu4).
libplib-dev est déjà la version la plus récente (1.8.5-7).
python3-pyqt5 est déjà la version la plus récente (5.5.1+dfsg-3ubuntu4).
python3-pyqt5.qtmultimedia est déjà la version la plus récente (5.5.1+dfsg-3ubuntu4).
cmake est déjà la version la plus récente (3.5.1-1ubuntu3).
git est déjà la version la plus récente (1:2.7.4-0ubuntu1.4).
libarchive-dev est déjà la version la plus récente (3.1.2-11ubuntu0.16.04.3).
libcurl4-openssl-dev est déjà la version la plus récente (7.47.0-1ubuntu2.8).
libdbus-1-dev est déjà la version la plus récente (1.10.6-1ubuntu3.3).
libexpat1-dev est déjà la version la plus récente (2.1.0-7ubuntu0.16.04.3).
libpng12-dev est déjà la version la plus récente (1.2.54-1ubuntu1.1).
libtiff5-dev est déjà la version la plus récente (4.0.6-1ubuntu0.4).
libudev-dev est déjà la version la plus récente (229-4ubuntu21.2).
procps est déjà la version la plus récente (2:3.3.10-4ubuntu2.4).
python-tk est déjà la version la plus récente (2.7.12-1~16.04).
qtbase5-private-dev est déjà la version la plus récente (5.5.1+dfsg-16ubuntu7.5).
zlib1g-dev est déjà la version la plus récente (1:1.2.8.dfsg-2ubuntu4.1).
qt5-default est déjà la version la plus récente (5.5.1+dfsg-16ubuntu7.5).
Les paquets suivants ont été installés automatiquement et ne sont plus nécessaires :
  libhtsengine1 libjs-excanvas libjs-jquery-flot libjs-leaflet libsimgearcore3.4.0v5 libsimgearscene3.4.0v5
Veuillez utiliser « sudo apt autoremove » pour les supprimer.
0 mis à jour, 0 nouvellement installés, 0 à enlever et 0 non mis à jour.
****************************************
************** FLIGHTGEAR **************
****************************************
****************************************
**************** DATA ******************
****************************************
Clonage dans '.'...
remote: Counting objects: 63419, done.
remote: Compressing objects: 100% (28757/28757), done.
error: RPC failed; curl 56 GnuTLS recv error (-110): The TLS connection was non-properly terminated.
fatal: The remote end hung up unexpectedly
fatal: fin de fichier prématurée
fatal: index-pack failed
pierre@pierre-Aspire-MC605:~/fgfs$ 

Pour l'instant j'en suis réduit à plier du papier et à essayer d'atteindre le mur d'en face, au moins pas besoin de joystick


Ubuntu 18.04 fgfs 3.4.0
Aspire 605 RAM 3,8 Gio IntelCore i5-3350P
cpu 3,10 gHZ X 4  Carte graph Nvidia GF 119

Hors ligne

#80 30/07/2018 12:28:32

ctesc356
Membre
Inscription : 18/05/2010
Messages : 2 717

Re : Script download_and_compile.sh

Bonjour,
je pense que tu trouveras la solution ici: http://fr.flightgear.org/forums/viewtop … 697#p41697


Intel i5 3570 3.4Mhz, Nvidia GTX 660, 8Go Ram, Linux Mint

Hors ligne

#81 30/07/2018 14:54:59

f-toro
Administrateur
Lieu : LFLA
Inscription : 16/12/2007
Messages : 2 511

Re : Script download_and_compile.sh

Bonjour PierreBM.

Le problème est en effet bien connu et la solution a déjà été décrite plusieurs fois sur le forum.

Je pense que en te donnant la solution, ctesc356 veut surtout parler de son message.
Où il est question de la ligne 612.

Tout ca est expliqué dans le tuto de Dany93.


André. anciennement taureau89_9
Debian Testing Amd64. CM Sabertooth 990FX, FX8350, 32 Go Ram DDR3 1866 Mhz, GTX 750ti 2Go, DD 2To Sata 3, THRUSTMASTER T.Flight StickX, FG 2019.2.0 Git.

Hors ligne

#82 27/09/2018 11:38:17

dany93
Administrateur
Lieu : Région Parisienne
Inscription : 5/07/2009
Messages : 2 997

Re : Script download_and_compile.sh

Complément important.

Florent Rougon a apporté des modifications importantes à d&c. Ce lien, inchangé (sauf https).

Voir son message dans Flightgear-devel.

Voir aussi, dans ce message, ma tentative (approximative) de résumé.

Beaucoup mieux, je cite ci-dessous les très longues explications qu'il a rédigées lui-même. Qui commencent par rectifier mes approximations.

Qu'il soit ici remercié pour ce double travail de codage et d'explications (sans lesquelles ce code serait pratiquement inutilisable pour la plupart d'entre nous).

Florent Rougon a écrit :

1) SourceForge n'est pas un protocole. C'est une plateforme
   d'hébergement (“hosting site” dans ce que j'ai écrit sur d&c.sh).

2) “SourceForge pour DATA, https pour update”, ça ne veut pas dire
   grand-chose, d'une part à cause du point 1) et d'autre part parce que
   DATA (FGData) est un des composants logiciels que d&c.sh peut
   récupérer et compiler (c'est un COMPONENT dans le texte qui est
   affiché quand on lance 'download_and_compile.sh --help'), alors que
   “update” veut juste dire mettre à jour ou mise à jour. Les deux ne
   se placent donc pas sur le même plan.

Ce qu'il faut comprendre, c'est que quand on demande à d&c.sh de
s'occuper d'un composant récupéré avec Git (SimGear, FlightGear, FGData,
etc., c'est-à-dire SIMGEAR, FGFS, DATA, etc. en parlance d&c.sh), la
récupération du code/contenu à jour peut se faire de deux manières
différentes :

  (a) Si d&c.sh ne trouve pas le dépôt déjà rempli (il regarde juste
      s'il y a un README, README.txt ou README.rst...), il le /clone/
      (c'est-à-dire qu'il effectue un téléchargement complet du dépôt
      avec tout l'historique Git) ;

  (b) Sinon, il fait juste une mise à jour (update), qui consiste
      essentiellement en un 'git pull --rebase'. C'est beaucoup plus
      rapide que de cloner, surtout si on le fait souvent, et d'autant
      plus si le contenu et son historique sont volumineux (FGData...).

L'opération (a) ('git clone ...') utilise https par défaut, mais les
nouvelles options permettent un choix plus fin sans avoir à modifier
d&c.sh (ce qui cause toujours des problèmes pour le mettre à jour) :

  - avec --git-clone-default-proto, on peut changer le protocole par
    défaut, par exemple --git-clone-default-proto=git pour utiliser le
    protocole Git (le protocole historique qui n'est pas chiffré) ;

  - pour utiliser ssh, c'est un peu plus compliqué car il faut fournir
    un nom d'utilisateur (username), et celui-ci n'est pas forcément le
    même pour toi, moi, etc. sur les différentes plateformes
    d'hébergement. Par exemple, je suis frougon sur SourceForge et sur
    GitHub, mais je pourrais très bien avoir choisi des noms
    d'utilisateur différents sur l'une et l'autre de ces plateformes.
    C'est pour ça que l'option --git-clone-site-params permet de faire
    un réglage différent pour chaque plateforme. Par exemple, si mon
    compte sur GitHub s'appelait 'flo', je pourrais vouloir faire :

    download_and_compile.sh \
      --git-clone-site-params SourceForge=ssh:frougon \
      --git-clone-site-params GitHub=ssh:flo

    ce qui est identique à :

    download_and_compile.sh \
      --git-clone-site-params=SourceForge=ssh:frougon \
      --git-clone-site-params=GitHub=ssh:flo

    La casse est ignorée pour les noms de plateformes et de protocoles,
    donc on pourrait écrire sourceforge, githUB et sSh, ça ne changerait
    rien.

    Chaque option --git-clone-site-params s'applique à tous les dépôts
    (repositories) téléchargés par d&c.sh depuis la plateforme
    d'hébergement mentionnée au début de l'argument. Par exemple,
    SimGear, FlightGear et FGData sont tous hébergés sur SourceForge,
    donc une seule option telle que :

      --git-clone-site-params SourceForge=ssh:frougon ou
      --git-clone-site-params SourceForge=https       ou
      --git-clone-site-params SourceForge=git

    s'applique à tous les trois (et bien d'autres dépôts gérés par
    d&c.sh) si le script décide qu'il faut cloner leurs dépôts Git.

Une fois qu'un dépôt a été cloné, le protocole et le nom d'utilisateur
sont enregistrés par Git dans le fichier .git/config à l'intérieur du
dépôt, comme j'ai indiqué sur flightgear-devel. Par exemple :

[remote "origin"]
        url = ssh://frougon@git.code.sf.net/p/flightgear/fgmeta
        fetch = +refs/heads/*:refs/remotes/upstream/*

(On peut lancer

find -type f -path '*/.git/config'

depuis le répertoire
de travail pour trouver tous ces fichiers)

Lorsqu'un dépôt est mis à jour par un 'git pull', 'git fetch', etc.
(opération (b)), ce que fait d&c.sh lorsqu'il détecte un des fichiers
mentionnés ci-dessus (README, README.txt ou README.rst), Git utilise la
méthode (protocole, nom d'utilisateur éventuel) enregistrée dans le
fichier .git/config. Dans ce cas, les options --git-clone-default-proto
et --git-clone-site-params n'ont aucun effet puisqu'elles n'affectent
que l'opération de clonage (téléchargement initial). Bien sûr, on peut
effacer un dépot et d&c.sh va le recloner, mais si on veut juste changer
le protocole et/ou le nom d'utilisateur, le plus simple est d'éditer le
fichier .git/config du ou des dépôts pour lesquels on veut changer le
protocole (et/ou le nom d'utilisateur).

Maintenant, à propos du “mix” possible que j'ai évoqué. Puisque c'est
FGData qui est récalcitrant en https, et apparemment lui seul, rien
n'empêche de configurer tous les dépôts en https et seulement FGData en
autre chose (soit le protocole 'git' qui n'est pas très sûr, soit 'ssh'
comme j'ai expliqué sur la mailing-list). Et pour ce faire, on peut
modifier simplement une ligne dans les fichiers .git/config des
différents dépôts, ou bien (re-)partir de zéro comme indiqué sur
flightgear-devel :

  # Cloner seulement FGData avec le protocole SSH (pour que ça clone
  # vraiment, s'assurer qu'il n'y a rien dans install/flightgear/fgdata là
  # où download_and_compile.sh est lancé !) :
  download_and_compile.sh --git-clone-site-params SourceForge=ssh:dany DATA

puis cloner le reste :

  # Si on ne passe aucun argument COMPONENT, d&c.sh va mettre à jour
  # FGData et, si les autres dépôts sont absents, cloner SimGear et
  # FlightGear ; ceci parce que le WHATTOBUILDALL du script est
  # (SIMGEAR FGFS DATA).
  download_and_compile.sh

Là, je n'ai pas spécifié de protocole, donc ça va utiliser https pour
les dépôts clonés. FGData, qui est déjà là, va être mis à jour sans
changement de protocole.

J'espère que c'est plus clair.

Florent Rougon a écrit :

En résumé (j'ai un peu peur de t'avoir noyé dans les explications) :

  - si d&c.sh doit installer ou mettre à jour un composant depuis un
    dépôt Git et qu'il ne le trouve pas à l'endroit attendu sous le
    répertoire courant, il va faire un 'git clone' et utiliser le
    contenu des éventuelles options --git-clone-default-proto et
    --git-clone-site-params (en se rabattant sur https si aucune n'a été
    passée) ;

  - si d&c.sh doit « traiter » un dépôt Git et qu'il le trouve à
    l'endroit attendu, il va faire essentiellement un
    'git pull --rebase', lequel utilise le protocole (et éventuellement
    nom d'utilisateur) indiqué dans le fichier .git/config à l'intérieur
    du dépôt.

C'est l'essentiel, cela doit être digérable, je pense. Par ailleurs,
comme les lignes de commande peuvent être un peu longues, il est
souhaitable, à mon avis, soit d'utiliser l'historique du shell pour
rappeler la dernière commande download_and_compile.sh, soit de se créer
un alias (dans le shell utilisateur : Bash, Zsh, etc.) ou un mini-script
shell contenant la commande avec les options souhaitées.

Les options courtes de download_and_compile.sh sont déjà assez
chargées ; pour les nouvelles options courtes, on est à chaque fois
obligé de choisir une lettre (ou un chiffre !) parmi celles qui restent,
et petit à petit, il devient très difficile et hasardeux de dire de
mémoire quelle option fait quoi. C'est pourquoi j'ai introduit getopt
pour pouvoir utiliser des options longues (du genre --faire-machin-truc)
qui sont beaucoup plus explicites et ne présentent pas le problème de
rareté des options courtes. Les futures options courtes ne devraient
être utilisées, à mon avis, que pour des choses jugées vraiment très
importantes.


FG 2019.2.0, Linux Mint 18 (64b), Quad Q6600 (2.4 GHz), RAM 8Go DDR2, GEFORCE GTX 650 1GB, OSG 3.4.2
Boeing 787-8 (YASim, avec nickyivyca, aco)
DR400 JSBSim (PAF)
DC3 JSBSim (PAF)

Hors ligne

#83 22/03/2019 18:47:46

dany93
Administrateur
Lieu : Région Parisienne
Inscription : 5/07/2009
Messages : 2 997

Re : Script download_and_compile.sh

Message de Florent Rougon à notre intention (francophones).

Florent Rougon a écrit :

1) Suite à une suggestion d'un lecteur de flightgear-devel, j'ai fait
   une petite mise à jour[1] (ça fait déjà un mois). Cela devrait aller
   un peu plus vite pour les gens qui compilent avec -pn, car les tests
   portant sur les packages disponibles (et non sur les packages
   installés) ne devaient pas leur être bien utiles auparavant. L'idée,
   c'est que la première fois qu'on utilise le script, on passe -py ou
   aucune option -p. download_and_compile.sh cherche alors les
   dépendances disponibles dans la distribution Linux (via APT) et
   installe tout ce qui est nécessaire. Par la suite, on peut compiler
   avec -pn, ce qui fait gagner un peu de temps ; et si un jour on
   rencontre un problème, avant de demander de l'aide, on passe à
   nouveau -py (ou pas d'option -p) pour s'assurer qu'il n'y a pas de
   nouvelle dépendance à installer.

   Il y a aussi les nouvelles options --package-manager et --sudo, je te
   laisse regarder la documentation en anglais
   ('download_and_compile.sh --help' ou [1]). Rien de révolutionnaire
   dans ces nouvelles options, mais elles peuvent s'avérer pratiques,
   par exemple --sudo=echo pour voir les commandes apt-get/aptitude/etc.
   sans les exécuter (la compilation va quand même commencer si on
   laisse faire, mais un petit Ctrl-C permet de l'interrompre sans
   problème).

2) Concernant les contournements visant à pallier le manque de fiabilité
   de 'git clone' pour FGData en 'https', je vois que le protocole
   obsolète 'git' est encore largement utilisé et même conseillé, je
   trouve que c'est dommage. À l'heure actuelle, je n'ai pas
   connaissance d'attaques en place profitant du fait que le protocole
   'git' ne permet pas d'authentifier le serveur (donc la provenance de
   ce que l'on télécharge avec ce protocole), mais cela ne prouve pas
   l'inexistence présente ou future de telles attaques, d'autant que
   SHA-1, l'algorithme utilisé par Git pour calculer les identifiants
   des commits, a été « un peu » affaibli depuis quelques années
   (cf. travaux[2] publiés par Google).

   Comme je l'ai déjà expliqué plusieurs fois[3][4], une manière sûre de
   contourner ce problème consiste à utiliser le protocole 'ssh' — qui
   n'a pas grand-chose à voir avec 'https', contrairement à ce que
   croient certains. Il y a quelques prérequis pour cela, ce n'est pas
   très compliqué mais il faut quand-même lire un peu. J'ai écrit un
   tutoriel en français[5] sur le wiki FlightGear qui explique comment
   mettre en place l'authentification par paire de clés (publique,
   privée) dans le but d'utiliser le protocole ssh de manière
   confortable (avec ssh-agent ou équivalent).

   Cela peut servir pour n'importe quelle connexion SSH, et en
   particulier pour celles faites par Git quand on utilise une URL du
   type ssh://frougon@git.code.sf.net/p/flightgear/flightgear avec la
   commande 'git clone', URL qui se retrouve dans le fichier .git/config
   à l'intérieur du dépôt un fois le clonage terminé et définit le
   protocole utilisé par les opérations ultérieures effectuées au sein
   de ce même dépôt ('git pull', 'git fetch', 'git push'...). Cela peut
   aussi servir avec Subversion puisqu'il peut travailler avec des URLs
   du type svn+ssh://..., et bien-sûr avec download_and_compile.sh
   (c'est par dépit de voir que « les gens » préfèrent utiliser git://
   plutôt que les nouvelles possibilités plus sûres disponibles avec
   l'option --git-clone-site-params=SourceForge=ssh:nom_utilisateur_SF
   que j'ai écrit le tutoriel[5]).

3) WHATTOBUILDALL

   Il semble à la mode sur le forum francophone de modifier
   WHATTOBUILDALL directement dans download_and_compile.sh. Bof bof...
   ça complique inutilement les mises à jour (de FGMeta ou
   spécifiquement download_and_compile.sh). Je ne sais pas pour les
   premières versions, mais les versions actuelles de
   download_and_compile.sh devraient être assez souples pour qu'on n'ait
   pas besoin de les modifier pour les besoins courants. Concernant ce
   WHATTOBUILDALL, il suffit de passer les arguments correspondant à ce
   que l'on veut télécharger et compiler, par exemple :

     download_and_compile.sh CMAKE SIMGEAR FGFS DATA

   Les composants disponibles (tels que CMAKE, SIMGEAR, FGFS et DATA)
   peuvent être obtenus en faisant :

     download_and_compile.sh --help

   Au passage, les trois commandes suivantes sont équivalentes :

     download_and_compile.sh
     download_and_compile.sh ALL
     download_and_compile.sh SIMGEAR FGFS DATA

   Je trouve regrettable que ALL ait ce sens, mais c'était déjà ainsi
   quand j'ai commencé à toucher à download_and_compile.sh, sauf erreur.
   Il vaudrait mieux à mon avis que ALL fasse télécharger et compiler
   tout ce qu'il y a dans WHATTOBUILD_AVAIL, c'est-à-dire

     'CMAKE' 'PLIB' 'OPENRTI' 'OSG' 'SIMGEAR' 'FGFS' 'DATA' 'FGRUN'
     'FGO' 'FGX' 'OPENRADAR' 'ATCPIE' 'TERRAGEAR' 'TERRAGEARGUI'

   mais si je change ça et que certaines personnes utilisent déjà ALL au
   lieu des deux autres possibilités équivalentes, ça ne va plus marcher
   comme elles en ont l'habitude et elles ne vont pas être contentes...
   Bref, mon conseil serait de ne jamais utiliser ALL, mais je ne suis
   pas sûr que je vais changer son interprétation.

4) Un peu la suite du point 3) : je suppose que si certaines personnes
   modifient le script alors qu'il suffit a priori de lui passer les
   options adéquates, c'est pour n'avoir à taper rien d'autre que
   download_and_compile.sh. Auquel cas, je recommanderais plutôt une des
   trois solutions suivantes :

   (a) Écrire un mini-script par exemple dans ~/bin, en supposant que
       votre PATH contient $HOME/bin. Ce mini-script aurait la tête
       suivante :

#! /bin/sh

cd /répertoire/que/vous/voulez
/chemin/vers/download_and_compile.sh <arguments de votre choix>

       Faites un 'chmod a+x fichier_contenant_le_mini-script' et le tour
       est joué.

   (b) Créer un alias du genre :

       alias my-download_and_compile.sh='cd /répertoire/que/vous/voulez && /chemin/vers/download_and_compile.sh <arguments de votre choix>'

       Avec Zsh, vous pouvez mettre ça dans ~/.zshrc. Avec Bash, dans
       ~/.bashrc ou encore dans un fichier ~/.bash_aliases à
       éventuellement créer comme indiqué ici[6], par exemple. On peut
       bien sûr faire la même chose avec Zsh (mettre les aliases dans un
       fichier séparé).

       Une fois l'alias déclaré, il suffit généralement pour l'activer :
         - de relancer le shell, par exemple avec 'exec zsh' ou
           'exec bash', ou encore en ouvrant un nouveau terminal ;
         - ou de faire 'source ~/.bash_aliases' si l'on a utilisé un
           fichier ne contenant que des déclarations d'aliases comme
           proposé dans le lien [6].

   (c) Créer une fonction au niveau du shell, par exemple :

my-download_and_compile.sh() {
    cd /répertoire/que/vous/voulez && \
    /chemin/vers/download_and_compile.sh <arguments de votre choix>
}

       (syntaxe correcte pour Bash et pour Zsh)

       C'est comme un alias mais un peu plus lisible et plus puissant,
       notamment car on peut utiliser les paramètres positionnels $1,
       $2, etc., comme si my-download_and_compile.sh était un
       exécutable. Pour activer la fonction, c'est en général à peu près
       comme pour activer un alias : mettre dans ~/.bashrc, ~/.zshrc ou
       l'équivalent avec votre shell, ou encore dans un fichier séparé
       chargé par votre ~/.bashrc ou ~/.zshrc, etc., puis recharger le
       fichier en question ou relancer le shell .

   L'avantage de garder un download_and_compile.sh intact, c'est que
   vous pouvez vous contenter de faire 'git pull' dans votre clone
   FGMeta pour le mettre à jour. Clone que vous pouvez obtenir comme
   d'habitude avec :

     git clone https://git.code.sf.net/p/flightgear/fgmeta

   ou bien, si vous avez un compte chez SourceForge et avez lu le
   tutoriel [5], ou êtes prêt à taper votre mot de passe SourceForge à
   chaque fois :

     git clone ssh://nom_utilisateur_SF@git.code.sf.net/p/flightgear/fgmeta

   (où nom_utilisateur_SF représente votre login chez SourceForge)

Voilà, j'espère que ces petits conseils aideront un peu mes camarades
francophones...

Amicalement

[1] https://sourceforge.net/p/flightgear/fg … f49e2c70b/
[2] https://security.googleblog.com/2017/02 … ision.html
[3] https://sourceforge.net/p/flightgear/ma … /36425031/
[4] https://sourceforge.net/p/flightgear/ma … /36511334/
[5] http://wiki.flightgear.org/User:Rominet
[6] https://askubuntu.com/a/17537

--
Florent


FG 2019.2.0, Linux Mint 18 (64b), Quad Q6600 (2.4 GHz), RAM 8Go DDR2, GEFORCE GTX 650 1GB, OSG 3.4.2
Boeing 787-8 (YASim, avec nickyivyca, aco)
DR400 JSBSim (PAF)
DC3 JSBSim (PAF)

Hors ligne

#84 23/03/2019 1:16:48

ctesc356
Membre
Inscription : 18/05/2010
Messages : 2 717

Re : Script download_and_compile.sh

Bonsoir,
j'ai parcouru vite fait.
Tout d'abord un grand merci pour la maintenance du script.

1) C'est parfait, avec -pn on ne passe plus en revue les dépendances optionnelles.
     Pas encore essayé les autres options, mais j'y pense.

2) Là, il faut que je m'y penche, tête reposée et aspirine à portée de main. smile tant qu'on a pas de souci on pense que ça n'arrivera pas...

3) Pour moi la variable "WHATTOBUILDALL" est inutile. Je la "vide" systématiquement. Je rentre les paramètres dans la ligne de commande.
    En plus ça permet, si on lance sans aucun paramètre de ne faire que le apt/update/install. Ok on peut toujours interrompre par "ctrl-c" mais bon...
    Je ne clone pas fgmeta, je dn le script si je vois une modif. Primitif, mais on a ses petites habitudes wink
    Par contre je n'ai jamais rien compris à la déclaration de version...

4) Ouais... bon... ça me semble un peu "prise de tête" pour pas grand chose.

Un souhait: déplacer le "mkdir -p "openscenegraph" dans le bloc "if _elementIn..." comme pour les autres options, ça éviterait la création d'un un dossier "openscenegraph" vide si on ne choisit pas OSG. 

Une interrogation: Ne pourrait'on pas supprimer la clause "BACKWARD COMPATIBILITY WITH 1.9.14a" ?


Intel i5 3570 3.4Mhz, Nvidia GTX 660, 8Go Ram, Linux Mint

Hors ligne

#85 23/03/2019 11:40:17

Patten
Membre
Lieu : LFLR
Inscription : 14/12/2010
Messages : 1 658
Site Web

Re : Script download_and_compile.sh

Merci Daniel, Florent, Ernest. wink

smile


Intel I7.7700k 4.2 GHz 4 C 8 tr.MSI Gaming pro.MSI GTX 1080 Armor 8Go.Ram:16Go DDR4 GSKILL 3000Mhz.Stock:2*480Go SSD Kingston UV 400+2*2T HDD Seagate Baracuda.Alim:Corsair RM750X 80Plus Gold.Ventirad Be quiet pure rock.Boîtier Aérocool GT-S black édition.DVD Asus drw-24f1-mt. Wifi + Bluetooth gigabyte.Dual boot LinuxMint 18.3 Sylvia/Windows10 FG2019.2
http://pattenflightgear.wifeo.com/

Hors ligne

#86 23/03/2019 19:23:55

rominet
Membre
Inscription : 23/03/2019
Messages : 61

Re : Script download_and_compile.sh

Réponses à quelques questions vues par ici :

ctesc356 a écrit :

2) Là, il faut que je m'y penche, tête reposée et aspirine à portée de main. smile tant qu'on a pas de souci on pense que ça n'arrivera pas...

La méthode Autre méthode : clonage avec SSH et mises à jour avec HTTPS devrait être assez simple: on clone via le protocole ssh avec un mot de passe (il faut donc un compte sur SourceForge) puis on met à jour avec le protocole https. A priori, les mises à jour en https devraient toujours passer, sauf si vous n'en avez pas fait depuis 10 ans et que ça revient à quasiment tout télécharger (je me répète, mais comme on est sur plusieurs fils...).

ctesc356 a écrit :

3) Pour moi la variable "WHATTOBUILDALL" est inutile. Je la "vide" systématiquement. Je rentre les paramètres dans la ligne de commande.
    En plus ça permet, si on lance sans aucun paramètre de ne faire que le apt/update/install. Ok on peut toujours interrompre par "ctrl-c" mais bon...
    Je ne clone pas fgmeta, je dn le script si je vois une modif. Primitif, mais on a ses petites habitudes wink
    Par contre je n'ai jamais rien compris à la déclaration de version...

C'est justement parce que tu ne télécharges pas d&c.sh « comme il faut ». smile

Je conseille d'utiliser le dépôt fgmeta au lieu de télécharger manuellement download_and_compile.sh :

cd ~/"où vous voulez"
git clone https://git.code.sf.net/p/flightgear/fgmeta fgmeta.git

(le dernier argument est optionnel, il donne le répertoire où vous voulez télécharger fgmeta ; par défaut, c'est 'fgmeta' ; je préfère ajouter '.git' pour me rappeler que c'est un dépôt Git, ce qui permet de faire plein de choses intéressantes)

C'est très rapide. Ensuite, pour mettre à jour, rien de plus simple :

cd fgmeta.git
git pull

(si jamais vous faites des commits locaux, utilisez 'git pull --rebase' au lieu de 'git pull' ; bien sûr, si vos commits entrent en conflit avec une mise à jour, il faudra régler le conflit ou repartir d'un fgmeta tout propre ; Google "Git conflict resolution" doit donner plein de résultats pour la résolution de conflits)

Quels avantages y a-t-il à cloner fgmeta plutôt que de télécharger manuellement download_and_compile.sh ?

1) C'est pas plus compliqué. C'est même plus simple car le script est déjà exécutable une fois le clonage effectué, pas besoin de jouer avec 'chmod'.

2) download_and_compile.sh écrit son numéro de version correctement dans le log et la commande 'download_and_compile.sh --version' le rapporte sans rien faire d'autre, si besoin (ne pas oublier que la doc de référence sur 'download_and_compile.sh' est obtenue en lançant 'download_and_compile.sh --help' ; le wiki FG n'est hélas pas à jour là-dessus).

Le numéro rapporté est mis à jour automatiquement par Git lors d'un clone, du checkout d'une branche ou d'une mise à jour du dépôt fgmeta. Ce n'est pas un numéro de commit, c'est un “blob id”. La mise à jour de ce numéro ne pollue pas les diffs dans le dépôt, et on ne risque pas d'oublier de la faire (mettre à jour un numéro de version à chaque commit, c'est aberrant ; et si on ne met pas à jour à chaque fois, c'est trompeur). Pour trouver un commit contenant tel blob id, on peut utiliser ce script :

#! /bin/sh
#
# From <http://stackoverflow.com/questions/223678/which-commit-has-this-blob>

obj_name="$1"
shift
git log "$@" --pretty=format:'%T %h %s' \
| while read tree commit subject ; do
    if git ls-tree -r $tree | grep -q "$obj_name" ; then
        echo $commit "$subject"
    fi
done

Exemple à exécuter depuis la racine du dépôt fgmeta (j'appelle le script ci-dessus find-git-commits-containing-blob.sh, il faut évidemment que vous le rendiez exécutable et le mettiez dans votre PATH si vous voulez essayer ces commandes) :

$ ./download_and_compile.sh --version
download_and_compile.sh version c8c09570f4d05dc7c3a0a4c284b6655de0c5def7

This script is part of the FlightGear project.

This program is free software

(...)

$ find-git-commits-containing-blob.sh c8c09570f4d05dc7c3a0a4c284b6655de0c5def7
56e1055 download_and_compile.sh: improvements related to package installation
$ git show 56e1055
[détail du commit, appuyez sur 'q' pour quitter si votre $GIT_PAGER est
'less']
$

3) Pas besoin de dire à vos petits camarades : « tu trouves la ligne machin, la modifies comme ci comme ça, etc. et fais une prière avant de le lancer... » Si les gens ne modifient pas le script :

- Les mises à jour de download_and_compile.sh sont triviales ('cd fgmeta.git && git pull').
- C'est plus facile d'aider les autres. Il suffit de voir quels arguments ils passent à download_and_compile.sh.

4) Quand vous êtes à la racine du dépôt fgmeta, vous pouvez facilement voir tous les changements apportés à download_and_compile.sh depuis qu'il a été mis dans un VCS (2011) :

git log -- download_and_compile.sh

La même chose avec les diffs :

git log -p -- download_and_compile.sh

Si vous voulez voir les changements apportés par un commit listé par les commandes qui précèdent, vous pouvez faire ceci (exemple pour le commit 56e1055...) :

git show 56e1055dec8f685024585710989ea00f49e2c70b

Vous pouvez aussi comparer différents commits :

git diff <après-ça>..<jusque-là>

etc. (c'est du Git-fu standard, Google regorge d'exemples, tutoriels, livres...).

ctesc356 a écrit :

4) Ouais... bon... ça me semble un peu "prise de tête" pour pas grand chose.

C'est pourtant très simple et évite les complications dues à des modifs locales dans un script qu'on met à jour de temps en temps... Mais in fine, c'est à vous de voir.

ctesc356 a écrit :

Un souhait: déplacer le "mkdir -p "openscenegraph" dans le bloc "if _elementIn..." comme pour les autres options, ça éviterait la création d'un un dossier "openscenegraph" vide si on ne choisit pas OSG.

C'est fait.

ctesc356 a écrit :

Une interrogation: Ne pourrait'on pas supprimer la clause "BACKWARD COMPATIBILITY WITH 1.9.14a" ?

Moui... mais quel en serait l'intérêt ? Pose-t-elle un quelconque problème ? Si c'est non, je préfère la laisser pour le moment (la version 1.9.14 n'est « que » de 2014...).

P.S. : le logiciel du forum ne supporte pas les listes ? J'ai essayé les [ol] et [ul] indiqués ici sans grand succès...

Florent


Debian GNU/Linux, driver libre pour carte Radeon HD 4670, FG 'next', 8 Go de RAM

Hors ligne

Pied de page des forums