[Debian-l10n-devel] Mail delivery failed: returning message to sender
Nicolas François
nicolas.francois at centraliens.net
Tue Dec 29 11:07:22 UTC 2009
Hello,
See below, mails from churro are rejected by liszt. Is there anything I/we
should do to fix this?
Cheers,
--
Nekral
On Sun, Dec 27, 2009 at 06:20:38AM +0100, Mailer-Daemon at i18n.debian.net wrote:
> This message was created automatically by mail delivery software.
>
> A message that you sent could not be delivered to one or more of its
> recipients. This is a permanent error. The following address(es) failed:
>
> debian-l10n-french at lists.debian.org
> SMTP error from remote mail server after RCPT TO:<debian-l10n-french at lists.debian.org>:
> host liszt.debian.org [82.195.75.100]: 450 4.1.7 <nekral at i18n.debian.net>:
> Sender address rejected: unverified address: connect to i18n.debian.net[217.124.178.10]:25:
> Connection refused: retry timeout exceeded
>
> ------ This is a copy of the message, including all the headers. ------
>
> Return-path: <nekral at i18n.debian.net>
> Received: from nekral by i18n.debian.net with local (Exim 4.69)
> (envelope-from <nekral at i18n.debian.net>)
> id 1NOlYF-0004KN-5H
> for debian-l10n-french at lists.debian.org; Sun, 27 Dec 2009 06:20:23 +0100
> MIME-Version: 1.0
> Content-Transfer-Encoding: binary
> Content-Type: multipart/mixed; boundary="_----------=_1261891220164401"
> X-Mailer: MIME::Lite 3.023 (F2.76; T1.24; A2.03; B3.07_01; Q3.07)
> Date: Sun, 27 Dec 2009 06:20:20 +0100
> From: Debian WWW translation watch <debian-www at lists.debian.org>
> To: debian-l10n-french at lists.debian.org
> Subject: Pages web a mettre a jour
> Message-Id: <E1NOlYF-0004KN-5H at i18n.debian.net>
>
> This is a multi-part message in MIME format.
>
> --_----------=_1261891220164401
> MIME-Version: 1.0
> Content-Disposition: inline
> Content-Length: 884
> Content-Transfer-Encoding: binary
> Content-Type: text/plain; charset="utf-8"
> X-Mailer: MIME::Lite 3.023 (F2.76; T1.24; A2.03; B3.07_01; Q3.07)
> Date: Sun, 27 Dec 2009 06:20:20 +0100
>
> Bonjour,
>
> Ce message automatique vous est adressé car vous êtes le responsable de
> certaines pages du site web Debian qui sont traduites en français.
> Vous avez demandé à recevoir les informations suivantes :
> summary: quotidien
> logs: quotidien
> diff: quotidien
> tdiff: jamais
> file: jamais
>
> Vous pouvez demander de changer :
> - la fréquence des messages (jamais, quotidiens, hebdomadaires,
> mensuels) ;
> - les informations que vous souhaitez recevoir :
> * le résumé des fichiers à mettre à jour
> * les messages de logs entre la révision actuelle et celle à jour
> * les différences entre la révision actuelle et celle à jour
> * éventuellement les fichiers que vous devez mettre à jour
> - votre adresse électronique
>
> Si vous avez des questions sur ce message, veuillez les envoyer sur la
> liste de discussion debian-l10n-french at lists.debian.org
>
>
> --_----------=_1261891220164401
> Content-Disposition: inline; filename="NeedToUpdate summary"
> Content-Length: 259
> Content-Transfer-Encoding: binary
> Content-Type: text/plain; name="NeedToUpdate summary"
>
> NeedToUpdate french/devel/buildd/wanna-build-states.wml from revision 1.19 to revision 1.21 (maintainer Mohammed Adnène Trojette)
> NeedToUpdate french/ports/hurd/hurd-devel-debian.wml from revision 1.31 to revision 1.33 (maintainer Mohammed Adnène Trojette)
>
> --_----------=_1261891220164401
> Content-Disposition: inline; filename="english/devel/buildd/wanna-build-states.wml.diff"
> Content-Transfer-Encoding: quoted-printable
> Content-Type: text/plain; name="english/devel/buildd/wanna-build-states.wml.diff"
>
> --- english/devel/buildd/wanna-build-states.wml 1 Dec 2008 10:55:55 -0000 1=
> .19
> +++ english/devel/buildd/wanna-build-states.wml 19 Nov 2009 10:39:19 -0000 =
> 1.21
> @@ -1,7 +1,7 @@
> #use wml::debian::template title=3D"Wanna-build states: an explanation" BA=
> RETITLE=3D"true"
> =20
> <p>This page tries to explain what every wanna-build state means
> - and what will happen to a package when it's in that state. It's
> + and what will happen to a package when it's in that state. Its
> target audience are Debian package maintainers that try to
> understand why their package has, or has not, been built for a
> specific architecture. Also, an explanation of the different log
> @@ -14,9 +14,9 @@
> <h2>The wanna-build states</h2>
> <p>For every Debian-supported architecture, there's a wanna-build
> database installed on buildd.debian.org, with all packages and their curre=
> nt
> -compilation state. There are 7 states: <em>needs-build</em>,
> +compilation state. There are 8 states: <em>needs-build</em>,
> <em>building</em>, <em>uploaded</em>, <em>dep-wait</em>,
> -<em>failed</em>, <em>not-for-us</em>, and
> +<em>BD-Uninstallable</em>, <em>failed</em>, <em>not-for-us</em>, and
> <em>installed</em>.</p>
> =20
> <p>Their meaning is as follows:</p>
> @@ -121,6 +121,30 @@
> <tt>m68k</tt>, then the <em>dep-wait</em> state for <tt>m68k</tt> will
> have to be manually lifted by the <tt>m68k</tt> porters.
> </dd>
> + <dt><a name=3D"bd-uninstallable">BD-Uninstallable</a></dt>
> + <dd>During debconf9, <a
> + href=3D'http://lists.debian.org/debian-wb-team/2009/07/msg00089.html'>Joa=
> chim
> + Breitner had the idea</a> of using edos-debcheck to verify
> + build-dependency installability of packages that would otherwise
> + go into state Needs-Build. At that point, wanna-build already
> + had the ability to check the immediate availability of
> + build-dependencies; but if a package couldn't be installed
> + because it build-depends on a which depends on b which depends
> + on c (>=3D1.2.3) and c is still at version 1.2.2, this would
> + not be detected, and the build would fail early because of
> + unavailable build-dependencies. Figuring those out was a manual
> + process for the buildd admin, and, usually, a lengthy one at
> + that. With the BD-Uninstallable patch, this is no longer a
> + problem. When your package is in BD-Uninstallable, it means one
> + of the build-dependencies is not installable (either
> + immediately, or because part of its dependency tree is not
> + available). Unfortunately, the BD-Uninstallable patch does not
> + provide information about which package, exactly, is missing;
> + please use edos-debcheck to find out. This problem will,
> + however, solve itself once the missing dependencies are indeed
> + available, and at that point your package will automatically
> + move to Needs-Build again.
> + </dd>
> <dt><a name=3D"wanna-build-state-failed">failed</a></dt>
> <dd>If a build attempt failed, and the autobuilder maintainer
> decides it is really a failure that should not be retried, a
> @@ -182,7 +206,7 @@
> average.
> </dd>
> </dl>
> - <p>In addition to these seven states, <em>wanna-build</em> also
> + <p>In addition to these eight states, <em>wanna-build</em> also
> knows two -removed states, which are really corner cases. These
> two states are <em>dep-wait-removed</em> and
> <em>failed-removed</em>. They relate to their respective <q>plain</q>
>
> --_----------=_1261891220164401
> Content-Disposition: inline; filename="english/ports/hurd/hurd-devel-debian.wml.diff"
> Content-Transfer-Encoding: quoted-printable
> Content-Type: text/plain; name="english/ports/hurd/hurd-devel-debian.wml.diff"
>
> --- english/ports/hurd/hurd-devel-debian.wml 12 Jan 2007 16:16:45 -0000 1.31
> +++ english/ports/hurd/hurd-devel-debian.wml 25 Nov 2009 19:03:22 -0000 1.33
> @@ -97,118 +97,11 @@
> <h3>
> General Porting Issues</h3>
> <p>
> -Here is a list of common incompatibilities you may encounter when compiling
> -insufficient portable software on the Hurd.</p>
> +<a href=3Dhttp://www.gnu.org/software/hurd/hurd/porting/guidelines.html>A =
> list of common issues</a> is available on the upstream website. The followi=
> ng common issues are specific to Debian.</p>
> =20
> <ul>
> <li>
> -<code>Bad File Descriptor</code>
> +<code>Broken libc6 dependency</code>
> <p>
> -If you get <code>Bad File Descriptor</code> error when trying to read
> -from a file (or accessing it at all), check the <code>open()</code>
> -invocation. The second argument is the access method. If it is a hard
> -coded number instead of a symbol defined in the standard header files,
> -the code is screwed and should be fixed to either use
> -<code>O_RDONLY</code>, <code>O_WRONLY</code> or
> -<code>O_RDWR</code>. This bug was observed in the
> -<code>fortunes</code> and <code>mtools</code> packages for
> -example.</p></li>
> -<li>
> -<code>PATH_MAX</code>
> -<p>
> -Every unconditionalized use of <code>PATH_MAX</code> is a POSIX
> -incompatibility. If there is no upper limit on the length of a path,
> -this symbol is not defined in any header file. Instead, you need to
> -either use a different implementation that does not rely on the length
> -of a string or use <code>sysconf()</code> to query the length at
> -runtime. If <code>sysconf()</code> returns <code>-1</code>, you have
> -to use <code>realloc()</code> to allocate the needed memory
> -dynamically.</p></li>
> -<li>
> -<code>MAXHOSTNAMELEN</code>
> -<p>
> -see <code>PATH_MAX</code></p></li>
> -<li>
> -<code>MAXPATHLEN</code>
> -<p>
> -see <code>PATH_MAX</code></p></li>
> -<li>
> -<code>NOFILE</code>
> -<p>
> -see <code>PATH_MAX</code></p></li>
> -<li>
> -Hurd specific <code>#define</code>
> -<p>
> -If you need to include specific code for the Hurd using
> -<code>#if...#endif</code>, then you can use the <code>__GNU__</code>
> -symbol to do so. But think (at least) thrice! before doing so. In
> -<em>most</em> situations, this is completely unnecessary and will
> -create more problems than it may solve. Better ask on the mailing list
> -how to do it right if you can't think of a better solution.</p></li>
> -<li>
> -<code>sys_errlist[]</code> vs. <code>strerror()</code>
> -<p>
> -If a program has only support for <code>sys_errlist[]</code> you will
> -have to do some work to make it compile on the Hurd, which has dropped
> -support for it and does only provide <code>strerror()</code>. Steinar
> -Hamre writes about <code>strerror()</code>:</p>
> -<blockquote class=3D"documentquote">
> -<p>
> -<code>strerror()</code> should be used because:
> -<ul>
> -<li>
> -It is the modern, POSIX way.</li>
> -<li>
> -It is localized.</li>
> -<li>
> -It handles invalid signals/numbers out of range. (better errorhandling
> -and not a buffer-overflow-candidate/security risk)</li></ul>
> -<p>
> -<code>strerror()</code> should always be used if it is available.
> -Unfortunately there are still some <em>old</em> non-POSIX systems that
> -do not have <code>strerror()</code>, only
> -<code>sys_errlist[]</code>.</p>
> -<p>
> -Today, only supporting <code>strerror()</code> is far better than only sup=
> porting
> -<code>sys_errlist[]</code>. The best (from a portability viewpoint), howev=
> er is
> -supporting both. For <code>configure.in</code>, you will need:</p>
> -<p>
> -<code>AC_CHECK_FUNCS(strerror)</code></p>
> -<p>
> -To <code>config.h.in</code>, you need to add:</p>
> -<p>
> -<code>#undef HAVE_STRERROR</code></p>
> -<p>
> -Then something like:
> -<pre>
> - \#ifndef HAVE_STRERROR
> - static char *
> - private_strerror (errnum)
> - int errnum;
> - {
> - extern char *sys_errlist[];
> - extern int sys_nerr;
> -
> - if (errnum > 0 && errnum <=3D sys_nerr)
> - return sys_errlist[errnum];
> - return "Unknown system error";
> - }
> - \#define strerror private_strerror
> - \#endif /* HAVE_STRERROR */
> -</pre>
> -<p>
> -You can for example look in the latest fileutils (the above is a
> -simplified version of what I found there.) Patches should of course be
> -sent to upstream maintainers, this is very useful even for systems
> -with a working <code>sys_errlist[]</code>.</blockquote>
> -<li>
> -Filenames ending in a slash `/'
> -<p>
> -Those are evil if they don't exist and you want to name a directory
> -this way. For example, <code>mkdir foobar/</code> will <em>not</em>
> -work under the Hurd. This is POSIX compatible. POSIX says that the
> -path of a directory may have slashes appended to it. But the directory
> -does not exist yet, so the path does not refer to a directory, and
> -hence trailing slashes are not guaranteed to work. Just drop the
> -slashes, and you're fine.
> +Some packages use an erroneous dependency on <code>libc6-dev</code>. This =
> is incorrect because <code>libc6</code> is specific to some architectures o=
> f GNU/Linux. The corresponding package for GNU is <code>libc0.3-dev</code> =
> but other OSes will have different ones. You can locate the problem in the =
> <code>debian/control</code> file of the source tree. Typical solutions incl=
> ude detecting the OS using <code>dpkg-architecture</code> and hardcoding th=
> e soname, or better, use a logical OR. eg: <code>libc6-dev | libc6.1-dev | =
> libc0.3-dev | libc0.1-dev | libc-dev</code>. The <code>libc-dev</code> is a=
> virtual package that works for any soname but you have to put it only as t=
> he last option.</p></li>
> </ul>
>
> --_----------=_1261891220164401
> MIME-Version: 1.0
> Content-Disposition: inline; filename="english/devel/buildd/wanna-build-states.wml.log"
> Content-Transfer-Encoding: quoted-printable
> Content-Type: text/plain; charset="utf-8"; name="english/devel/buildd/wanna-build-states.wml.log"
> X-Mailer: MIME::Lite 3.023 (F2.76; T1.24; A2.03; B3.07_01; Q3.07)
> Date: Sun, 27 Dec 2009 06:20:22 +0100
>
> ---------------------------------------------------------------------------=
> ---
> 1.20 | wouter | Wed Sep 2 09:35:20 2009
>
> Document BD-Uninstallable
>
> ---------------------------------------------------------------------------=
> ---
> 1.21 | wouter | Thu Nov 19 11:39:19 2009
>
> Grammar fix
>
> ---------------------------------------------------------------------------=
> ---
>
> --_----------=_1261891220164401
> MIME-Version: 1.0
> Content-Disposition: inline; filename="english/ports/hurd/hurd-devel-debian.wml.log"
> Content-Transfer-Encoding: quoted-printable
> Content-Type: text/plain; charset="utf-8"; name="english/ports/hurd/hurd-devel-debian.wml.log"
> X-Mailer: MIME::Lite 3.023 (F2.76; T1.24; A2.03; B3.07_01; Q3.07)
> Date: Sun, 27 Dec 2009 06:20:23 +0100
>
> ---------------------------------------------------------------------------=
> ---
> 1.32 | sthibault | Tue Nov 24 00:33:48 2009
>
> Reference upstream wiki page instead of duplicating the information.
>
> ---------------------------------------------------------------------------=
> ---
> 1.33 | sthibault | Wed Nov 25 20:03:22 2009
>
> Add the broken libc6 dependency common issue
>
> ---------------------------------------------------------------------------=
> ---
>
> --_----------=_1261891220164401--
>
More information about the Debian-l10n-devel
mailing list