From: Charles Plessy Date: Tue, 28 Jun 2011 23:58:52 +0000 (+0900) Subject: Plus court. X-Git-Url: https://source.charles.plessy.org/?a=commitdiff_plain;h=a5ce88ed98604e77ca4b0fbe87cef58c5a685788;p=source.git Plus court. --- diff --git "a/Debian/debi\303\242neries/bioperl-et-tests.en.po" "b/Debian/debi\303\242neries/bioperl-et-tests.en.po" index cfe07065..e60c70f8 100644 --- "a/Debian/debi\303\242neries/bioperl-et-tests.en.po" +++ "b/Debian/debi\303\242neries/bioperl-et-tests.en.po" @@ -4,11 +4,12 @@ # Charles Plessy , 2011. # Charles Plessy , 2011. # Charles Plessy , 2011. +# Charles Plessy , 2011. msgid "" msgstr "" "Project-Id-Version: PACKAGE VERSION\n" "POT-Creation-Date: 2011-06-29 07:37+0900\n" -"PO-Revision-Date: 2011-06-29 08:14+0900\n" +"PO-Revision-Date: 2011-06-29 08:23+0900\n" "Last-Translator: Charles Plessy \n" "Language-Team: Hopla\n" "Language: en\n" @@ -67,7 +68,7 @@ msgid "" "est construit localement." msgstr "Two weeks ago, I updated the packages containing the BioPerl modules " "[[!debpkg bioperl]] and [[!debpkg bioperl-run]], which allowed to resume the " -"work done on [!debpkg gbrowse desc=\"GBrowse\"]], one of the [[genome " +"work done on [[!debpkg gbrowse desc=\"GBrowse\"]], one of the [[genome " "browsers|gbrowse]] available in Debian. As many Perl modules, BioPerl has " "extensive [regression " "tests](http://www.bioperl.org/wiki/HOWTO:Writing_BioPerl_Tests). Some of " @@ -96,7 +97,7 @@ msgid "" "parce qu'un programme a été renommé dans Debian. Dans d'autres cas, en " "particulier [[!debpkg wise desc=\"DBA et Genewise\"]], il est beaucoup plus " "difficile de déterminer de quel côté est le problème." -msgstr "Bioperl sucessfully passes all off-line tests, and a part of the on-line " +msgstr "Bioperl successfully passes all off-line tests, and a part of the on-line " "tests is already corrected its [development " "branch](https://github.com/bioperl/bioperl-live/tree/HEAD/t). In contrary, " "BioPerl-Run fail the tests for Bowtie, DBA, EMBOSS, Genewise, Hmmer, PAML, " @@ -180,10 +181,10 @@ msgid "" "qu'un seul programme manquant n'invalide complètement un paquet qui ne s'en " "sert que de manière optionnelle." msgstr "Second, this does not allow testing on the user side. The [Debian " -"Enhancement Proposal 8](http://dep.debian.net/deps/dep8/) whose goal is to " +"Enhancement Proposal 8](http://dep.debian.net/deps/dep8/), whose goal is to " "test programs as they are packaged, is a step in a good direction. Perhaps " -"will it be possible to extend this project, for testing binary packages by " +"will it be possible to extend this project for testing binary packages by " "themselves. This would allow to perform the tests not during the build but " "just after, and take advantage of the flexible levels of dependency between " "binary packages, so that the unavailability of one program does not prevent " -"the build of a packages that can use it on a completely optional manner.\n" +"the build of a package that can use it on a completely optional manner.\n" diff --git "a/Debian/debi\303\242neries/bioperl-et-tests.mdwn" "b/Debian/debi\303\242neries/bioperl-et-tests.mdwn" index 93929374..6f01ad81 100644 --- "a/Debian/debi\303\242neries/bioperl-et-tests.mdwn" +++ "b/Debian/debi\303\242neries/bioperl-et-tests.mdwn" @@ -41,16 +41,10 @@ construction](https://buildd.debian.org/status/logs.php?pkg=t-coffee&ver=8.99-1) Mais cela pose aussi des problèmes. Premièrement, cela demande de dépendre de tous les programmes pour lesquels un paquet fournit une interface si on veut le tester efficacement. Pour reprendre l'exemple de bioperl-run, cela rends sa -construction impossible sur le portage armel tant que t-coffee y défectueux sur -armel. +construction impossible sur le portage armel tant que t-coffee y défectueux. +Deuxièmement, cette approche n'aide pas l'utilisateur à tester pareillement un +programme installé sur son système. -Deuxièmement, ça n'est pas suffisant si on veut permettre aussi à l'utilisateur -de tester pareillement un programme installé sur son système. La proposition -[DEP 8](http://dep.debian.net/deps/dep8/), dont le but est de tester au moment -de la construction les programmes tels qu'ils sont empaquetés, est un pas dans -une bonne direction. Peut-être ce système pourra-t-il être étendu pour qu'on -puisse aussi tester les paquets binaires. Cela permettrait aussi de faire les -tests non pas au moment de la construction, mais juste après, et ainsi profiter -de la plus grande flexibilité des relations de dépendances entre paquets -binaires, pour éviter qu'un seul programme manquant n'invalide complètement un -paquet qui ne s'en sert que de manière optionnelle. +La proposition [DEP 8](http://dep.debian.net/deps/dep8/), pour tester des +paquets binaires avec du matériel fourni par leurs paquets source, va peut-être +régler ces deux problèmes.