[Wiki] Linux

Répondre
Partager Rechercher
Je suis un bouquin

Le bouquin dit :
1) Démarrer nginx par un docker run nginx
2) Aller sur un navigateur sur http://localhost:8080 pour voir ce que ça fait.

C'est pas moi qui le choisis, c'est le livre qui propose d'en passer par là.
Parce que le livre suppose que l'on est sur une machine CentOS 7, dans un terminal ouvert dans une session graphique. Si c'était le cas, tout irait bien.

Mais comme ce n'est pas le cas, je passe par une Vagrant.
Théoriquement, si ta VM a une ip accessible depuis windows, et que tu run le conteneur avec l'option "-p", tu peux accéder au nginx en faisant http://<ip_vm>:<port_nginx> depuis ton windows dans ton navigateur.
Voilà comment j'ai finalement fait.

Sur la vagrant :
yum update
yum -y groups install "GNOME Desktop"

Puis je me suis connecté par VirtualBox sur l'IHM, et j'ai lancé l'exemple dans un terminal, et Firefox à côté.

https://forums.jeuxonline.info/attachment.php?attachmentid=277392&amp;d=1482435373

Merci d'avoir vu qu'il me manquait tout simplement Gnome !

EDIT :
Je peux en faire une Moisy ?
Il y a vingt ans y avait un habitant qu'avait tout prophétisé, mais il était pas sur terre en fait.

https://forums.jeuxonline.info/attachment.php?attachmentid=277407&amp;d=1482477115
Miniatures attachées
Cliquez sur l'image pour la voir en taille réelle

Nom : resultat.png
Taille : 1701x1038
Poids : 495,5 Ko
ID : 277392   Cliquez sur l'image pour la voir en taille réelle

Nom : vagrant_git.png
Taille : 1117x697
Poids : 1,46 Mo
ID : 277407  

Dernière modification par Caniveau Royal ; 23/12/2016 à 08h12.
Citation :
Publié par Airmed / Ildefonse
Un des avantages, c'est d'avoir un historique dans chaque terminal et de pas forcément repartir sur du vierge. Un autre (pour moi) est de tout avoir dans une fenetre / serveur, histoire de pas confondre les machines.
NX3 + awesome, cela consomme pas grand chose et cela facilite grandement la vie </pub>
screen + tmux

Citation :
– Ma râlerie sur Linux vient de ce que je passe de client en client de Mint à Debian, prend un livre CentOS, ici un autre Ubuntu, et tout est toujours redéfini.
Mais bon, je reconnais que dans le contexte de mon message, cette plainte n'aurait pas du être là ! Mais voilà : je maugrée quotidiennement ce que j'ai écrit...
Tu as entierement raison. Linux manque de standardisation. Bon, tu veux docker donc c'est pas *encore* l'ideal, mais les BSD sont peut etre plus ce que tu veux ? c'est bien plus "carre" comme maniere de faire, et les choses comme les emplacement des fichiers de conf, etc. sont plus standardises.
apt-get update retourne 100 : problème de sources
Dans mon apprentissage de Docker, j'expérimente une installation de Tomcat 8.
Mais je n'y parviens pas encore, car je suis bloqué dans une phase préparatoire : l'installation de Java 8.
- La source Oracle d’installation pour le JDK Java 8 n'est pas incluse dans Debian : il faut aller la faire ajouter.
- L'installeur Oracle pour le JDK 8 est issu d'Ubuntu, d'après ce que j'ai compris.
- Je pourrais installer Java 8 par un wget, de-zippage dans /opt et tout ça, mais je dois expérimenter l'installation par apt-get tout d'abord.

Code:
FROM debian:8.6

# Update pour installer transport-https, requis pour récupérer les updates des sources de webupd8team.
RUN apt-get update && apt-get install -y apt-transport-https 

# installation d'une nouvelle source pour obtenir Java 8, car elle n'est pas dans Debian 8
RUN echo "deb http://ppa.launchpad.net/webupd8team/java/ubuntu trusty main" > /etc/apt/sources.list.d/webupd8team-java.list \
echo "deb-src http://ppa.launchpad.net/webupd8team/java/ubuntu trusty main" >> /etc/apt/sources.list.d/webupd8team-java.list \
apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys EEA14886

# Update sur ces nouvelles sources, puis install Java
RUN apt-get update && apt-get install oracle-java8-installer -y

# Installation Tomcat
RUN apt-get install tomcat8 -y

# Lancement de tomcat
CMD service tomcat8 start
Remarque : il est très probable que les étapes suivantes de mon Dockerfile (install et démarrage Tomcat) échoueront : je ne les ai pas encore expérimentées. Elles sont hors-sujet pour ce post.


Je rencontre un échec lors du build de ce Dockerfile :
The command '/bin/sh -c apt-get update && apt-get install oracle-java8-installer -y' returned a non-zero code: 100
Alors le code erreur 100 signifie : "En DOS 3.3, la commnande PCS/400 a échoué à lancer une émulation 5250 vers un IBM AS/400 à cause d'un problème de segment de 64 ko dépassé."
Je n'aime pas les développeurs qui ne font pas de bons messages d'erreur, par paresse. Un bon message d'erreur doit contenir, idéalement :
. Un libellé de l'erreur non ambigu : cause d'incident unique = libellé d'erreur unique ; jamais le même libellé d'erreur pour plusieurs erreurs différentes.
. présentation des valeurs des arguments passés à la sous-commande qui a échoué,
. présentation des autres éléments impliqués dans la commande avec leurs valeurs (sur quels éléments sous-jacents, autres que les arguments, a t-elle essayé d'agir ou qu'est-ce qu'elle a engagé dans son exécution ?)
. description du contexte dans laquelle l'erreur s'est produite,
. cause probable de l'erreur (diagnostic), si possible,
. alternative recommandée, s'il y en a une
tout ça, ça devrait être dans le message d'erreur final qui est émis.

Je vais avoir l'air malin, un jour en prod, si j'ai un plantage sérieux avec un code 7227.
Vous le connaissez le code 7227 ?

Je vais vous dire ce que j'en pense : -214.


Du coup, passage sur Google, où sur ce code 100, les internautes se perdent en conjectures.
L'un m'a fait ajouter le package apt-transport-https, par exemple. Mais sans succès.
Voici le déroulé du step fautif :

Code:
Step 5 : RUN apt-get update && apt-get install oracle-java8-installer -y
 ---> Running in df7522479867
Get:1 http://ppa.launchpad.net trusty InRelease [15.5 kB]
Ign http://ppa.launchpad.net trusty InRelease
Ign http://deb.debian.org jessie InRelease
Get:2 http://ppa.launchpad.net trusty/main amd64 Packages [3110 B]
Hit http://deb.debian.org jessie-updates InRelease
Hit http://deb.debian.org jessie Release.gpg
Hit http://deb.debian.org jessie Release
Get:3 http://deb.debian.org jessie-updates/main amd64 Packages [17.6 kB]
Get:4 http://deb.debian.org jessie/main amd64 Packages [9064 kB]
Err http://ppa.launchpad.net trusty/echo amd64 Packages
  404  Not Found
Err http://ppa.launchpad.net trusty/deb-src amd64 Packages
  404  Not Found
Err http://ppa.launchpad.net trusty/http://ppa.launchpad.net/webupd8team/java/ubuntu amd64 Packages
  404  Not Found
Err http://ppa.launchpad.net trusty/trusty amd64 Packages
  404  Not Found
Err http://ppa.launchpad.net trusty/apt-key amd64 Packages
  404  Not Found
Err http://ppa.launchpad.net trusty/adv amd64 Packages
  404  Not Found
Err http://ppa.launchpad.net trusty/--keyserver amd64 Packages
  404  Not Found
Err http://ppa.launchpad.net trusty/hkp://keyserver.ubuntu.com:80 amd64 Packages
  404  Not Found
Err http://ppa.launchpad.net trusty/--recv-keys amd64 Packages
  404  Not Found
Err http://ppa.launchpad.net trusty/EEA14886 amd64 Packages
  404  Not Found
Hit http://security.debian.org jessie/updates InRelease
Get:5 http://security.debian.org jessie/updates/main amd64 Packages [428 kB]
Fetched 9528 kB in 5s (1904 kB/s)
W: GPG error: http://ppa.launchpad.net trusty InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY C2518248EEA14886
W: Failed to fetch http://ppa.launchpad.net/webupd8team/java/ubuntu/dists/trusty/echo/binary-amd64/Packages  404  Not Found

W: Failed to fetch http://ppa.launchpad.net/webupd8team/java/ubuntu/dists/trusty/deb-src/binary-amd64/Packages  404  Not Found

W: Failed to fetch http://ppa.launchpad.net/webupd8team/java/ubuntu/dists/trusty/http://ppa.launchpad.net/webupd8team/java/ubuntu/binary-amd64/Packages  404  Not Found

W: Failed to fetch http://ppa.launchpad.net/webupd8team/java/ubuntu/dists/trusty/trusty/binary-amd64/Packages  404  Not Found

W: Failed to fetch http://ppa.launchpad.net/webupd8team/java/ubuntu/dists/trusty/apt-key/binary-amd64/Packages  404  Not Found

W: Failed to fetch http://ppa.launchpad.net/webupd8team/java/ubuntu/dists/trusty/adv/binary-amd64/Packages  404  Not Found

W: Failed to fetch http://ppa.launchpad.net/webupd8team/java/ubuntu/dists/trusty/--keyserver/binary-amd64/Packages  404  Not Found

W: Failed to fetch http://ppa.launchpad.net/webupd8team/java/ubuntu/dists/trusty/hkp://keyserver.ubuntu.com:80/binary-amd64/Packages  404  Not Found

W: Failed to fetch http://ppa.launchpad.net/webupd8team/java/ubuntu/dists/trusty/--recv-keys/binary-amd64/Packages  404  Not Found

W: Failed to fetch http://ppa.launchpad.net/webupd8team/java/ubuntu/dists/trusty/EEA14886/binary-amd64/Packages  404  Not Found

E: Some index files failed to download. They have been ignored, or old ones used instead.
En les lisant, je peux penser que c'est le message en rouge qui est à l'origine de l'incident.
Mais ce n'est pas sûr : il dit que les fichiers ont étés ignorés ou les anciens utilisés à la place, donc je pourrais croire que ça ne l'a pas gêné.

Sur Google, d'autres internautes disent que c'est probablement
http://ppa.launchpad.net/webupd8team/java/

qui n'est plus maintenu par webupd8team, et donc ce serait normal qu'il ait des liens qui fassent des 404.
Du coup, je ne sais pas trop quoi faire. J'ai essayé des options derrière apt-get update pour lui demander d'ignorer les erreurs, mais sans succès.

Comment agir pour rétablir le bon fonctionnement à partir d'ici ?
C'est normal que ce soit la communauté qui se bricole des listes de sources, les propose à la place d'Oracle, puis ne les maintienne plus parce que ça l'ennuie finalement ?

Dernière modification par Caniveau Royal ; 01/01/2017 à 07h44.
Tu peux pas installer OpenJDK plutôt que le Java d'Oracle ? apt-get install tomcat8 devrait d'ailleurs installer OpenJDK automatiquement je pense. Du coup ça t'éviterait d'avoir à passer par des dépôts non officiels et ça devrait résoudre ton problème.
La plupart du temps, je vois Open JDK déclassé au profit de la version maintenue par Oracle.
C'est encore le cas où je travaille, et pour ma part, j'utilise aussi le JDK d'Oracle.
Je préfère me maintenir sur celui-là.

@PatNyck : Oui, c'est Oracle qui a racheté Sun, le créateur de Java. Ses implémentations sont celles de référence, même s'il en existe d'autres (Open JDK, mais aussi jadis : IBM a fait les siennes).

Dernière modification par Caniveau Royal ; 01/01/2017 à 22h54.
Citation :
Publié par Caniveau Royal
- Je pourrais installer Java 8 par un wget, de-zippage dans /opt et tout ça, mais je dois expérimenter l'installation par apt-get tout d'abord.
Personne dans le monde pro installe un jdk via apt-get, je comprends pas trop ce besoin d'installer des appli du monde pro par des commandes de noobs. Un jdk ça se dézip, tout comme tomcat.

Citation :
Publié par PatNyck
Il y a une raison particuliere le JRE d'Oracle ou c'est juste "comme ça" ?
Cette question hérisserait le poil de pas mal de développeurs Java.
Citation :
Publié par Mixo`
Personne dans le monde pro installe un jdk via apt-get, je comprends pas trop ce besoin d'installer des appli du monde pro par des commandes de noobs. Un jdk ça se dézip, tout comme tomcat.

Cette question hérisserait le poil de pas mal de développeurs Java.
C'est de l'ironie j'espère

OpenJDK est l'implémentation de référence de Java (et est développé en grande partie par les dev d'Oracle), donc je ne vois pas le soucis avec OpenJDK, surtout pour des produits de base comme Tomcat. Il y avait quelques produits comme Cassandra qui conseillaient le JDK d'Oracle il y a quelques années mais même eux valident maintenant leurs produits sur l'OpenJDK.
Si on rajoute à ça le comportement d'Oracle de ces derniers temps, je ne conseille pas l'installation d'un truc venant d'Oracle. On voit encore beaucoup de jdk Oracle en entreprise, mais c'est plus installé car ça vient d'Oracle (donc ça fait plus "pro") qu'autre chose.

Et sinon c'est beaucoup plus simple d'installer des app via .deb/rpm quand c'est possible (quitte à les packager soit même pour des trucs maison), le coup du curl/tar c'est toujours l'enfer pour gérer l'idempotence dans les outils de déploiement.
Citation :
Publié par Nelphit
C'est de l'ironie j'espère
Pas que.

Citation :
Publié par Nelphit
Et sinon c'est beaucoup plus simple d'installer des app via .deb/rpm quand c'est possible (quitte à les packager soit même pour des trucs maison), le coup du curl/tar c'est toujours l'enfer pour gérer l'idempotence dans les outils de déploiement.
On parle d'un jdk hein, si décompresser une archive, créer un lien symbolique et set une variable d'environnement c'est l'enfer...
Pour l'automatiser oui c'est l'enfer, car je ne veux pas retélécharger et réinstaller le jdk si il est déjà présent (et je veux également gérer proprement le restart de mes app en cas d'upgrade). Ça veut dire devoir réaliser un check avant de commencer l'installation, et commencer à mettre des conditions partout sur la suite. En gros récrire yum à la main
Dans ma boîte on repackage tout en rpm quand c'est possible, c'est beaucoup plus simple à gérer (une commande yum qui pose tout à lancer vs check + curl + tar +...)
Citation :
Publié par Caniveau Royal
Je rencontre un échec lors du build de ce Dockerfile :
The command '/bin/sh -c apt-get update && apt-get install oracle-java8-installer -y' returned a non-zero code: 100[INDENT] Alors le code erreur 100 signifie : "En DOS 3.3, la commnande PCS/400 a échoué à lancer une émulation 5250 vers un IBM AS/400 à cause d'un problème de segment de 64 ko dépassé."
Je n'aime pas les développeurs qui ne font pas de bons messages d'erreur, par paresse. Un bon message d'erreur doit contenir, idéalement :
. Un libellé de l'erreur non ambigu : cause d'incident unique = libellé d'erreur unique ; jamais le même libellé d'erreur pour plusieurs erreurs différentes.
. présentation des valeurs des arguments passés à la sous-commande qui a échoué,
. présentation des autres éléments impliqués dans la commande avec leurs valeurs (sur quels éléments sous-jacents, autres que les arguments, a t-elle essayé d'agir ou qu'est-ce qu'elle a engagé dans son exécution ?)
. description du contexte dans laquelle l'erreur s'est produite,
. cause probable de l'erreur (diagnostic), si possible,
. alternative recommandée, s'il y en a une
tout ça, ça devrait être dans le message d'erreur final qui est émis.

Je vais avoir l'air malin, un jour en prod, si j'ai un plantage sérieux avec un code 7227.
Vous le connaissez le code 7227 ?

Je vais vous dire ce que j'en pense : -214.
Le code retour c'est une norme, lorsque c'est différent de 0 c'est que c'est une erreur.

Tu peux connaitre la valeur du code retour en faisant un "echo $?" après avoir exécuté une commande.

Il te dit juste que le code de retour est différent de 0 et qu'il y a donc eu une erreur.
Si tu exécutes à la main la ligne tu auras probablement un retour plus explicite.
Citation :
Publié par Nelphit
Pour l'automatiser oui c'est l'enfer, car je ne veux pas retélécharger et réinstaller le jdk si il est déjà présent (et je veux également gérer proprement le restart de mes app en cas d'upgrade). Ça veut dire devoir réaliser un check avant de commencer l'installation, et commencer à mettre des conditions partout sur la suite. ...
chez nous on est en pleine migration dans du devops avec Puppet. Et quand on pose la question du JRE Oracle, ce que je comprend dans les reponses c'est que c'est plus par habitude que pour des raisons bien précises.
Si je fais un docker avec apt-get install oracle-java8-jdk, c'est parce que je sais que c'est celui qu'on nous a demandé d'utiliser en production sur les machines cibles, et installé de cette manière (qui marche d'ailleurs très bien sur nos postes de dev... et je fais du Java depuis seize années maintenant : j'arrive à reconnaître une installation qui ne fonctionne pas).

À un moment, les gars de la prod nous disent : c'est ça qu'on utilise et de cette manière.
On peut toujours discuter à côté sur le bien fondé de leurs choix : il n'empêche, ils ont dit : "La cible, c'est ça.". Alors voilà. On peut épiloguer, mais ça ne sert à rien.

Ils ont sûrement un dépôt chez eux avec ce qu'ils admettent de packages, qu'ils ont vérifié.
On se dit : "Oui mais bon, on leur passe des images : ils pourraient ne pas se préoccuper de comment on les a bâties.". Mais ils ne se gênent pas pour inspecter les Dockerfile : "Non, pas ça. Non pas ceci non plus."... Je pense même qu'ils ne seraient pas gênés de refaire un docker build de nos Dockerfile en préprod pour voir si tout est bien tiré au cordeau. Et là, renvoi aux 22 mètres si ça coince.

En un mot : y a un énoncé, faut pas le changer.
C'est apt-get install oracle-java8-jdk qu'il faut faire.
Si vous me dites : "Bon, on sait pas faire.", c'est pas grave ! Ça arrive de temps en temps.

Citation :
Publié par Airmed / Ildefonse
Fais un apt-get tomcat et apt-get fera les dépendances lui-même.
Et quelle version de Java ramènerait-il, s'il le faisait ?
La 8, la 7 ? Et si je relance le build de ce Dockerfile dans six mois, il ira tirer la 9 ? Un composant qui s'en irait prendre la version Java qu'il veut transformerait tout en loterie.

Dernière modification par Caniveau Royal ; 02/01/2017 à 19h31.
Citation :
Publié par Caniveau Royal
En un mot : y a un énoncé, faut pas le changer.
C'est apt-get install oracle-java8-jdk qu'il faut faire.
Si vous me dites : "Bon, on sait pas faire.", c'est pas grave ! Ça arrive de temps en temps.
Bah du coup c'est simple: soit les depots de webudp8 (re ?)marchent (a vrai dire j'ai jamais eu de souci avec, la derniere update de leur site remonte a oct 2016 donc ils sont pas inactifs), soit la prod fournit un serveur de repo, avec les versions qu'ils supportent dedans, et vous rajoutez leur ppa a apt-get.

Si vous avez pas l'autorisation de pull les tgz de Oracle, ca limite sacrement.
Citation :
Publié par Caniveau Royal
Et quelle version de Java ramènerait-il, s'il le faisait ?
La 8, la 7 ? Et si je relance le build de ce Dockerfile dans six mois, il ira tirer la 9 ? Un composant qui s'en irait prendre la version Java qu'il veut transformerait tout en loterie.
La version dont dépend la version de tomcat 8 ? Suffit de lui demander, sinon :
https://packages.debian.org/jessie/tomcat8-common

apt-get va installer la v7 a priori

Dans 6 mois, tant que tu reste sur la jessie (et non la stable), tu auras toujours les memes versions vu qu'elle est freeze. Sinon tu prends la backport pour avoir directement java 8
Je suis dans un état intermédiaire : je teste à mon domicile une situation similaire à celle que j'aurais en production plus tard.
Je n'ai donc pas le futur repo de prod, j'ai webudp8, qui coince toujours, malheureusement.

En quoi dezipper des tgz, tar, zip serait à préférer à l'installation de paquets sous Linux, ou dans le cas de Windows, lancer des exécutables (setup) d'installation du JDK ?
Le dézip c'est le degré zéro de l'installation : ça écrase et ne vérifie rien de la compatibilité avec l'existant : packages ou environnement en conflit, rien ne sera contrôlé. Je comprends que des exploitants écartent cette manière de faire.
Citation :
Publié par Caniveau Royal
En quoi dezipper des tgz, tar, zip serait à préférer à l'installation de paquets sous Linux, ou dans le cas de Windows, lancer des exécutables (setup) d'installation du JDK ?
Le dézip c'est le degré zéro de l'installation : ça écrase et ne vérifie rien de la compatibilité avec l'existant : packages ou environnement en conflit, rien ne sera contrôlé. Je comprends que des exploitants écartent cette manière de faire.
Parce que tu choisis la version que tu veux, parce que tu choisis où tu l'installes, bref c'est ça le contrôle. Avec des liens symboliques et une variable d'environnement tu peux switcher de version sans problème. Une des contraintes par contre c'est que mettre à jour ça revient à télécharger la dernière archive et changer le lien symbolique. C'est aussi possible d'avoir plusieurs versions de jdk (7 et 8 par exemple) sur un même système par ce biais.

En gros, quand on a plus une vision système que dév (), on fait ça pour que ce soit propre :
- dézip l'archive dans un dossier (exemple /opt)
- faire un lien symbolique /opt/jdk qui pointe vers /opt/jdk-8u111 par exemple.
- créer la variable d'environnement qui pointe sur /opt/jdk dans /etc/profile ou pour un utilisateur précis comme ici

Comme ça le jour où on veut mettre à jour, on dézip le nouveau, on change le lien symbolique, et voilà, c'est fini.

Citation :
Publié par N° 44 636
Apres oui c'est plus propre avec apt-get, mais dans ce cas le mieux c'est d'avoir en interne un miroir pour ne pas avoir une dependance externe, et sans support.
Oh bah oui bien sur, c'est plus propre de laisser un package installer des trucs un peu partout sur le système sans contrôle plutôt que d'avoir tout dans le même dossier, avec la version que l'on souhaite.

Dernière modification par Mixo` ; 03/01/2017 à 09h05.
Citation :
Publié par Mixo`

Oh bah oui bien sur, c'est plus propre de laisser un package installer des trucs un peu partout sur le système sans contrôle plutôt que d'avoir tout dans le même dossier, avec la version que l'on souhaite.
lit tout, ma solution implique de gerer le package en interne. Dans ce cas, tu sais ou ca installe, et ce que ca installe. et tu sais ou c'est installe via l'OS du coup. Plutot que de se demander "hmmm alors sur ce vieux serveur, ou on installait les JVM deja lol ? dans /usr/opt ? dans /usr/local ? ailleurs ?" Ca facilite egalement le deploiement automatise (via du puppet ou du docker par exemple).

D'un cote, tu dois verifier "a la main" si la JVM est installee (dans plusieurs chemins possibles, selon la version), quelle est sa version, est-ce qu'il faut en installer une plus recente, etc.

en gerant toi meme ton repo, tu as ton application metier dedans, qui a une dependance sur votre version de java, et c'est gere tout seul.



Citation :
Parce que tu choisis la version que tu veux, parce que tu choisis où tu l'installes, bref c'est ça le contrôle. Avec des liens symboliques et une variable d'environnement tu peux switcher de version sans problème. Une des contraintes par contre c'est que mettre à jour ça revient à télécharger la dernière archive et changer le lien symbolique. C'est aussi possible d'avoir plusieurs versions de jdk (7 et 8 par exemple) sur un même système par ce biais.
Tu peux avoir tout cela avec des paquets.


EDIT: et apres verification: Oracle sert ses tgz en HTTP, sans aucune securite. La page des checksum est accessible en HTTPS, mais bon, c'est lourd a verifier a la main a chaque install. avec ton propre repo, une fois que le paquet est construit, tu le signes, et tu sais que personne a pu trafficoter ton paquet quand tu l'installes sur une becane.

Dernière modification par N° 44 636 ; 03/01/2017 à 11h23.
Compilation et répartition d'exécutables dans /usr vs. /opt, et .deb fpm vs. dpkg
Voici mon problème du jour :

1) Quelles équivalences du point de vue répartition des fichiers pour une install dans /usr ou une dans /opt ?
J'ai une application C et C++ qui se compile et dont on répartit les outputs (sh, .so, .la, etc.) dans des répertoires /usr/bin, /usr/lib, /usr/include, /usr/share, etc.
Elle s'exécute bien quand on la lance depuis /usr/bin

On me demande de la déployer plutôt dans /opt
J'ai l'impression qu'alors la répartition est différente.
Quelles sont les équivalences ?
Quel en est le but ?

2) Je dois ensuite un faire un package debian
Parce que ce que je compile, pour s'exécuter, réclame qu'il y ait quelques dépendances pré-installées auparavant.
J'ai deux solutions : fpm et dpkg, je crois.
Les deux commandes permettent-elles de le faire aisément, ou bien non : c'est un métier ?

Dernière modification par Caniveau Royal ; 17/01/2017 à 21h23.
Sur le premier point, opt est sensé contenir des applicatifs regroupés dans un dossier. Par exemple : /opt/jdk-8.xx./[...].
/usr/ lui contient des librairies/binaires posées à plat. Elles sont juste regroupées selon des notions logiques rattachés au système (local, lib32, lib64, share, src, ...).

Sur le second point... je suis pas usé à fpm donc je saurais pas trop te dire. Mais construire un paquet avec dpkg n'a rien de sorcier... ça demande juste d'y consacrer un peu de temps à lire la doc.
L'installation silencieuse de GNOME est-elle possible ?
Merci pour vos assistances précédentes ! Cela m'aide beaucoup !

Pour me faciliter la vie lors de mes expérimentations, j'ai voulu me monter un environnement Debian 8 avec Gnome directement dessus au démarrage.

Je suis parti sur ce script de Vagrant :
(l'idée est qu'après, cet environnement ayant été bâti, je re-rentrerai dans cette VM par Virualbox cette fois, et tout sera prêt).

Code:
Vagrant.configure("2") do |config|
  config.vm.box = "debian/jessie64"
  config.vm.synced_folder ".", "/vagrant", type: "virtualbox"

   config.vm.provider "virtualbox" do |vb|
     vb.memory = "4096"
   end

  config.vm.provision "shell", inline: <<-SHELL
    sudo apt-get install curl
    sudo apt-get install aptitude tasksel
    sudo tasksel install gnome-desktop --new-install
  SHELL
end
L'ensemble finit par échouer. Est-ce parce que :
1) L'installeur de Gnome voudrait me demander quelque-chose et je ne peux lui répondre ?
2) Il ne voit pas de périphérique graphique, ayant débuté l'installation par vagrant = mode console ?
Ou bien c'est autre chose ?

Puis-je rajouter des options à
sudo tasksel install gnome-desktop --new-install
pour qu'il se débrouille seul en mode ligne de commande sans demander une intervention manuelle ?

Voici l'exécution problématique (elle n'est pas dans une balise CODE, désolé. Sinon les lignes en rouge qui posent problème perdent leur coloration):

F:\vagrant_declarations\d8_gitlab>bash
$ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Importing base box 'debian/jessie64'...
==> default: Matching MAC address for NAT networking...
==> default: Checking if box 'debian/jessie64' is up to date...
==> default: A newer version of the box 'debian/jessie64' is available! You currently
==> default: have version '8.6.1'. The latest is version '8.7.0'. Run
==> default: `vagrant box update` to update.
==> default: Setting the name of the VM: d8_gitlab_default_1489040852463_96618
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
default: Adapter 1: nat
==> default: Forwarding ports...
default: 22 (guest) => 2222 (host) (adapter 1)
==> default: Running 'pre-boot' VM customizations...
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
default: SSH address: 127.0.0.1:2222
default: SSH username: vagrant
default: SSH auth method: private key
default:
default: Vagrant insecure key detected. Vagrant will automatically replace
default: this with a newly generated keypair for better security.
default:
default: Inserting generated public key within guest...
default: Removing insecure key from the guest if it's present...
default: Key inserted! Disconnecting and reconnecting using new SSH key...
==> default: Machine booted and ready!
[default] No installation found.
stdin: is not a tty
Reading package lists...
Building dependency tree...
Reading state information...
The following extra packages will be installed:
binutils cpp cpp-4.8 cpp-4.9 fakeroot gcc gcc-4.8 gcc-4.9 libasan0 libasan1
libatomic1 libc-dev-bin libc6-dev libcilkrts5 libcloog-isl4 libfakeroot
libgcc-4.8-dev libgcc-4.9-dev libgomp1 libisl10 libitm1 liblsan0 libmpc3
libmpfr4 libquadmath0 libtsan0 libubsan0 linux-compiler-gcc-4.8-x86
linux-headers-3.16.0-4-common linux-headers-amd64 linux-kbuild-3.16
linux-libc-dev make manpages-dev
Suggested packages:
binutils-doc cpp-doc gcc-4.8-locales gcc-4.9-locales gcc-multilib autoconf
automake libtool flex bison gdb gcc-doc gcc-4.8-multilib gcc-4.8-doc
libgcc1-dbg libgomp1-dbg libitm1-dbg libatomic1-dbg libasan0-dbg
libtsan0-dbg libquadmath0-dbg gcc-4.9-multilib gcc-4.9-doc libasan1-dbg
liblsan0-dbg libubsan0-dbg libcilkrts5-dbg glibc-doc make-doc
Recommended packages:
linux-image
The following NEW packages will be installed:
binutils cpp cpp-4.8 cpp-4.9 dkms fakeroot gcc gcc-4.8 gcc-4.9 libasan0
libasan1 libatomic1 libc-dev-bin libc6-dev libcilkrts5 libcloog-isl4
libfakeroot libgcc-4.8-dev libgcc-4.9-dev libgomp1 libisl10 libitm1 liblsan0
libmpc3 libmpfr4 libquadmath0 libtsan0 libubsan0 linux-compiler-gcc-4.8-x86
linux-headers-3.16.0-4-amd64 linux-headers-3.16.0-4-common
linux-headers-amd64 linux-kbuild-3.16 linux-libc-dev make manpages-dev
0 upgraded, 36 newly installed, 0 to remove and 0 not upgraded.
Need to get 40.3 MB of archives.
After this operation, 153 MB of additional disk space will be used.
Get:1 http://httpredir.debian.org/debian/ jessie/main libasan0 amd64 4.8.4-1 [63.3 kB]
Get:2 http://httpredir.debian.org/debian/ jessie/main libasan1 amd64 4.9.2-10 [195 kB]
Get:3 http://httpredir.debian.org/debian/ jessie/main libatomic1 amd64 4.9.2-10 [8,992 B]
Get:4 http://httpredir.debian.org/debian/ jessie/main libcilkrts5 amd64 4.9.2-10 [40.1 kB]
Get:5 http://httpredir.debian.org/debian/ jessie/main libisl10 amd64 0.12.2-2 [440 kB]
Get:6 http://httpredir.debian.org/debian/ jessie/main libcloog-isl4 amd64 0.18.2-1+b2 [61.8 kB]
Get:7 http://httpredir.debian.org/debian/ jessie/main libgomp1 amd64 4.9.2-10 [37.8 kB]
Get:8 http://httpredir.debian.org/debian/ jessie/main libitm1 amd64 4.9.2-10 [29.2 kB]
Get:9 http://httpredir.debian.org/debian/ jessie/main liblsan0 amd64 4.9.2-10 [92.8 kB]
Get:10 http://httpredir.debian.org/debian/ jessie/main libmpfr4 amd64 3.1.2-2 [527 kB]
Get:11 http://httpredir.debian.org/debian/ jessie/main libquadmath0 amd64 4.9.2-10 [129 kB]
Get:12 http://httpredir.debian.org/debian/ jessie/main libtsan0 amd64 4.9.2-10 [212 kB]
Get:13 http://httpredir.debian.org/debian/ jessie/main libubsan0 amd64 4.9.2-10 [82.4 kB]
Get:14 http://httpredir.debian.org/debian/ jessie/main libmpc3 amd64 1.0.2-1 [39.3 kB]
Get:15 http://httpredir.debian.org/debian/ jessie/main binutils amd64 2.25-5 [3,516 kB]
Get:16 http://httpredir.debian.org/debian/ jessie/main cpp-4.9 amd64 4.9.2-10 [5,169 kB]
Get:17 http://httpredir.debian.org/debian/ jessie/main cpp amd64 4:4.9.2-2 [17.3 kB]
Get:18 http://httpredir.debian.org/debian/ jessie/main cpp-4.8 amd64 4.8.4-1 [4,577 kB]
Get:19 http://httpredir.debian.org/debian/ jessie/main libgcc-4.9-dev amd64 4.9.2-10 [2,066 kB]
Get:20 http://httpredir.debian.org/debian/ jessie/main gcc-4.9 amd64 4.9.2-10 [5,352 kB]
Get:21 http://httpredir.debian.org/debian/ jessie/main gcc amd64 4:4.9.2-2 [5,136 B]
Get:22 http://httpredir.debian.org/debian/ jessie/main make amd64 4.0-8.1 [349 kB]
Get:23 http://httpredir.debian.org/debian/ jessie/main dkms all 2.2.0.3-2 [70.9 kB]
Get:24 http://httpredir.debian.org/debian/ jessie/main libfakeroot amd64 1.20.2-1 [44.7 kB]
Get:25 http://httpredir.debian.org/debian/ jessie/main fakeroot amd64 1.20.2-1 [84.7 kB]
Get:26 http://httpredir.debian.org/debian/ jessie/main libgcc-4.8-dev amd64 4.8.4-1 [1,689 kB]
Get:27 http://httpredir.debian.org/debian/ jessie/main gcc-4.8 amd64 4.8.4-1 [4,787 kB]
Get:28 http://httpredir.debian.org/debian/ jessie/main libc-dev-bin amd64 2.19-18+deb8u6 [238 kB]
Err http://httpredir.debian.org/debian/ jessie/main linux-libc-dev amd64 3.16.36-1+deb8u1
404 Not Found [IP: 151.101.60.204 80]
Err http://httpredir.debian.org/debian/ jessie/main libc6-dev amd64 2.19-18+deb8u6
404 Not Found [IP: 151.101.60.204 80]
Err http://security.debian.org/ jessie/updates/main linux-libc-dev amd64 3.16.36-1+deb8u1
404 Not Found [IP: 217.196.149.233 80]
Err http://security.debian.org/ jessie/updates/main linux-compiler-gcc-4.8-x86 amd64 3.16.36-1+deb8u1
404 Not Found [IP: 217.196.149.233 80]
Err http://security.debian.org/ jessie/updates/main linux-headers-3.16.0-4-common amd64 3.16.36-1+deb8u1
404 Not Found [IP: 217.196.149.233 80]
Get:29 http://httpredir.debian.org/debian/ jessie/main linux-kbuild-3.16 amd64 3.16.7-ckt20-1 [174 kB]
Err http://httpredir.debian.org/debian/ jessie/main linux-headers-3.16.0-4-amd64 amd64 3.16.36-1+deb8u1
404 Not Found [IP: 151.101.60.204 80]
Get:30 http://httpredir.debian.org/debian/ jessie/main linux-headers-amd64 amd64 3.16+63 [5,050 B]
Err http://security.debian.org/ jessie/updates/main linux-headers-3.16.0-4-amd64 amd64 3.16.36-1+deb8u1
404 Not Found [IP: 217.196.149.233 80]
Get:31 http://httpredir.debian.org/debian/ jessie/main manpages-dev all 3.74-1 [1,865 kB]
Fetched 32.0 MB in 2min 3s (259 kB/s)
E: Failed to fetch http://security.debian.org/pool/upda...b8u1_amd64.deb 404 Not Found [IP: 217.196.149.233 80]

E: Failed to fetch http://httpredir.debian.org/debian/p...b8u6_amd64.deb 404 Not Found [IP: 151.101.60.204 80]

E: Failed to fetch http://security.debian.org/pool/upda...b8u1_amd64.deb 404 Not Found [IP: 217.196.149.233 80]

E: Failed to fetch http://security.debian.org/pool/upda...b8u1_amd64.deb 404 Not Found [IP: 217.196.149.233 80]

E: Failed to fetch http://security.debian.org/pool/upda...b8u1_amd64.deb 404 Not Found [IP: 217.196.149.233 80]

E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?
stdin: is not a tty
Ign http://httpredir.debian.org jessie InRelease
Get:1 http://httpredir.debian.org jessie Release.gpg [2,373 B]
Get:2 http://httpredir.debian.org jessie Release [148 kB]
Get:3 http://httpredir.debian.org jessie/main Sources [7,056 kB]
Get:4 http://security.debian.org jessie/updates InRelease [63.1 kB]
Get:5 http://httpredir.debian.org jessie/main amd64 Packages [6,776 kB]
Get:6 http://security.debian.org jessie/updates/main Sources [191 kB]
Get:7 http://security.debian.org jessie/updates/main amd64 Packages [355 kB]
Fetched 14.6 MB in 3s (4,027 kB/s)
Reading package lists...
stdin: is not a tty
Reading package lists...
Building dependency tree...
Reading state information...
The following extra packages will be installed:
binutils cpp cpp-4.8 cpp-4.9 fakeroot gcc gcc-4.8 gcc-4.9 libasan0 libasan1
libatomic1 libc-dev-bin libc6 libc6-dev libcilkrts5 libcloog-isl4
libfakeroot libgcc-4.8-dev libgcc-4.9-dev libgomp1 libisl10 libitm1 liblsan0
libmpc3 libmpfr4 libquadmath0 libtsan0 libubsan0 linux-compiler-gcc-4.8-x86
linux-headers-3.16.0-4-common linux-headers-amd64 linux-kbuild-3.16
linux-libc-dev make manpages-dev
Suggested packages:
binutils-doc cpp-doc gcc-4.8-locales gcc-4.9-locales gcc-multilib autoconf
automake libtool flex bison gdb gcc-doc gcc-4.8-multilib gcc-4.8-doc
libgcc1-dbg libgomp1-dbg libitm1-dbg libatomic1-dbg libasan0-dbg
libtsan0-dbg libquadmath0-dbg gcc-4.9-multilib gcc-4.9-doc libasan1-dbg
liblsan0-dbg libubsan0-dbg libcilkrts5-dbg glibc-doc make-doc
Recommended packages:
linux-image
The following NEW packages will be installed:
binutils cpp cpp-4.8 cpp-4.9 dkms fakeroot gcc gcc-4.8 gcc-4.9 libasan0
libasan1 libatomic1 libc-dev-bin libc6-dev libcilkrts5 libcloog-isl4
libfakeroot libgcc-4.8-dev libgcc-4.9-dev libgomp1 libisl10 libitm1 liblsan0
libmpc3 libmpfr4 libquadmath0 libtsan0 libubsan0 linux-compiler-gcc-4.8-x86
linux-headers-3.16.0-4-amd64 linux-headers-3.16.0-4-common
linux-headers-amd64 linux-kbuild-3.16 linux-libc-dev make manpages-dev
The following packages will be upgraded:
libc6
1 upgraded, 36 newly installed, 0 to remove and 69 not upgraded.
Need to get 13.3 MB/45.0 MB of archives.
After this operation, 153 MB of additional disk space will be used.
Get:1 http://security.debian.org/ jessie/updates/main linux-libc-dev amd64 3.16.39-1+deb8u2 [1,046 kB]
Get:2 http://security.debian.org/ jessie/updates/main linux-compiler-gcc-4.8-x86 amd64 3.16.39-1+deb8u2 [346 kB]
Get:3 http://security.debian.org/ jessie/updates/main linux-headers-3.16.0-4-common amd64 3.16.39-1+deb8u2 [4,542 kB]
Get:4 http://security.debian.org/ jessie/updates/main linux-headers-3.16.0-4-amd64 amd64 3.16.39-1+deb8u2 [451 kB]
Get:5 http://httpredir.debian.org/debian/ jessie/main libc6 amd64 2.19-18+deb8u7 [4,665 kB]
Get:6 http://httpredir.debian.org/debian/ jessie/main libc-dev-bin amd64 2.19-18+deb8u7 [238 kB]
Get:7 http://httpredir.debian.org/debian/ jessie/main libc6-dev amd64 2.19-18+deb8u7 [2,002 kB]
Reading changelogs...
dpkg-preconfigure: unable to re-open stdin: No such file or directory
Fetched 13.3 MB in 52s (252 kB/s)
(Reading database ... 28298 files and directories currently installed.)
Preparing to unpack .../libc6_2.19-18+deb8u7_amd64.deb ...
Unpacking libc6:amd64 (2.19-18+deb8u7) over (2.19-18+deb8u6) ...
Setting up libc6:amd64 (2.19-18+deb8u7) ...
Processing triggers for libc-bin (2.19-18+deb8u6) ...
Selecting previously unselected package libasan0:amd64.
(Reading database ... 28298 files and directories currently installed.)
Preparing to unpack .../libasan0_4.8.4-1_amd64.deb ...
Unpacking libasan0:amd64 (4.8.4-1) ...
Selecting previously unselected package libasan1:amd64.
Preparing to unpack .../libasan1_4.9.2-10_amd64.deb ...
Unpacking libasan1:amd64 (4.9.2-10) ...
Selecting previously unselected package libatomic1:amd64.
Preparing to unpack .../libatomic1_4.9.2-10_amd64.deb ...
Unpacking libatomic1:amd64 (4.9.2-10) ...
Selecting previously unselected package libcilkrts5:amd64.
Preparing to unpack .../libcilkrts5_4.9.2-10_amd64.deb ...
Unpacking libcilkrts5:amd64 (4.9.2-10) ...
Selecting previously unselected package libisl10:amd64.
Preparing to unpack .../libisl10_0.12.2-2_amd64.deb ...
Unpacking libisl10:amd64 (0.12.2-2) ...
Selecting previously unselected package libcloog-isl4:amd64.
Preparing to unpack .../libcloog-isl4_0.18.2-1+b2_amd64.deb ...
Unpacking libcloog-isl4:amd64 (0.18.2-1+b2) ...
Selecting previously unselected package libgomp1:amd64.
Preparing to unpack .../libgomp1_4.9.2-10_amd64.deb ...
Unpacking libgomp1:amd64 (4.9.2-10) ...
Selecting previously unselected package libitm1:amd64.
Preparing to unpack .../libitm1_4.9.2-10_amd64.deb ...
Unpacking libitm1:amd64 (4.9.2-10) ...
Selecting previously unselected package liblsan0:amd64.
Preparing to unpack .../liblsan0_4.9.2-10_amd64.deb ...
Unpacking liblsan0:amd64 (4.9.2-10) ...
Selecting previously unselected package libmpfr4:amd64.
Preparing to unpack .../libmpfr4_3.1.2-2_amd64.deb ...
Unpacking libmpfr4:amd64 (3.1.2-2) ...
Selecting previously unselected package libquadmath0:amd64.
Preparing to unpack .../libquadmath0_4.9.2-10_amd64.deb ...
Unpacking libquadmath0:amd64 (4.9.2-10) ...
Selecting previously unselected package libtsan0:amd64.
Preparing to unpack .../libtsan0_4.9.2-10_amd64.deb ...
Unpacking libtsan0:amd64 (4.9.2-10) ...
Selecting previously unselected package libubsan0:amd64.
Preparing to unpack .../libubsan0_4.9.2-10_amd64.deb ...
Unpacking libubsan0:amd64 (4.9.2-10) ...
Selecting previously unselected package libmpc3:amd64.
Preparing to unpack .../libmpc3_1.0.2-1_amd64.deb ...
Unpacking libmpc3:amd64 (1.0.2-1) ...
Selecting previously unselected package binutils.
Preparing to unpack .../binutils_2.25-5_amd64.deb ...
Unpacking binutils (2.25-5) ...
Selecting previously unselected package cpp-4.9.
Preparing to unpack .../cpp-4.9_4.9.2-10_amd64.deb ...
Unpacking cpp-4.9 (4.9.2-10) ...
Selecting previously unselected package cpp.
Preparing to unpack .../cpp_4%3a4.9.2-2_amd64.deb ...
Unpacking cpp (4:4.9.2-2) ...
Selecting previously unselected package cpp-4.8.
Preparing to unpack .../cpp-4.8_4.8.4-1_amd64.deb ...
Unpacking cpp-4.8 (4.8.4-1) ...
Selecting previously unselected package libgcc-4.9-dev:amd64.
Preparing to unpack .../libgcc-4.9-dev_4.9.2-10_amd64.deb ...
Unpacking libgcc-4.9-dev:amd64 (4.9.2-10) ...
Selecting previously unselected package gcc-4.9.
Preparing to unpack .../gcc-4.9_4.9.2-10_amd64.deb ...
Unpacking gcc-4.9 (4.9.2-10) ...
Selecting previously unselected package gcc.
Preparing to unpack .../gcc_4%3a4.9.2-2_amd64.deb ...
Unpacking gcc (4:4.9.2-2) ...
Selecting previously unselected package make.
Preparing to unpack .../make_4.0-8.1_amd64.deb ...
Unpacking make (4.0-8.1) ...
Selecting previously unselected package dkms.
Preparing to unpack .../dkms_2.2.0.3-2_all.deb ...
Unpacking dkms (2.2.0.3-2) ...
Selecting previously unselected package libfakeroot:amd64.
Preparing to unpack .../libfakeroot_1.20.2-1_amd64.deb ...
Unpacking libfakeroot:amd64 (1.20.2-1) ...
Selecting previously unselected package fakeroot.
Preparing to unpack .../fakeroot_1.20.2-1_amd64.deb ...
Unpacking fakeroot (1.20.2-1) ...
Selecting previously unselected package libgcc-4.8-dev:amd64.
Preparing to unpack .../libgcc-4.8-dev_4.8.4-1_amd64.deb ...
Unpacking libgcc-4.8-dev:amd64 (4.8.4-1) ...
Selecting previously unselected package gcc-4.8.
Preparing to unpack .../gcc-4.8_4.8.4-1_amd64.deb ...
Unpacking gcc-4.8 (4.8.4-1) ...
Selecting previously unselected package libc-dev-bin.
Preparing to unpack .../libc-dev-bin_2.19-18+deb8u7_amd64.deb ...
Unpacking libc-dev-bin (2.19-18+deb8u7) ...
Selecting previously unselected package linux-libc-dev:amd64.
Preparing to unpack .../linux-libc-dev_3.16.39-1+deb8u2_amd64.deb ...
Unpacking linux-libc-dev:amd64 (3.16.39-1+deb8u2) ...
Selecting previously unselected package libc6-dev:amd64.
Preparing to unpack .../libc6-dev_2.19-18+deb8u7_amd64.deb ...
Unpacking libc6-dev:amd64 (2.19-18+deb8u7) ...
Selecting previously unselected package linux-compiler-gcc-4.8-x86.
Preparing to unpack .../linux-compiler-gcc-4.8-x86_3.16.39-1+deb8u2_amd64.deb ...
Unpacking linux-compiler-gcc-4.8-x86 (3.16.39-1+deb8u2) ...
Selecting previously unselected package linux-headers-3.16.0-4-common.
Preparing to unpack .../linux-headers-3.16.0-4-common_3.16.39-1+deb8u2_amd64.deb ...
Unpacking linux-headers-3.16.0-4-common (3.16.39-1+deb8u2) ...
Selecting previously unselected package linux-kbuild-3.16.
Preparing to unpack .../linux-kbuild-3.16_3.16.7-ckt20-1_amd64.deb ...
Unpacking linux-kbuild-3.16 (3.16.7-ckt20-1) ...
Selecting previously unselected package linux-headers-3.16.0-4-amd64.
Preparing to unpack .../linux-headers-3.16.0-4-amd64_3.16.39-1+deb8u2_amd64.deb ...
Unpacking linux-headers-3.16.0-4-amd64 (3.16.39-1+deb8u2) ...
Selecting previously unselected package linux-headers-amd64.
Preparing to unpack .../linux-headers-amd64_3.16+63_amd64.deb ...
Unpacking linux-headers-amd64 (3.16+63) ...
Selecting previously unselected package manpages-dev.
Preparing to unpack .../manpages-dev_3.74-1_all.deb ...
Unpacking manpages-dev (3.74-1) ...
Processing triggers for man-db (2.7.0.2-5) ...
Setting up libasan0:amd64 (4.8.4-1) ...
Setting up libasan1:amd64 (4.9.2-10) ...
Setting up libatomic1:amd64 (4.9.2-10) ...
Setting up libcilkrts5:amd64 (4.9.2-10) ...
Setting up libisl10:amd64 (0.12.2-2) ...
Setting up libcloog-isl4:amd64 (0.18.2-1+b2) ...
Setting up libgomp1:amd64 (4.9.2-10) ...
Setting up libitm1:amd64 (4.9.2-10) ...
Setting up liblsan0:amd64 (4.9.2-10) ...
Setting up libmpfr4:amd64 (3.1.2-2) ...
Setting up libquadmath0:amd64 (4.9.2-10) ...
Setting up libtsan0:amd64 (4.9.2-10) ...
Setting up libubsan0:amd64 (4.9.2-10) ...
Setting up libmpc3:amd64 (1.0.2-1) ...
Setting up binutils (2.25-5) ...
Setting up cpp-4.9 (4.9.2-10) ...
Setting up cpp (4:4.9.2-2) ...
Setting up cpp-4.8 (4.8.4-1) ...
Setting up libgcc-4.9-dev:amd64 (4.9.2-10) ...
Setting up gcc-4.9 (4.9.2-10) ...
Setting up gcc (4:4.9.2-2) ...
Setting up make (4.0-8.1) ...
Setting up dkms (2.2.0.3-2) ...
Setting up libfakeroot:amd64 (1.20.2-1) ...
Setting up fakeroot (1.20.2-1) ...
update-alternatives: using /usr/bin/fakeroot-sysv to provide /usr/bin/fakeroot (fakeroot) in auto mode
Setting up libgcc-4.8-dev:amd64 (4.8.4-1) ...
Setting up gcc-4.8 (4.8.4-1) ...
Setting up libc-dev-bin (2.19-18+deb8u7) ...
Setting up linux-libc-dev:amd64 (3.16.39-1+deb8u2) ...
Setting up libc6-dev:amd64 (2.19-18+deb8u7) ...
Setting up linux-compiler-gcc-4.8-x86 (3.16.39-1+deb8u2) ...
Setting up linux-headers-3.16.0-4-common (3.16.39-1+deb8u2) ...
Setting up linux-kbuild-3.16 (3.16.7-ckt20-1) ...
Setting up linux-headers-3.16.0-4-amd64 (3.16.39-1+deb8u2) ...
Examining /etc/kernel/header_postinst.d.
run-parts: executing /etc/kernel/header_postinst.d/dkms 3.16.0-4-amd64
Setting up linux-headers-amd64 (3.16+63) ...
Setting up manpages-dev (3.74-1) ...
Processing triggers for libc-bin (2.19-18+deb8u6) ...
Copy iso file F:\Outils\VirtualBox\VBoxGuestAdditions.iso into the box /tmp/VBoxGuestAdditions.iso
stdin: is not a tty
mount: /dev/loop0 is write-protected, mounting read-only
Installing Virtualbox Guest Additions 5.1.14 - guest version is unknown
stdin: is not a tty
Verifying archive integrity... All good.
Uncompressing VirtualBox 5.1.14 Guest Additions for Linux...........
VirtualBox Guest Additions installer
Copying additional installer modules ...
Installing additional modules ...
vboxadd.sh: Building Guest Additions kernel modules.
vboxadd.sh: Starting the VirtualBox Guest Additions.

Could not find the X.Org or XFree86 Window System, skipping.
stdin: is not a tty

==> default: Checking for guest additions in VM...
==> default: Mounting shared folders...
default: /vagrant => F:/vagrant_declarations/d8_gitlab
==> default: Running provisioner: shell...
default: Running: inline script
==> default: stdin: is not a tty
==> default: Reading package lists...
==> default: Building dependency tree...
==> default: Reading state information...
==> default: The following extra packages will be installed:
==> default: libcurl3
==> default: The following NEW packages will be installed:
==> default: curl libcurl3
==> default: 0 upgraded, 2 newly installed, 0 to remove and 69 not upgraded.
==> default: Need to get 460 kB of archives.
==> default: After this operation, 933 kB of additional disk space will be used.
==> default: Do you want to continue? [Y/n] Abort.
==> default: Reading package lists...
==> default: Building dependency tree...
==> default: Reading state information...
==> default: aptitude is already the newest version.
==> default: tasksel is already the newest version.
==> default: 0 upgraded, 0 newly installed, 0 to remove and 69 not upgraded.
==> default: open /dev/tty: No such device or address
==> default: debconf: whiptail output the above errors, giving up!
==> default: Use of uninitialized value $ret in scalar chomp at /usr/share/perl5/Debconf/Client/ConfModule.pm line 132, <STDIN> line 27716.
==> default: Use of uninitialized value $ret in split at /usr/share/perl5/Debconf/Client/ConfModule.pm line 133, <STDIN> line 27716.
==> default: Use of uninitialized value $ret[0] in string eq at /usr/share/perl5/Debconf/Client/ConfModule.pm line 134, <STDIN> line 27716.
==> default: tasksel: apt-get failed (255)


Dernière modification par Caniveau Royal ; 09/03/2017 à 08h16.
Répondre

Connectés sur ce fil

 
1 connecté (0 membre et 1 invité) Afficher la liste détaillée des connectés