guix/documentation-manual — French @ Fedora Weblate: Those wishing to inspect the results of failed tests directly …

The translation is temporarily closed for contributions due to maintenance, please come back later.
The translation was automatically locked due to following alerts: Could not update the repository.

Zen

Translation

English

type: Plain text

French

Needs editing

This translation is currently locked.

Skip

	English	French	Actions
	You are advised to run @command{make authenticate} after every @command{git pull} invocation. This ensures you keep receiving valid changes to the repository.	Nous vous conseillons d'exécuter @command{make authenticate} après chaque invocation de @command{git pull}. Cela vous garantit de continuer à recevoir des modifications valables dans le dépôt.
	After updating the repository, @command{make} might fail with an error similar to the following example:	Après la mise à jour du dépôt, @command{make} peut échouer avec une erreur semblable à celle de l'exemple suivant :
	error: failed to load 'gnu/packages/linux.scm': ice-9/eval.scm:293:34: In procedure abi-check: #<record-type <origin>>: record ABI mismatch; recompilation needed	error: failed to load 'gnu/packages/dunst.scm': ice-9/eval.scm:293:34: In procedure abi-check: #<record-type <origin>>: record ABI mismatch; recompilation needed
	This means that one of the record types that Guix defines (in this example, the @code{origin} record) has changed, and all of guix needs to be recompiled to take that change into account. To do so, run @command{make clean-go} followed by @command{make}.	Cela signifie qu'un des types d'enregistrement que Guix définie (dans cet exemple, l'enregistrement @code{origin}) a changé, et que l'entièreté de guix doit être recompilé pour prendre ce changement en compte. Pour ce faire, lancez @command{make clean-go} suivi de @command{make}.
	Should @command{make} fail with an Automake error message after updating, you need to repeat the steps outlined in this section, commencing with @command{./bootstrap}.
	test suite	suite de tests
	After a successful @command{configure} and @code{make} run, it is a good idea to run the test suite. It can help catch issues with the setup or environment, or bugs in Guix itself---and really, reporting test failures is a good way to help improve the software. To run the test suite, type:	Après avoir lancé @command{configure} et @code{make} correctement, c'est une bonne idée de lancer la suite de tests. Elle peut aider à trouver des erreurs avec la configuration ou l'environnement, ou des bogues dans Guix lui-même — et vraiment, rapporter des échecs de tests est une bonne manière d'aider à améliorer le logiciel. Pour lancer la suite de tests, tapez :
	make check	make check
	Test cases can run in parallel: you can use the @code{-j} option of GNU@tie{}make to speed things up. The first run may take a few minutes on a recent machine; subsequent runs will be faster because the store that is created for test purposes will already have various things in cache.	Les cas de tests peuvent être lancés en parallèle : vous pouvez utiliser l'option @code{-j} de GNU@tie{}make pour accélérer les choses. Le premier lancement peut prendre plusieurs minutes sur une machine récente ; les lancements suivants seront plus rapides car le dépôt créé pour les tests aura déjà plusieurs choses en cache.
	It is also possible to run a subset of the tests by defining the @code{TESTS} makefile variable as in this example:	Il est aussi possible de lancer un sous-ensemble des tests en définissant la variable makefile @code{TESTS} comme dans cet exemple :
	make check TESTS="tests/store.scm tests/cpio.scm"	make check TESTS="tests/store.scm tests/cpio.scm"
	By default, tests results are displayed at a file level. In order to see the details of every individual test cases, it is possible to define the @code{SCM_LOG_DRIVER_FLAGS} makefile variable as in this example:	Par défaut, les résultats des tests sont affichés au niveau du fichier. Pour voir les détails de chaque cas de test individuel, il est possible de définir la variable makefile @code{SCM_LOG_DRIVER_FLAGS} comme dans cet exemple :
	make check TESTS="tests/base64.scm" SCM_LOG_DRIVER_FLAGS="--brief=no"	make check TESTS="tests/base64.scm" SCM_LOG_DRIVER_FLAGS="--brief=no"
	The underlying SRFI 64 custom Automake test driver used for the 'check' test suite (located at @file{build-aux/test-driver.scm}) also allows selecting which test cases to run at a finer level, via its @option{--select} and @option{--exclude} options. Here's an example, to run all the test cases from the @file{tests/packages.scm} test file whose names start with ``transaction-upgrade-entry'':	Le pilote de tests Automake personnalisé avec SRFI 64 utilisé pour la suite de tests « check » (située dans @file{build-aux/test-driver.scm}) permet aussi de choisir les cas de test à lancer à plus fine granularité, via ses options @option{--select} et @option{--exclude}. Voici un exemple, pour lancer tous les cas de tests du fichier de tests @file{tests/packages.scm} dont les noms commencent par « transaction-upgrade-entry » :
	export SCM_LOG_DRIVER_FLAGS="--select=^transaction-upgrade-entry" make check TESTS="tests/packages.scm"	export SCM_LOG_DRIVER_FLAGS="--select=^transaction-upgrade-entry" make check TESTS="tests/packages.scm"
	Those wishing to inspect the results of failed tests directly from the command line can add the @option{--errors-only=yes} option to the @code{SCM_LOG_DRIVER_FLAGS} makefile variable and set the @code{VERBOSE} Automake makefile variable, as in:	Pour celles et ceux qui veulent inspecter les résultats des tests échoués directement depuis la ligne de commande, il est possible d'ajouter l'option @option{--errors-only=yes} à la variable @code{SCM_LOG_DRIVER_FLAGS} du Makefile et d'initialiser la variable Automake du Makefile @code{VERBOSE}, de cette manière :
	make check SCM_LOG_DRIVER_FLAGS="--brief=no --errors-only=yes" VERBOSE=1	make check SCM_LOG_DRIVER_FLAGS="--brief=no --errors-only=yes" VERBOSE=1
	The @option{--show-duration=yes} option can be used to print the duration of the individual test cases, when used in combination with @option{--brief=no}:	L'option @option{--show-duration=yes} peut être utilisée pour afficher la durée des cas de test individuels, en combinaison avec @option{--brief=no} :
	make check SCM_LOG_DRIVER_FLAGS="--brief=no --show-duration=yes"	make check SCM_LOG_DRIVER_FLAGS="--brief=no --show-duration=yes"
	@xref{Parallel Test Harness,,,automake,GNU Automake} for more information about the Automake Parallel Test Harness.	@xref{Parallel Test Harness,,,automake,GNU Automake} pour plus d'information sur le banc de tests parallèle d'Automake.
	Upon failure, please email @email{bug-guix@@gnu.org} and attach the @file{test-suite.log} file. Please specify the Guix version being used as well as version numbers of the dependencies (@pxref{Requirements}) in your message.	Après un échec, envoyez un courriel à @email{bug-guix@@gnu.org} et attachez le fichier @file{test-suite.log}. Précisez la version de Guix utilisée ainsi que les numéros de version de ses dépendances (@pxref{Requirements}) dans votre message.
	Guix also comes with a whole-system test suite that tests complete Guix System instances. It can only run on systems where Guix is already installed, using:	Guix possède aussi une suite de tests de systèmes complets qui test des instances complètes du système Guix. Elle ne peut être lancée qui sur un système où Guix est déjà installé, avec :
	make check-system	make check-system
	or, again, by defining @code{TESTS} to select a subset of tests to run:	ou, de nouveau, en définissant @code{TESTS} pour choisir un sous-ensemble des tests à lancer :
	make check-system TESTS="basic mcron"	make check-system TESTS="basic mcron"
	These system tests are defined in the @code{(gnu tests @dots{})} modules. They work by running the operating systems under test with lightweight instrumentation in a virtual machine (VM). They can be computationally intensive or rather cheap, depending on whether substitutes are available for their dependencies (@pxref{Substitutes}). Some of them require a lot of storage space to hold VM images.	Ces tests systèmes sont définis dans les modules @code{(gnu tests @dots{})}. Ils fonctionnent en lançant les systèmes d'exploitation sous test avec une instrumentation légère dans une machine virtuelle (VM). Ils peuvent être intenses en terme de calculs ou plutôt rapides en fonction de la disponibilité des substituts de leurs dépendances (@pxref{Substituts}). Certains requièrent beaucoup d'espace disque pour contenir les images des VM@.
	Again in case of test failures, please send @email{bug-guix@@gnu.org} all the details.	De nouveau, en cas d'échec, envoyez tous les détails à @email{bug-guix@@gnu.org}.
	In order to keep a sane working environment, you will find it useful to test the changes made in your local source tree checkout without actually installing them. So that you can distinguish between your ``end-user'' hat and your ``motley'' costume.	Pour garder un environnement de travail sain, il est utile de tester les changement localement sans les installer pour de vrai. Pour pouvoir distinguer votre rôle « d'utilisateur·rice final·e » de celui parfois haut en couleur de « développeur·euse ».
	To that end, all the command-line tools can be used even if you have not run @code{make install}. To do that, you first need to have an environment with all the dependencies available (@pxref{Building from Git}), and then simply prefix each command with @command{./pre-inst-env} (the @file{pre-inst-env} script lives in the top build tree of Guix; @pxref{Building from Git} to generate it). As an example, here is how you would build the @code{hello} package as defined in your working tree (this assumes @command{guix-daemon} is already running on your system; it's OK if it's a different version):	Pour cela, tous les outils en ligne de commande sont utilisables même sans avoir lancé @code{make install}. Pour faire cela, vous devez d'abord avoir un environnement avec toutes les dépendances disponibles (@pxref{Building from Git}), et puis préfixer simplement chaque commande avec @command{./pre-inst-env} (le script @file{pre-inst-env} se trouve dans le répertoire de plus haut niveau de l'arborescence des sources de Guix ; il est généré en lançant @command{./bootstrap} suivit de @command{./configure}). À titre d'exemple, voici comment construire le paquet @code{hello} tel que défini dans votre arborescence de travail (cela suppose que @command{guix-daemon} fonctionne déjà sur votre système ; c'est OK si c'est une version différente) :
	$ ./pre-inst-env guix build hello	$ ./pre-inst-env guix build hello
	Similarly, an example for a Guile session using the Guix modules:	De même, pour une session Guile qui utilise les modules Guix :

Loading…

roptat

Translation added

English

French 315 characters edited Current translation

3 years ago

Browse all string changes

Things to check

Consecutive duplicated words

Text contains the same word twice in a row: option

Reset

Glossary

English	French
No related strings found in the glossary.

String information

Source string description

type: Plain text

Source string location

guix-git/doc/contributing.texi:360

String age

3 years ago

Last updated

10 months ago

Source string age

3 years ago

Translation file

po/doc/guix-manual.fr.po, string 129