Les gars, j'ai une question un peu bête à vous poser de si bon matin, c'est au sujet de la compilation. Il y a un truc que j'ai pas bien compris et je vais procéder avec un exemple simple :

Je veux Mumble, je ne l'ai pas sur mon système d'exploitation et le site file les sources, ça veut dire que je peux compiler et avoir le programme sur mon ordi ?

Dakien : Oui, il te faudra installer les éventuelles dépendances (incluant les dépendances de développement, à savoir compilateur(s), autotools et compagnie, et suivre les instructions de compilation (dans 90% des softs C/C++ ce sera `./configure && make`.

Je te déconseille de l'installer "en global" {/usr,}/{lib,bin} (braces expantion FTW) par contre (ce que fait `make install` en général), parfois les softs viennent sans règle de désinstallation (`make uninstall` en général), et si t'as pas enregistré l'arborescense avant et après l'installation t'es couillon pour savoir exactement quoi supprimer en temps voulu.

Dans ces cas là je préfère une jail sous FreeBSD (autant en profiter), comme ça si je veux supprimer le soft, j'ai qu'à supprimer la jail.

Les dépendances de développement sont ajoutés automatiquement si elles ne sont pas présente dans le système ?

Du coup je fais configure && make puis ensuite make install ? (ou je fais pas make install)

D'ailleurs, petite question. FreeBSD, lors de la compilation, s'arrête sur chaque dépendance pour te demande quoi installer mais NetBSD ne le fait pas, il y a une option pour ça ou je suis "baisé" ?

Sauf s'il y a un script spécifique avec les sources, les dépendances ne sont pas installées avec le logiciel.
Normalement, elles sont nommées dans le fichier README ou autre, dans le dossier d'installation.

D'accord, merci pour les infos.

Par contre, sous NetBSD j'ai un sacré problème de conflit entre deux paquets et comme j'ai pas la page de selection comme sous FreeBSD, je coince et j'ai pas de pilote vidéo...

Utilise les paquets binaires Dakien

(Avec pkgin)

C'est les ports de FreeBSD qui te proposent d'installer les dépendances. C'est comme pour les packages binaires, c'est lié à un système de paquets/ports particulier (sinon comment savoir le nom du paquet/port à installer pour chaque dépendance ?).

Donc ouais en général c'est dans le README. Si t'as de la chance le ./configure sera capable de déterminer l'emplacement des dépendances comme un grand, sinon t'es bon pour ./configure --help et lui passer les bonnes options pour linker les headers et librairies partagées de chaque dépendance au bon endroit (là où tout est déjà préconfiguré pour un package/port maintenu pour ton système).

Si jamais les dépendances ne sont pas non plus dans les packages/ports, tu continues récursivement, ça peut vite prendre du temps.

J'insiste quand même sur le ./configure (./ devant), c'est un script shell dans le dossier des sources, pas une commande globale (sauf si tu as . dans ton PATH, mais je te le déconseille).

Après le ./configure, make va (normalement) compiler le programme dans le dossier courant, souvent dans un dossier bin, build, ou dist. Tu trouveras un ou des binaires dedans si tout se passe bien, et des .so/.a si tu compiles une librairie.

Si tu veux installer globalement, make install devrait se charger de copier ce qu'il faut dans les dossiers systèmes, mais si y'a pas de règle propre de désinstallation, j'éviterais clairement. Si tu veux installer dans un autre dossier, il y a des chances que le makefile supporte make install PREFIX=/path/to/prefix, dossier dans lequel il recrééera une architecture avec bin, lib, usr/* et ainsi de suite. Mais lis bien la doc (ou look la source du makefile), parce que des fois c'est pas PREFIX mais autre chose.

Si tu veux un exemple, voilà ce qu'il faut faire pour compiler libsodium dans un dossier local (et donc sans avoir besoin de droits root), puis linker toxcore à la librairie installée localement et le compiler lui-même dans le même préfixe : https://github.com/valeriangalliat/tox-user-install/blob/b40f0b03d7683cbd1f4ede15f1ff9e621f1c9c7b/tox-user-install#L40-L70

C'est pas une partie de plaisir, mais je considère ça plus propre que de faire des su -c 'make install' bourrins qui modifient les dossiers systèmes.

Mais ça c'est bien pour des sources non maintenues par ton système, dans le cas des ports officiels sur *BSD (et c'est certainement similaire sous Gentoo), tu peux make install sans problèmes dans la mesure ou c'est prévu par les mainteneurs pour que ça cohabite prorement avec ton système.

Le pilote n'est pas en binaire malheureusement

Ok merci pour tous ces renseignements, la j'avoue bien plus comprendre comment tout ça fonctionne
Donc, pour tout ce qui est hors /usr/pkgsrc (l'endroit où sont les ports officiels de NetBSD), je "jail"erai ça chez moi et en non-root (j'ai déjà pas mal bricolé avec des path sous Linux, ça ne me fait pas peur)

Pour le problème du libdrm qui fait conflit, j'ai fait un report de bug pour voir d'où ça peut venir (c'est l'unique moyen pour moi d'installer ma carte graphique et il se fait un conflit à lui même... faut le faire !)

De côté de FreeBSD, j'ai tout installé via pkg install "paquet", ça m'a prit 5 minutes et je lançait déjà X avec tout ce qui va bien puisque les pilotes sont dispo en binaire.

Au fait hier, testdisk avec l'analyse profonde (~3h sur mon 1 Tio) a pu détecter *toutes* mes partitions ! Après il suffit de lui dire où sont les partitions primaires/logiques, et il regen la table de partitions.

On peut même parcourir les partitions récupérées depuis l'interface et faire directement des backups ! http://youtu.be/l7-6m2cE6JM

J'ai juste perdu tous mes bootloaders, faudra que je déterre un DVD de Windows pour réparer ça, sauf si y'a un outil sous Linux qui me permette de réinstaller/réparer un bootloader Windows ?

J'ai installé Ubuntu sur la partition que j'avais prévue pour OpenBSD du coup (c'est par où le bûcher ?). C'est une 12.04, j'en profiterai pour tester la mise à jour d'un système Ubuntu "à vide", pour le fun.

Ça m'a permis d'avoir au moins Grub, qui a bien détecté mon Arch et les deux Windows (même si comme je disais les bootloaders Windows sont dead, même si Grub peut chain dessus). Mais j'ai pu booter sur mon Arch qui est intacte.

D'ailleurs j'ai trouvé l'installeur d'Ubuntu plutôt bien foutu, l'étape de partitionnement est particulièrement claire ( ), je pourrais même laisser mon lama partitionner le disque en toute confiance, et on peut choisir de chiffrer son home à la création de l'utilisateur (aucune idée de ce qu'ils utilisent derrière par contre). Les barres de progression pendant l'installation sont plutôt agréables (honnêtement ça manque pendant les installations cli, avec une petite estimation de temps), et on peut aussi afficher le "vrai" log d'installation pour avoir les détails (donc pour le coup ils copient pas totalement l'obscurantisme de Windows et ça fait plaisir).

Notons quand même que j'ai du pkill X en TTY pendant la récupération de disque sur le live CD d'Ubuntu, parce qu'avec Firefox et 3 terminaux d'ouverts ça m'avait complètement freezé l'interface (j'ai 4 Gio de RAM hein) (enfin j'ai au moins pu basculer en TTY, sur Debian j'au eu plusieurs fois le problème ou j'avais un freez général sans pouvoir passer en TTY — mais c'était sûrement une cause différente). C'est dans ces cas là que j'aime tmux, WeeChat et w3m.

Bref, je suis content, j'ai plutôt bien réparé mes conneries. Noraj de mon rattrapage. ~ ~

Conclusion, faut vraiment tester le multiboot OpenBSD sur un disque *de test* avant de faire ça en production (comme précisé sur la doc après tout).

Deuxième conclusion, testdisk ça déchire sa maman.

Je sais que sur NetBSD, il te le répète une sacré paire de fois en disant (pour l'instant, rien n'a été encore fait, vous voulez vraiment continuer) jusqu'au dernier moment où il dit "ça y est, c'est la, c'est irréversible, on continue ?"

« j'en profiterai pour tester la mise à jour d'un système Ubuntu "à vide", pour le fun. »

C'est probablement la situation dans laquelle ça a le plus de chances de marcher (et c'est probablement le cas de tous ceux qui viennent faire chier leur monde avec pour slogan "chez moi ubuntu marche très bien, ça marche forcément pareil pour tout le monde :genius:").

Dakien : Raison de plus pour que je teste NetBSD sous peu.

Google_Bot : Pour corser un peu le truc je peux installer quelques paquets alors, mais bon c'est un coup à ce que j'installe que des paquets que j'utilise habituellement, donc globalement des trucs très légers et souvent cli. Faut dire que j'y mets pas du mien pour avoir un système qui pète facilement, même sous Ubuntu.

Salut , quand je lance TF sur steam , il me marque un message d'erreur :
could not find required opengl entry point

Il faut que je mette a jour mes pilotes graphique , je ne sait pas du tout comment faire , j'ai une GTX 770

Merci pour l'aide

SaumonHD Active les dépots non-free si c'est pas déjà fait pour récupérer le paquet contenant le paquet propriétaire

Hint: « debian nvidia » sur Google, tu devrais tomber sur le nVidia howto du wiki officiel.

https://wiki.debian.org/fr/NvidiaGraphicsDrivers
Oui mais je panne pas grand chose

et je suis sous debian jessie, il proposent que wheezy

Je te laisse lire la page correspondante du wiki Debian-Facile: http://wiki.debian-facile.org/doc:materiel:cartes-graphique:nvidia:accueil

Mais tu veux installer les drivers pendant une période charnière de transition de paquets: il va te manquer un paquet indispensable: nvidia-settings .
Ce paquet permet de configurer graphiquement la carte.

https://packages.debian.org/search?keywords=nvidia-settings&searchon=names&suite=all&section=all&sourceid=mozilla-search

En attendant, pour ce paquet, tu peux récupérer le .deb (de mémoire il y a 2 autres dépendances à récupérer aussi) qui va bien sur snapshop-debian:
http://snapshot.debian.org/package/nvidia-settings/337.19-1/

Les snapshots de nvidia-settings sont à la version 337 ; la où le driver en lui même est en version 340 (et plus potentiellement).
Mais rassure toi c'est parfaitement compatible.