Merci à Cyril Brulebois pour ses relectures. Pas d'autres commentaires ? -- Thomas Huriaux
#use wml::debian::weeklynews::header PAGENAME="Courriel" #use wml::debian::translation-check translation="1.3" maintainer="Thomas Huriaux" <a name=1></a> <pre> Client : Mutt 0.95.3i Date : Lun. 5 avr. 1999 19 h 53 ' 35 " +0300 De : Andrei D. Caraman <adc@KILI.MEDIASAT.RO> Sujet : Une question sur Apache sur Debian À : BUGTRAQ@NETSPACE.ORG [ Premier avertissement, Je ne me souviens pas avoir vu ceci posté sur Bugtraq, mais n'hésitez pas à le supprimer, si c'est une nouvelle ancienne. ] Cela concerne la configuration d'Apache telle qu'elle est fournie avec Debian 2.1 (surnommée Slink). La configuration par défaut d'Apache (apache_1.3.3-7.deb) rend le répertoire /usr/doc disponible pour tout le monde sur http://un.hôte/doc/. La ligne incriminée est dans le fichier srm.conf : Alias /doc/ /usr/doc/ Ceci permettrait à tous les utilisateurs sur le réseau (malveillant ou pas) de connaître la version exacte de tous les paquets installés sur une machine Debian. Cela semble être plus une question de vie privée que de sécurité. Cependant, si une vulnérabilité affectant l'un de ces paquets est trouvée, les attaquants pourraient déjà connaître les cibles potentielles (et peut-être celles à éviter). Tout d'abord, j'ai pensé que Alias pouvait être désactivé, mais en lisant les lignes ci-dessous (« la ligne ci-dessus est pour les standards du web 3.0 de Debian, qui spécifient que /doc renvoie à /usr/doc. Certains paquets peuvent ne pas marcher autrement »), je dirais que l'accès à cet endroit ne devrait être autorisé qu'au localhost (notez qu'un serveur mandataire web sur la même machine pourrait rendre inutile cette limitation). L'administrateur du site peut facilement changer cela s'il en a besoin. Johnie Ingram (le responsable Debian d'Apache) a été averti, et a répondu que cela avait déjà été formellement signalé sur le système de suivi des bogues par un autre utilisateur Debian (les détails sont disponibles ici : http://www.debian.org/Bugs/db/34/34099.html incluant la correction suggérée : <Directory /usr/doc> AllowOverride None order deny,allow deny from all allow from localhost </Directory> ). Johnie a dit qu'il avait l'intention de changer l'ancienne valeur par défaut dans la prochaine publication. Le 26 mars, il a ainsi déclaré qu'un nouveau paquet Apache allait être envoyé dans les prochains jours, donc je suppose qu'il est déjà sur les miroirs Debian. <propagande> Ce n'est pas un bogue sérieux, puisque Debian est la distribution Linux la plus sécurisée. C'est pourquoi je l'utilise. </propagande> Je ne me suis pas ennuyé à vérifier les autres distributions... Cordialement, ------------------------------------------------------------------------ Andrei D. Caraman Tél. : +40 (1) 2050 637 Ingénieur réseau Fax : +40 (1) 2050 655 Mediasat SA Heures de bureau : 10 h 00 - 18 h 00 GMT </pre> <hr> <a name=2></a> <pre> À : Chris McKillop <cdmckill@warg.uwaterloo.ca> Cc : debian-mentors@lists.debian.org Sujet : Re : Devenir un nouveau développeur De : James Troup <james@nocrew.org> Date : 12 avr. 1999 20 h 02 ' 51 " +0100 Chris McKillop <cdmckill@warg.uwaterloo.ca> a écrit : > Combien de temps faut-il habituellement pour remplir la procédure de > candidature pour les développeurs ? J'ai lu des commentaires > déprimants sur irc parlant de plus de 10 mois. Quelqu'un peut-il > me confirmer cela ? Quelques commentaires aléatoires sans ordre particulier, car je ne veux pas m'ennuyer à prendre le temps d'écrire une réponse propre à tous les courriels de cette discussion. La procédure peut durer 10 minutes comme elle peut durer plus d'un an et demi. La première situation est rare, mais a déjà été vue deux ou trois fois, la deuxième est, bizarrement, habituelle, mais c'est toujours car nous attendons que les candidats viennent vers <u>nous</u> et pas le contraire. Ne crois pas tout ce que tu lis sur IRC, en particulier ce qui vient de certaines personnes. Le processus pour les nouveaux responsables est incroyablement ennuyeux pour bien trop de raisons pour les lister, mais un problème particulier est que les attentes des candidats au niveau de la durée du processus varient fortement. J'ai téléphoné à des personnes avec un retard inexcusable, et ils ont calmement répondu : « Tout va bien, je n'ai même pas encore commencé mon paquet, et je ne le ferai sûrement pas avant un moment ». Ou alors, vous avez des personnes qui vous harcèlent sans arrêt pour une procédure rapide puis ne font rien en tant que développeur pendant des semaines voire des mois après leur intégration. Tu peux accélérer ta candidature en fournissant les informations pertinentes, comme cela est indiqué dans la référence des développeurs. C'est déprimant de voir combien de personnes ne le font toujours pas malgré l'excellent travail de Christian et Adam. Non, je n'ai pas envisagé de mettre un répondeur automatique sur l'adresse new-maintainer@debian.org. Fais juste confiance au fait que c'est arrivé, et si tu n'es pas sûr, envoie-nous une petite note. Nous n'attachons pas d'importance au fait que les personnes nous harcèlent avec de petits messages après un délai raisonnable. Je m'oppose violemment aux personnes qui renvoient de grosses images scannées, je paie pour mes appels à la minute et je n'ai qu'un lent modem 28.8 (et en dehors de tout ça, c'est une chose importante). Dans un domaine similaire, veuillez réduire vos images scannées. En général, 500 Ko sont aussi utiles que 5 Mo. Je suis désolé pour toutes les personnes qui ont attendu si longtemps. Je vais essayer de me réoccuper de vous le plus tôt possible, mais continuez à lire. Les appels téléphoniques provoquent souvent des retards. Je pense qu'ils sont nécessaires, et je ne pense pas les arrêter. Non, je ne peux pas vous envoyer de courriel avant d'appeler, simplement parce que je ne sais jamais quand j'aurai le temps et l'énergie [1] d'appeler jusqu'à la dernière minute. Cela n'a alors plus d'intérêt. Les appels téléphoniques deviennent de moins en moins un problème, puisque j'ai commencé à donner mes informations pour que les personnes puissent <u>optionnellement</u> me téléphoner, quand cela <b>les</b> arrange (avec quelques simples exceptions [Salut, Ed :p]). Cela sera entièrement optionnel, ne coûtera pas beaucoup aux candidats (je les rappellerai immédiatement, si je peux), et évitera, je l'espère, les problèmes des personnes manquantes ou de ceux qui donnent des numéros de téléphone pour une ligne dédiée virtuellement au modem. J'ai essayé ceci la semaine dernière, et, à une seule exception (Salut, Ed :p), cela a bien fonctionné, et les candidats semblent répondre favorablement à l'idée. Bon, je pense que j'ai assez râlé. -- James « L'astuce est de continuer à respirer. » [1] La majorité des appels sont soit faits (pour mon fuseau horaire) tard la nuit, très tôt le matin (Salut, Ed :p) ou tôt le matin. J'ai un emploi demandant une charge de travail énorme, ce qui m'empêche de participer à Debian plus que je ne le voudrais et qui me demande une certaine quantité de sommeil chaque nuit. -- Pour vous désinscrire, envoyez un courriel à debian-mentors-request@lists.debian.org avec comme sujet « unsubscribe ». Des problèmes ? Contactez listmaster@lists.debian.org. </pre> <a name=3></a> <pre> De debian-vote-request@lists.debian.org Dim. 11 avr. 1999 18 h 07 ' 26 " Date : Dim. 11 avr. 1999 11 h 07 ' 10 " -0700 De : Darren O. Benham <gecko@debian.org> À : Martin Schulze <joey@infodrom.north.de> Cc : Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>, debian-vote@lists.debian.org Sujet : Re : le logo : sélection des logos maintenant disponible ! --xo44VMWPx7vlQ2+2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Le dim. 11 avr. 1999 à 11 h 44 ' 21 " +0200, Martin Schulze a écrit: > Marcus Brinkmann a écrit : > > Le sam. 10 avr. 1999 à 12 h 33 ' 51 " +0200, Martin Schulze a écrit : > > > > > > Je suis désolé, mais le premier concours pour le logo n'a été > > > ni public, ni ouvert aux responsables, donc doogie n'a pas eu > > > l'occasion d'intervenir avant > > Apparemment, ça n'a pas été formulé correctement et j'étais pressé. > > Le concours officiel pour le logo (le deuxième) s'est tenu en public. > > Mais les logos que nous pouvons choisir n'ont pas été choisis en public > mais derrière des portes fermées pour que ni doogie ni moi-même ne > puissions intervenir. > > Après cela, le vote est public. > > Vous savez déjà que j'ai essayé de conduire la totalité du concours > dans la bonne direction. Puisque je ne peux pas décider de ce que fait > l'équipe du logo, c'est tout ce que je peux faire - en dehors de > provoquer une révolution, ce qui n'est pas ce que je veux. Il y a autre chose... sans révolution. S'il y a un logo que vous aimez, proposez-le en amendement... Si soit Wichert, soit le comité technique, soit cinq autres développeurs sont d'accord pour ajouter le logo à la liste des choix (sponsor), il sera ajouté au bulletin sans relancer la période de discussion. -- Veuillez m'envoyer une copie de toutes vos réponses aux listes de diffusion. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D * http://benham.net/index.html <gecko@benham.net> <>< * * -------------------- * -----------------------------------------------* * Développeur Debian, Secrétaire du projet, Concepteur du site web * * <gecko@debian.org> <secretary@debian.org> <lintian-maint@debian.org> * * <webmaster@debian.org> <gecko@fortunet.com> <webmaster@spi-inc.org> * =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --xo44VMWPx7vlQ2+2 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GNUPG v0.4.3 (GNU/Linux) Comment: For info finger gcrypt@ftp.guug.de iD8DBQE3EOTObbwt//gBAIoRAVweAKCBMIqcNMLORxD8a0nCxq+W8T8o6gCfRl6O pkFvJNuNNqewx3HneUj3Nyc= =0BOB -----END PGP SIGNATURE----- --xo44VMWPx7vlQ2+2-- -- Pour vous désinscrire, envoyez un courriel à debian-vote-request@lists.debian.org avec comme sujet « unsubscribe ». Des problèmes ? Contactez listmaster@lists.debian.org. </pre> #use wml::debian::weeklynews::footer translator="Thomas Huriaux"
#use wml::debian::weeklynews::header PAGENAME="Courriel"
#use wml::debian::translation-check translation="1.9" maintainer="Thomas Huriaux"
<p>
<a name=1></a>
<strong>Gnome d'octobre </strong> pour <strong>Debian</strong> :
</p>
<ul>
<li> <strong>Debian 2.2</strong> (surnommée <em>Potato</em>) [pas encore
publiée]<p>
Le Gnome d'octobre est déjà inclus.<br> Assurez-vous simplement de
sélectionner le profil « GNOME Workstation » lors de l'installation.
<li> <strong>Debian 2.1</strong> (surnommée <em>Slink</em>)<p>
Procédure d'installation :<br>
<ul>
<li>assurez-vous que « apt » est installé sur votre
système (vous pouvez le télécharger sur
<a href="http://ftp.debian.org/debian/dists/stable/main/binary-i386/admin/apt_0.3.10slink11.deb";>\
http://ftp.debian.org/debian/dists/stable/main/binary-i386/admin/apt_0.3.10slink11.deb</a>) ;
<li>ajoutez la ligne<br>
<pre>deb http://www.debian.org/~vincent/ slink-update main</pre>
dans votre fichier <i>/etc/apt/sources.list</i>.
Pour cela, tapez (en tant que superutilisateur) :
<pre>echo "deb http://www.debian.org/~vincent/ slink-update main" >> /etc/apt/sources.list</pre>
<li>téléchargez et installez les paquets
en utilisant apt ; tapez (en tant que superutilisateur) :
<pre>
apt-get update
apt-get install task-gnome-apps
</pre>
Vous pouvez également utiliser la méthode apt de dselect :
mettez à jour votre fichier sources.list puis faites une mise à
jour dans dselect (et sélectionnez manuellement les paquets que
vous voulez).
</ul>
<p>
Vous pouvez également vouloir parcourir la
<a href="http://www.debian.org/~vincent/dists/slink-update/main/binary-i386/";>\
liste complète des paquets</a> et choisir d'installer individuellement des
paquets supplémentaires en tapant (en tant que superutilisateur) :
<pre>
apt-get install <i>package-name</i> (c'est-à-dire : apt-get install gnumeric)
</pre>
<p>
<strong>Note :</strong>
Le dépôt sera mis à jour de temps en temps pour inclure, le cas échéant,
les nécessaires corrections de bogues. Ainsi, même après la mise à jour,
nous vous encourageons à garder la ligne de ressource dans votre
fichier sources.list, et à taper régulièrement
<tt>apt-get dist-upgrade</tt>.
<li> <strong>Les versions de Debian avant la 2.1</strong> ne sont pas
gérées. Si vous voulez le Gnome d'octobre sur votre Debian 1.3 ou
Debian 2.0, vous devez le recompiler à partir du source
(soit en utilisant
<a href="../../oldurl?http://www.gnome.org/start/gnometar-new.phtml";>les
archives tar amont</a>, soit en utilisant
les <a href="http://www.debian.org/~vincent/dists/slink-update/main/source/";>\
paquets de source de Debian</a>).
</ul>
-- Vincent Renardias <vincent@debian.org> Vendredi
5 novembre 1999 17 h 44 ' 03 " +0100
<hr>
<a name=2></a>
<pre>
À : debian-devel@lists.debian.org
Sujet : Raisonnement d'Adam Di Carlo (était Re : GEL REPLANIFIÉ)
Références : <19991107131936.A1352@xs4all.nl> <l4u2my2xe7.fsf@laminaria.rahul.net> <382594DC.1CAD2BE3@by.net> <19991107183854.B281@paradigm.rfc822.org> <38267D5C.C3FA293A@by.net>
De : Adam Di Carlo <adam@onshore.com>
Date : 8 nov. 1999 21 h 26 ' 14 " -0500
Ci-jointe se trouve une justification du report du gel que j'ai envoyée
au forum slashdot. C'est la première fois que j'ai posté à cet endroit,
mais j'ai très peur de devenir la personne la plus détestée de Debian.
Dans tous les cas, je la poste ici au cas où des personnes veulent la lire.
Veuillez juste me laisser faire une préface en disant que je suis d'accord
avec ceux qui disent qu'un gel reporté de deux mois avec un cycle d'un
mois (si nous le réussissons) est mieux qu'un gel de trois mois. Pour les
développeurs ici, j'espère que vous éviterez d'envoyer des paquets très
instables tant que Potato n'est pas publiée.
--
.....Adam Di Carlo....adam@onShore.com.....<URL:http://www.onShore.com/>
Tous ceux qui observent Debian depuis plus d'un an savent que la période
de gel est une phase très importante du projet. Le gestionnaire de
publication, Richard Braakman, a déclaré son désir que la durée totale
du gel ne soit pas plus longue que trois ou quatre semaines.
La discussion que j'ai eue avec lui concernant l'état de préparation
des disquettes de démarrage, en particulier, n'était que pour s'assurer
qu'il a toutes les informations nécessaires pour faire de son rêve une
réalité. Toute la question est d'entrer dans le gel avec un système
d'installation composé de toutes les fonctionnalités et prêt en version
bêta. Sans cela, ce n'est pas possible. Pour ceux qui se souviennent du
gel de Slink, il y a eu un cycle d'environ 16 semaines (elle a été
gelée au milieu de novembre, avec une publication à la mi-mars),
qui a été plutôt stressant pour tout le monde. Notre objectif est que
le gel soit prévu sur un ensemble assez stable de paquets, ce qui
nous permet complètement de tester plus sainement l'installation à partir
de rien ainsi que les mises à niveau de Slink vers Potato
[Pour votre information, mon estimation actuelle est que nous aurons
des disquettes de démarrage complètes le premier décembre. Je peux l'affirmer
avec la conviction que le premier janvier 2000, nous aurons ce que
j'appelle des disquettes de démarrage « de qualité pour la publication »
(c'est-à-dire ayant été beaucoup testées, mais avec encore un peu de
documentation à faire).]
Laissez-moi juste aborder quelques autres points rapidement.
* La raison principale pour laquelle je veux plus de temps pour les
fonctionnalités des disquettes de démarrage est que je pense qu'elles
sont très importantes. Parcourons-les brièvement : un nouveau
mécanisme de sélection du profil et des métapaquets task, qui permet
de continuer à utiliser ces mécanismes même après l'installation ;
utilisation d'apt dans quasiment tous les cas [pour la récupération
des paquets ; oui, je sais qu'il y a des situations avec des serveurs
mandataires SOCKS et d'autres situations obscures où cela peut ne pas
être une réalité] ; un configurateur d'apt, avec la possibilité
de détecter automatiquement les cédéroms officiels aux endroits
attendus ; la possibilité d'installer base2_2.tgz <i>via</i> http
et peut-être ftp ; ensemble des données réseaux pour bootp et dhcp
lorsque c'est disponible ; superviseur de l'installation du paquet X,
capable de détecter automatiquement le paquet correct du serveur X.
Je pense que ces avancées sont importantes. Même avec le report, j'espère
que nous aurons le temps de les implémenter.
* Ceux qui disent que nous ne gèlerons jamais racontent des bêtises.
Nous désirons fortement nous mettre à jour et rendre obsolète la
distribution Slink.
* En ce qui concerne Linux 2.4, non, nous n'envisageons pas de synchroniser
nos cycles de publications avec ceux de Linux, ce qui devrait être clair
pour tout le monde. Pour le meilleur ou pour le pire. En supposant que
Linux 2.4 est stable (2.2 n'était pas si bien que ça au niveau de la
stabilité lorsqu'il est sorti, AMHA) et sortent dans les prochaines semaines,
il est certain que je ne m'y lancerai pas. Actuellement, nous pensons
utiliser 2.2.13 (même si cela peut varier entre nos 5 architectures
différentes).
* Nous réalisons que les mécanismes actuels de gestion des publications
montrent les limites dues à l'élargissement du projet. Il y a deux approches
possibles pour ce problème : (a) faire plus de « publications intermédiaires »
du système stable, ce qui nécessite simplement une équipe plus importante
qu'actuellement pour s'occuper de la distribution stable après sa
publication ; (b) reconcevoir complètement la gestion des publications,
le candidat le plus probable pour cela étant la proposition de « dépôts
de paquets » -- je n'ai pas de lien sous la main.
* Même avec cela, je voudrais le répéter, Debian reste la seule distribution
ayant un système de mise à niveau robuste et mis à l'épreuve (que ce
soit pour les nouvelles publications, récupérer des paquets de la
distribution instable, ou quoi que ce soit d'autre).
* Tant que nous sommes dans le domaine des « excuses », je ne pense pas
que beaucoup réalisent ici la quantité d'efforts nécessaires pour
coordonner Debian en général (ou les disquettes de démarrage, pour ce
qui nous concerne). Ce travail se réalise en coulisse, et certains d'entre
vous interprètent la lenteur de résolution de cette question comme de
l'indifférence. Je peux vous assurer que nous ne sommes pas indifférents,
en particulier en ce qui concerne la fréquence des publications et la
qualité des disquettes de démarrage.
</pre>
<hr>
<a name=3></a>
<pre>
Date : Mar. 9 nov. 1999 07 h 23 ' 23 " +1100
De : Chris Leishman <masklin@debian.org>
À : debian-devel@lists.debian.org
Sujet : Gel partiel ?
OK,
Voici une autre réflexion (sûrement une qui est déjà ressortie - nous
aimons tourner en rond. Faites-le moi savoir si c'est le cas).
Le problème pour le moment est que personne ne veut du gel, car nous
ne savons pas combien de temps il va durer - et pendant ce temps, les
choses sont bloquées et vieillissent. Et pourquoi ne savons-nous pas
combien de temps nous allons geler ? Car quelques paquets « critiques
à publier » (comme les disquettes de démarrage) ne sont pas stables
et nous ne savons pas combien de temps il faudra avant qu'ils ne le
soient.
Cependant - AMHA si nous ne gelons pas, alors nous sommes dans la même
situation que la distribution instable - à tout moment il peut y avoir
une mise à jour qui va provoquer l'échec d'un nouveau paquet « critique à
publier ». Qui sait - dans un mois quand nous aurons des disquettes de
démarrage, des paquets neufs ou mis à jour (ou une nouvelle charte)
pourraient nous empêcher de geler pour les mêmes raisons...
C'est vraiment un casse-tête. Si nous gelons, alors les choses vont
se stabiliser, mais elles risquent de périmer. Si nous ne gelons pas,
les choses ne périmeront pas, mais elles risquent de ne pas se stabiliser
rapidement.
Que faire alors : Nous identifions les paquets qui sont considérés comme
« critiques à publier ». Cela inclurait les paquets comme les disquettes
de démarrage et la charte. Ensuite nous déclarons un <u>gel de ces
paquets</u>. Les mêmes règles que pour un gel normal s'appliquent - seules
les corrections de bogues sont permises pour ces paquets.
Cependant, les nouveaux envois peuvent continuer pendant que cette chose
se stabilise - tant qu'ils ne créent pas de problème avec les paquets
« critiques à publier ». S'ils en créent, alors les règles du gel
s'appliquent sur cet envoi (pas de nouveau code).
Nous gèlerons éventuellement la distribution complète pendant un court
moment, pour nettoyer les bogues dans les paquets non principaux. Nous
devrions nous imposer une discipline stricte pour cela, et globalement
dire que s'il y avait une version sans <u>nouveau code</u> qui n'a pas
montré de problème, alors nous la gardons plutôt que de corriger des bogues.
OK... la conclusion de cette idée.... Cela <u>peut</u> allonger la
période de gel, puisque nous en faisons en pratique 2. Mais la deuxième
phase (la phase qui peut introduire une stagnation) sera bien plus
courte qu'elle ne l'est dans notre situation actuelle.
Une autre conclusion serait que cela semble être une évidence, et il n'y
a pas besoin de le rendre officiel... mais j'ai toujours trouvé que
ces choses fonctionnent mieux quand elles sont obligatoires.
La dernière question restante est la faisabilité de ce concept...
Cordialement,
Chris
(Souhaitez-moi bonne chance pour mon examen de macroéconomie dans... oh !...
une heure et demie :))
--
----------------------------------------------------------------------
Linux, car j'aimerais *y être* aujourd'hui
----------------------------------------------------------------------
Répondez avec le sujet « request key » pour la clé GPG publique.
Identifiant de clé : 0xB4E24219
</pre>
<hr>
<a name=4></a>
<pre>
À : debian-devel-announce@lists.debian.org
Cc : ftpmaster@debian.org
Répondre-à : ftpmaster@debian.org
Sujet : Nouveaux membre de l'équipe de maintenance de l'archive
De : James Troup <james@nocrew.org>
Date : 9 nov. 1999 00 h 41 ' 51 " +0000
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
[ Veuillez ne pas répondre à debian-devel-announce ]
Salut,
J'aimerais souhaiter publiquement la bienvenue à Gergely Madarasz et
Antti-Juhani Kaijanaho qui rejoignent Guy, Richard et moi en tant que
membres de l'équipe de maintenance de l'archive.
Même si nous n'avons initialement demandé qu'une seule personne pour
aider, nous avons décidé de prendre deux nouveaux membres en raison
du nombre de nouveaux paquets qui sont envoyés tous les jours.
Merci à tous ceux qui se sont gentiment portés volontaires pour aider.
- --
James
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.0 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.4 and Gnu Privacy Guard <http://www.gnupg.org/>
iD8DBQE4J22rgD/uEicUG7ARAlWcAKCSLTKJG76UArnF7ZN9TeQonVGinACg3XPM
A9RkFdHOQK7Kluwp9KEwi0A=
=C8iF
-----END PGP SIGNATURE-----
</pre>
#use wml::debian::weeklynews::footer translator="Thomas Huriaux"
Attachment:
pgpr9kr2OAwUT.pgp
Description: PGP signature