Debian Bug report logs - #334164
yada: Touches debian/control, first paragraph, modifies Build-Depends on the fly

version graph

Package: yada; Maintainer for yada is Piotr Roszatycki <dexter@debian.org>;

Reported by: Joerg Jaspert <joerg@ganneff.de>

Date: Sat, 15 Oct 2005 22:03:05 UTC

Severity: serious

Tags: wontfix

Fixed in version 0.55+rm

Done: Debian FTP Masters <ftpmaster@ftp-master.debian.org>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Joerg Jaspert <joerg@ganneff.de>, Piotr Roszatycki <dexter@debian.org>:
Bug#334164; Package yada. Full text and rfc822 format available.

Acknowledgement sent to Joerg Jaspert <joerg@ganneff.de>:
New Bug report received and forwarded. Copy sent to Joerg Jaspert <joerg@ganneff.de>, Piotr Roszatycki <dexter@debian.org>. Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Joerg Jaspert <joerg@ganneff.de>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: yada: Touches debian/control, first paragraph, modifies Build-Depends on the fly
Date: Sat, 15 Oct 2005 23:55:33 +0200
[Message part 1 (text/plain, inline)]
Package: yada
Severity: serious

Hi

yada rebuilds the debian/control file when it is run, *AND* it goes and
*modifies* data in the first paragraph of it.

This is *really* broken and should never be done, except by the
maintainer itself. The reason is simple: If its done automagically and
noone checks it, it can produce results which may break later, for
example in security updates.


-- 
bye Joerg
<Getty> LOL die Telefonnummer vom Arbeitsamt Mönchengladbach ist echt 404-0?
<Getty> Soll das nen schlechter Scherz sein?
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Piotr Roszatycki <dexter@debian.org>:
Bug#334164; Package yada. Full text and rfc822 format available.

Acknowledgement sent to Piotr Roszatycki <Piotr_Roszatycki@netia.net.pl>:
Extra info received and forwarded to list. Copy sent to Piotr Roszatycki <dexter@debian.org>. Full text and rfc822 format available.

Message #10 received at 334164@bugs.debian.org (full text, mbox):

From: Piotr Roszatycki <Piotr_Roszatycki@netia.net.pl>
To: Joerg Jaspert <joerg@ganneff.de>, 334164@bugs.debian.org
Cc: control@bugs.debian.org
Subject: Re: Bug#334164: yada: Touches debian/control, first paragraph, modifies Build-Depends on the fly
Date: Sun, 16 Oct 2005 11:59:52 +0200
severity 334164 normal
thanks

> yada rebuilds the debian/control file when it is run, *AND* it goes and
> *modifies* data in the first paragraph of it.
>
> This is *really* broken and should never be done, except by the
> maintainer itself. The reason is simple: If its done automagically and
> noone checks it, it can produce results which may break later, for
> example in security updates.

If the security update is prapared with sane environment (in sarge system), 
there is no possibility to break the debian/control's Build-Dependencies.

Please, tell me, how yada can break the package? I'm using this tool for years 
and it happened *never*.

In fact, the Build-Depends are changed only for yada itself. If security 
update is prepared with wrong tool, the result will be also wrong. If updated 
is prepared with the proper environment, the result will be OK.

My example - the phpmyadmin 2.6.2-3:

autogenerated debian/control in original package:

Build-Depends-Indep: yada (>= 0.34), po-debconf

autoregenerated debian/control in sid environment:

Build-Depends-Indep: yada (>= 0.48), po-debconf

autogenerated debian/control in sarge environment (i.e. for security update)

Build-Depends-Indep: yada (>= 0.34), po-debconf

So, it is the same version as in original package. Everything is all right.

-- 
 .''`.    Piotr Roszatycki, Netia SA
: :' :    mailto:Piotr_Roszatycki@netia.net.pl
`. `'     mailto:dexter@debian.org
  `-



Severity set to `normal'. Request was from Piotr Roszatycki <Piotr_Roszatycki@netia.net.pl> to control@bugs.debian.org. Full text and rfc822 format available.

Tags added: wontfix Request was from "Piotr Roszatycki" <piotr.roszatycki@gmail.com> to control@bugs.debian.org. (Fri, 04 May 2007 15:21:01 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Piotr Roszatycki <dexter@debian.org>:
Bug#334164; Package yada. (Wed, 03 Aug 2011 13:27:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Tim Retout <diocles@debian.org>:
Extra info received and forwarded to list. Copy sent to Piotr Roszatycki <dexter@debian.org>. (Wed, 03 Aug 2011 13:27:04 GMT) Full text and rfc822 format available.

Message #19 received at 334164@bugs.debian.org (full text, mbox):

From: Tim Retout <diocles@debian.org>
To: debian-release@lists.debian.org
Cc: dexter@debian.org, 334164@bugs.debian.org
Subject: Re: Release goal proposal: remove yada
Date: Wed, 3 Aug 2011 14:24:16 +0100
On 2 August 2011 13:24, Ricardo Mones <mones@debian.org> wrote:
> From the dialog on the bug seems only Build-Depends are adjusted by the
> packages existing in the build environment, i.e., not arbitrary rewritting
> but a precise one. What has changed in this regard to make it serious?

Allow me to focus on this issue, because it sets yada apart from
debhelper, cdbs or packages without any helpers.  I will CC the bug in
question.

Firstly, the scope of the rewriting is greater than merely the
Build-Depends field.  The entire control file in the source package
(not just in the binary packages) is regenerated from debian/packages
during each build - indeed, so is debian/rules.  Any manual
modifications to debian/control or debian/rules are likely to be
overwritten when 'debclean' is run.

Secondly, consider the case where yada is updated during the course of
a release cycle, and a package using yada is not rebuilt before the
release:

 1. yada-0.55-1 is uploaded.
 2. foo-0.1-1 is uploaded - Build-Depends: yada (>= 0.55)
 3. yada-0.56-1 is uploaded.
 4. Release happens.
 5. Security bug is found in the 'foo' package.

Then the security update for 'foo' will be given a different
Build-Depends line from foo-0.1-1.  If any other details of how
control or rules files are generated have changed in yada 0.56, then
these will also be applied to the security update.

This makes it difficult to produce a minimal diff for a security
update (or even an NMU in unstable) for a package using yada, and
increases the risk of unintentional changes.  The same problems do not
occur with other methods of building packages, because the source
packages are not automatically modified.

Kind regards,

-- 
Tim Retout <diocles@debian.org>




Information forwarded to debian-bugs-dist@lists.debian.org, Piotr Roszatycki <dexter@debian.org>:
Bug#334164; Package yada. (Wed, 03 Aug 2011 17:12:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Tim Retout <diocles@debian.org>:
Extra info received and forwarded to list. Copy sent to Piotr Roszatycki <dexter@debian.org>. (Wed, 03 Aug 2011 17:12:03 GMT) Full text and rfc822 format available.

Message #24 received at 334164@bugs.debian.org (full text, mbox):

From: Tim Retout <diocles@debian.org>
To: debian-release@lists.debian.org
Cc: dexter@debian.org, 334164@bugs.debian.org
Subject: Re: Release goal proposal: remove yada
Date: Wed, 3 Aug 2011 18:10:22 +0100
On 3 August 2011 14:24, Tim Retout <diocles@debian.org> wrote:
> Firstly, the scope of the rewriting is greater than merely the
> Build-Depends field.

By the way, in case there is any doubt that this bug should be RC,
turning on automagic use of the equivalent feature in cdbs qualifies
for a reject from the ftp-masters:

http://ftp-master.debian.org/REJECT-FAQ.html
http://bugs.debian.org/311724

Even if removal of yada does not qualify for a release goal, the
release team could choose to upgrade the severity of bug #334164.

Kind regards,

-- 
Tim Retout <diocles@debian.org>




Information forwarded to debian-bugs-dist@lists.debian.org, Piotr Roszatycki <dexter@debian.org>:
Bug#334164; Package yada. (Thu, 04 Aug 2011 10:18:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ricardo Mones <mones@debian.org>:
Extra info received and forwarded to list. Copy sent to Piotr Roszatycki <dexter@debian.org>. (Thu, 04 Aug 2011 10:18:05 GMT) Full text and rfc822 format available.

Message #29 received at 334164@bugs.debian.org (full text, mbox):

From: Ricardo Mones <mones@debian.org>
To: dexter@debian.org
Cc: 334164@bugs.debian.org
Subject: Fw: Re: Release goal proposal: remove yada
Date: Thu, 4 Aug 2011 12:13:58 +0200
  Sorry, forgot to keep Cc on reply.

----- Forwarded message from Ricardo Mones <mones@debian.org> -----

Date: Thu, 4 Aug 2011 11:07:29 +0200
From: Ricardo Mones <mones@debian.org>
To: debian-release@lists.debian.org
Subject: Re: Release goal proposal: remove yada
User-Agent: Mutt/1.5.21 (2010-09-15)

On Wed, Aug 03, 2011 at 02:24:16PM +0100, Tim Retout wrote:
> On 2 August 2011 13:24, Ricardo Mones <mones@debian.org> wrote:
> > From the dialog on the bug seems only Build-Depends are adjusted by the
> > packages existing in the build environment, i.e., not arbitrary rewritting
> > but a precise one. What has changed in this regard to make it serious?
> 
> Allow me to focus on this issue, because it sets yada apart from
> debhelper, cdbs or packages without any helpers.  I will CC the bug in
> question.
> 
> Firstly, the scope of the rewriting is greater than merely the
> Build-Depends field.  The entire control file in the source package
> (not just in the binary packages) is regenerated from debian/packages
> during each build - indeed, so is debian/rules.  Any manual
> modifications to debian/control or debian/rules are likely to be
> overwritten when 'debclean' is run.

  Yep, it basically means that the debian/rules and debian/control are in
fact embedded in the debian/packages file and are written from it. So, the
rule that the build process must not modifiy the control file for yada should
be read as "must not modify the packages file" which is the origin from them.

  The fact that ftp-masters had neither banned yada packages nor sent
further respones to that bug make me suspect that's how rule is being
applied in case of yada, but I may be wrong, of course.

> Secondly, consider the case where yada is updated during the course of
> a release cycle, and a package using yada is not rebuilt before the
> release:
> 
>  1. yada-0.55-1 is uploaded.
>  2. foo-0.1-1 is uploaded - Build-Depends: yada (>= 0.55)
>  3. yada-0.56-1 is uploaded.
>  4. Release happens.
>  5. Security bug is found in the 'foo' package.
> 
> Then the security update for 'foo' will be given a different
> Build-Depends line from foo-0.1-1.  If any other details of how
> control or rules files are generated have changed in yada 0.56, then
> these will also be applied to the security update.

  I don't think this situation is even possible: you have to freeze things
before release, and that includes helpers. And if you have to do that because
a grave problem on the helper affecting packages build process you should
issue binNMUs on the packages using it to ensure the problem is solved with
the new helper version before releasing.

> This makes it difficult to produce a minimal diff for a security
> update (or even an NMU in unstable) for a package using yada, and
> increases the risk of unintentional changes.  The same problems do not
> occur with other methods of building packages, because the source
> packages are not automatically modified.

  Yes, I understand the problem, but if the release is done properly that
should not happen (TM), and we should trust our Release Team ;)

  regards,
-- 
  Ricardo Mones 
  ~
  You have the capacity to learn from mistakes. You'll learn a lot 
  today.                                           /usr/games/fortune




----- End forwarded message -----

-- 
  Ricardo Mones 
  ~
  Don't take the name of root in vain.          /usr/src/linux/README





Information forwarded to debian-bugs-dist@lists.debian.org, Piotr Roszatycki <dexter@debian.org>:
Bug#334164; Package yada. (Thu, 04 Aug 2011 11:51:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Tim Retout <diocles@debian.org>:
Extra info received and forwarded to list. Copy sent to Piotr Roszatycki <dexter@debian.org>. (Thu, 04 Aug 2011 11:51:11 GMT) Full text and rfc822 format available.

Message #34 received at 334164@bugs.debian.org (full text, mbox):

From: Tim Retout <diocles@debian.org>
To: 334164@bugs.debian.org
Subject: Re: Release goal proposal: remove yada
Date: Thu, 4 Aug 2011 12:48:56 +0100
[Forwarding to bug too.]

On 4 August 2011 10:07, Ricardo Mones <mones@debian.org> wrote:
>  I don't think this situation is even possible: you have to freeze things
> before release, and that includes helpers. And if you have to do that because
> a grave problem on the helper affecting packages build process you should
> issue binNMUs on the packages using it to ensure the problem is solved with
> the new helper version before releasing.

Right; but the helper being frozen does not mean that we binNMU every
package depending on it?

See for example:
yada version 0.55 is in stable.
aylet - Build-Depends: yada (>= 0.53) in stable.
cvsconnect - Build-Depends: yada (>= 0.48) in stable.
etc.

If you try rebuilding these in a stable chroot, you'll get a different
debian/rules and debian/control in the new source package.  If yada
were actively maintained, the changes could be a lot more drastic.

The best, of course, are found in experimental:
libhttp-davserver-perl: Build-Depends: yada (>= 0.21)
securecgi: Build-Depends: yada (>= 0.23) and FTBFS because automake1.8
no longer exists - I'll go and file a bug.

I strongly suspect the ftp-masters will not allow packages through NEW
that contain yada, but that it's not in the FAQ because not that many
people bother to try.

Kind regards,

--
Tim Retout <diocles@debian.org>




Information forwarded to debian-bugs-dist@lists.debian.org, Piotr Roszatycki <dexter@debian.org>:
Bug#334164; Package yada. (Thu, 04 Aug 2011 12:05:55 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ricardo Mones <ricardo@mones.org>:
Extra info received and forwarded to list. Copy sent to Piotr Roszatycki <dexter@debian.org>. (Thu, 04 Aug 2011 12:06:12 GMT) Full text and rfc822 format available.

Message #39 received at 334164@bugs.debian.org (full text, mbox):

From: Ricardo Mones <ricardo@mones.org>
To: debian-release@lists.debian.org
Cc: 334164@bugs.debian.org, dexter@debian.org
Subject: Re: Release goal proposal: remove yada
Date: Thu, 4 Aug 2011 13:52:08 +0200
[Message part 1 (text/plain, inline)]
On Thu, Aug 04, 2011 at 12:03:10PM +0100, Tim Retout wrote:
> On 4 August 2011 10:07, Ricardo Mones <mones@debian.org> wrote:
> >  I don't think this situation is even possible: you have to freeze things
> > before release, and that includes helpers. And if you have to do that because
> > a grave problem on the helper affecting packages build process you should
> > issue binNMUs on the packages using it to ensure the problem is solved with
> > the new helper version before releasing.
> 
> Right; but the helper being frozen does not mean that we binNMU every
> package depending on it?

  Err, I think I lost something here... I meant you binNMU if you have to
upload a new helper version to fix something affecting build process, i.e.,
something you have to really verify. I think this applies to every helper
in the situation you described, not only yada.

> See for example:
> yada version 0.55 is in stable.
> aylet - Build-Depends: yada (>= 0.53) in stable.
> cvsconnect - Build-Depends: yada (>= 0.48) in stable.
> etc.
> 
> If you try rebuilding these in a stable chroot, you'll get a different
> debian/rules and debian/control in the new source package.  If yada
> were actively maintained, the changes could be a lot more drastic.

  According the bug response, the only change to build depends should be
the yada version number (which would become 0.55), and rules should be the
same. If that's not true then I would agree the problem is more serious.

> The best, of course, are found in experimental:
> libhttp-davserver-perl: Build-Depends: yada (>= 0.21)
> securecgi: Build-Depends: yada (>= 0.23) and FTBFS because automake1.8
> no longer exists - I'll go and file a bug.

  Yeah, same as before, but what I see here is packages with a lazy or
inexistent maintainer, which should have uploaded some update so the yada
version numbers were current. As said not a yada problem itself. Imagine
some maintainer using debhelper which refuses to bump compat level, do we
remove debhelper or the package?

  Like is already done with other changes, make usign yada < $testing_ver - 1
(for example) a serious bug and things would improve (either packages are
fixed or removed). Futhermore, this can be automated :)

> I strongly suspect the ftp-masters will not allow packages through NEW
> that contain yada, but that it's not in the FAQ because not that many
> people bother to try.

  Umm, that could be too :) any ftp-master around to confirm?
-- 
  Ricardo Mones 
  ~
  Physics is like sex: sure, it may give some practical results, but 
  that's not why we do it.                            Richard Feynman

[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Piotr Roszatycki <dexter@debian.org>:
Bug#334164; Package yada. (Thu, 04 Aug 2011 12:09:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Tim Retout <diocles@debian.org>:
Extra info received and forwarded to list. Copy sent to Piotr Roszatycki <dexter@debian.org>. (Thu, 04 Aug 2011 12:09:48 GMT) Full text and rfc822 format available.

Message #44 received at 334164@bugs.debian.org (full text, mbox):

From: Tim Retout <diocles@debian.org>
To: debian-release@lists.debian.org
Cc: 334164@bugs.debian.org, dexter@debian.org
Subject: Re: Release goal proposal: remove yada
Date: Thu, 4 Aug 2011 13:07:05 +0100
On 4 August 2011 12:52, Ricardo Mones <ricardo@mones.org> wrote:
>  According the bug response, the only change to build depends should be
> the yada version number (which would become 0.55), and rules should be the
> same. If that's not true then I would agree the problem is more serious.

Yep, that is not true, and I would like the release team to override
the maintainer's opinion of the severity.  Here's what happens if
aylet is rebuilt after just 'dch -i', for example:

$ diffstat aylet-debdiff
 changelog |    6 ++++++
 control   |    2 +-
 rules     |    6 +++---
 3 files changed, 10 insertions(+), 4 deletions(-)

The fact that the rules change is so small is because we're only
talking a few minor versions.  In principle the rules and control
files could be entirely different.

Yes, perhaps we could make dependencies on old versions of yada RC,
but the real problem here is yada.  This is completely different to
debhelper compat versions.

Kind regards,

-- 
Tim Retout <diocles@debian.org>




Information forwarded to debian-bugs-dist@lists.debian.org, Piotr Roszatycki <dexter@debian.org>:
Bug#334164; Package yada. (Thu, 04 Aug 2011 12:18:13 GMT) Full text and rfc822 format available.

Acknowledgement sent to "Adam D. Barratt" <adam@adam-barratt.org.uk>:
Extra info received and forwarded to list. Copy sent to Piotr Roszatycki <dexter@debian.org>. (Thu, 04 Aug 2011 12:18:45 GMT) Full text and rfc822 format available.

Message #49 received at 334164@bugs.debian.org (full text, mbox):

From: "Adam D. Barratt" <adam@adam-barratt.org.uk>
To: Tim Retout <diocles@debian.org>
Cc: <debian-release@lists.debian.org>, <334164@bugs.debian.org>, <dexter@debian.org>
Subject: Re: Release goal proposal: remove yada
Date: Thu, 04 Aug 2011 13:14:29 +0100
On Thu, 4 Aug 2011 13:07:05 +0100, Tim Retout wrote:
> On 4 August 2011 12:52, Ricardo Mones <ricardo@mones.org> wrote:
>>  According the bug response, the only change to build depends should 
>> be
>> the yada version number (which would become 0.55), and rules should 
>> be the
>> same. If that's not true then I would agree the problem is more 
>> serious.
>
> Yep, that is not true, and I would like the release team to override
> the maintainer's opinion of the severity.  Here's what happens if
> aylet is rebuilt after just 'dch -i', for example:
>
> $ diffstat aylet-debdiff
>  changelog |    6 ++++++
>  control   |    2 +-
>  rules     |    6 +++---
>  3 files changed, 10 insertions(+), 4 deletions(-)
[...]
> Yes, perhaps we could make dependencies on old versions of yada RC,
> but the real problem here is yada.  This is completely different to
> debhelper compat versions.

To get a fuller picture, what are the changes being made to each of the 
files in question and when/where are they being made?  You mentioned 
earlier that cleaning the package would lead to changes being made - it 
sounds like the above build may well fail part of the "autobuilding" 
section of the RC policy; specifically:

	debian/rules must include the targets: clean, binary, binary-arch,
	binary-indep and build; and these targets cannot require any
	interaction with the user. The build target must not do anything that
	requires root privileges. These targets must not change the package's
	build-dependencies or the changelog.

Regards,

Adam




Information forwarded to debian-bugs-dist@lists.debian.org, Piotr Roszatycki <dexter@debian.org>:
Bug#334164; Package yada. (Fri, 05 Aug 2011 10:15:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Tim Retout <diocles@debian.org>:
Extra info received and forwarded to list. Copy sent to Piotr Roszatycki <dexter@debian.org>. (Fri, 05 Aug 2011 10:15:12 GMT) Full text and rfc822 format available.

Message #54 received at 334164@bugs.debian.org (full text, mbox):

From: Tim Retout <diocles@debian.org>
To: debian-release@lists.debian.org
Cc: 334164@bugs.debian.org, dexter@debian.org
Subject: Re: Release goal proposal: remove yada
Date: Fri, 5 Aug 2011 11:12:26 +0100
severity 334164 serious
thanks

On 4 August 2011 13:14, Adam D. Barratt <adam@adam-barratt.org.uk> wrote:
> To get a fuller picture, what are the changes being made to each of the
> files in question and when/where are they being made?  You mentioned earlier
> that cleaning the package would lead to changes being made - it sounds like
> the above build may well fail part of the "autobuilding" section of the RC
> policy; specifically:
>
>        debian/rules must include the targets: clean, binary, binary-arch,
>        binary-indep and build; and these targets cannot require any
>        interaction with the user. The build target must not do anything that
>        requires root privileges. These targets must not change the package's
>        build-dependencies or the changelog.

Thanks for pointing this out.  Indeed, the build-dependencies are
potentially modified in all of those targets (including just "clean"),
and this has been against the RC policy since etch (most likely
introduced at a later time than the previous discussion on this bug).

So I'm upgrading the severity to serious on those grounds, if there
are no objections.

-- 
Tim Retout <diocles@debian.org>




Severity set to 'serious' from 'normal' Request was from Tim Retout <diocles@debian.org> to control@bugs.debian.org. (Fri, 05 Aug 2011 10:15:29 GMT) Full text and rfc822 format available.

Added blocking bug(s) of 334164: 660548 Request was from Cyril Brulebois <kibi@debian.org> to control@bugs.debian.org. (Sun, 19 Feb 2012 20:00:25 GMT) Full text and rfc822 format available.

Reply sent to Debian FTP Masters <ftpmaster@ftp-master.debian.org>:
You have taken responsibility. (Tue, 21 Feb 2012 09:54:23 GMT) Full text and rfc822 format available.

Notification sent to Joerg Jaspert <joerg@ganneff.de>:
Bug acknowledged by developer. (Tue, 21 Feb 2012 09:54:27 GMT) Full text and rfc822 format available.

Message #63 received at 334164-done@bugs.debian.org (full text, mbox):

From: Debian FTP Masters <ftpmaster@ftp-master.debian.org>
To: 52711-done@bugs.debian.org,96860-done@bugs.debian.org,334164-done@bugs.debian.org,402550-done@bugs.debian.org,563392-done@bugs.debian.org,636735-done@bugs.debian.org,
Cc: yada@packages.debian.org, yada@packages.qa.debian.org
Subject: Bug#660548: Removed package(s) from unstable
Date: Tue, 21 Feb 2012 09:51:56 +0000
Version: 0.55+rm

Dear submitter,

as the package yada has just been removed from the Debian archive
unstable we hereby close the associated bug reports.  We are sorry
that we couldn't deal with your issue properly.

For details on the removal, please see http://bugs.debian.org/660548

The version of this package that was in Debian prior to this removal
can still be found using http://snapshot.debian.org/.

This message was generated automatically; if you believe that there is
a problem with it please contact the archive administrators by mailing
ftpmaster@debian.org.

Debian distribution maintenance software
pp.
Ansgar Burchardt (the ftpmaster behind the curtain)




Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Wed, 21 Mar 2012 07:37:24 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Sun Apr 20 21:52:03 2014; Machine Name: buxtehude.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.