Debian Bug report logs -
#461100
manpages-dev: Please remove a paragraph from alloca(3) man page
Reported by: Vincent Lefevre <vincent@vinc17.org>
Date: Wed, 16 Jan 2008 15:33:04 UTC
Severity: normal
Tags: fixed-upstream
Found in version manpages/2.67-1
Fixed in version manpages/2.77-1
Done: Martin Schulze <joey@infodrom.org>
Bug is archived. No further changes may be made.
Toggle useless messages
Report forwarded to debian-bugs-dist@lists.debian.org, Martin Schulze <joey@debian.org>:
Bug#461100; Package manpages-dev.
(full text, mbox, link).
Acknowledgement sent to Vincent Lefevre <vincent@vinc17.org>:
New Bug report received and forwarded. Copy sent to Martin Schulze <joey@debian.org>.
(full text, mbox, link).
Message #5 received at submit@bugs.debian.org (full text, mbox, reply):
Package: manpages-dev
Version: 2.67-1
Severity: normal
The alloca(3) man page says:
BUGS
The alloca() function is machine and compiler dependent.
On many systems its implementation is buggy. Its use is
discouraged.
The first sentence doesn't give more information than sections
"CONFORMING TO" and "NOTES", and concerning the second sentence,
Torbjorn Granlund says in the MPFR mailing-list[*]:
That text is FUDish; I have never encountered any bugs with alloca on
any of the many GMP target systems.
So, this misleading paragraph should be removed.
[*] http://websympa.loria.fr/wwsympa/arc/mpfr/2008-01/msg00062.html
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 2.6.23-1-686-bigmem (SMP w/2 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.ISO8859-1 (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash
Versions of packages manpages-dev depends on:
ii manpages 2.67-1 Manual pages about using a GNU/Lin
manpages-dev recommends no packages.
-- no debconf information
Information forwarded to debian-bugs-dist@lists.debian.org, Martin Schulze <joey@debian.org>:
Bug#461100; Package manpages-dev.
(full text, mbox, link).
Acknowledgement sent to Michael Kerrisk <mtk.manpages@googlemail.com>:
Extra info received and forwarded to list. Copy sent to Martin Schulze <joey@debian.org>.
(full text, mbox, link).
Message #10 received at 461100@bugs.debian.org (full text, mbox, reply):
tags 461100 fixed-upstream
thanks
(changes in upstream 2.77)
Vincent Lefevre wrote:
> Package: manpages-dev
> Version: 2.67-1
> Severity: normal
>
> The alloca(3) man page says:
>
> BUGS
> The alloca() function is machine and compiler dependent.
> On many systems its implementation is buggy. Its use is
> discouraged.
>
> The first sentence doesn't give more information than sections
> "CONFORMING TO" and "NOTES", and concerning the second sentence,
> Torbjorn Granlund says in the MPFR mailing-list[*]:
>
> That text is FUDish; I have never encountered any bugs with alloca on
> any of the many GMP target systems.
>
> So, this misleading paragraph should be removed.
While I don't think we can take one developer's experience as gospel
(though it would be useful to know the range of platforms that Torbjorn has
tested), I do agree that the warning in the existing text is a bit strong.
I removed the sentence containing "buggy", and relocated the rest under NOTES:
NOTES
The alloca() function is machine- and compiler-dependent.
Its use is discouraged.
Perhaps the two of you might still feel that this is a bit strong, but
before I make further changes, I'd be interested in specific details of
platforms that have been found to be problem free.
I also reworked various other parts of the page, so that it now reads as
shown below. The changes will be in upstream 2.77. Thanks for your report!
Cheers,
Michael
NAME
alloca - allocate memory that is automatically freed
SYNOPSIS
#include <alloca.h>
void *alloca(size_t size);
DESCRIPTION
The alloca() function allocates size bytes of space in
the stack frame of the caller. This temporary space is
automatically freed when the function that called
alloca() returns to its caller.
RETURN VALUE
The alloca() function returns a pointer to the beginning
of the allocated space. If the allocation causes stack
overflow, program behavior is undefined.
CONFORMING TO
This function is not in POSIX.1-2001.
There is evidence that the alloca() function appeared in
32V, PWB, PWB.2, 3BSD, and 4BSD. There is a man page for
it in 4.3BSD. Linux uses the GNU version.
NOTES
The alloca() function is machine- and compiler-dependent.
Its use is discouraged.
Because the space allocated by alloca() is allocated
within the stack frame, that space is automatically freed
if the function return is jumped over by a call to
longjmp(3) or siglongjmp(3).
Do not attempt to free(3) space allocated by alloca()!
Notes on the GNU Version
Normally, gcc(1) translates calls to alloca() with
inlined code. This is not done when either the -ansi,
-std=c89, -std=c99, or the -fno-builtin option is given
(and the header <alloca.h> is not included). But beware!
By default the glibc version of <stdlib.h> includes
<alloca.h> and that contains the line:
#define alloca(size) __builtin_alloca (size)
with messy consequences if one has a private version of
this function.
The fact that the code is inlined means that it is impos-
sible to take the address of this function, or to change
its behavior by linking with a different library.
The inlined code often consists of a single instruction
adjusting the stack pointer, and does not check for stack
overflow. Thus, there is no NULL error return.
BUGS
There is no error indication if the stack frame cannot be
extended. (However, after a failed allocation, the pro-
gram is likely to receive a SIGSEGV signal if it attempts
to access the unallocated space.)
On many systems alloca() cannot be used inside the list
of arguments of a function call, because the stack space
reserved by alloca() would appear on the stack in the
middle of the space for the function arguments.
SEE ALSO
brk(2), longjmp(3), malloc(3)
Tags added: fixed-upstream
Request was from Michael Kerrisk <mtk.manpages@googlemail.com>
to control@bugs.debian.org.
(Thu, 24 Jan 2008 15:39:08 GMT) (full text, mbox, link).
Information forwarded to debian-bugs-dist@lists.debian.org, Martin Schulze <joey@debian.org>:
Bug#461100; Package manpages-dev.
(full text, mbox, link).
Acknowledgement sent to Vincent Lefevre <vincent@vinc17.org>:
Extra info received and forwarded to list. Copy sent to Martin Schulze <joey@debian.org>.
(full text, mbox, link).
Message #17 received at 461100@bugs.debian.org (full text, mbox, reply):
On 2008-01-24 16:36:29 +0100, Michael Kerrisk wrote:
> While I don't think we can take one developer's experience as gospel
> (though it would be useful to know the range of platforms that
> Torbjorn has tested), [...]
That's quite a lot, but I don't know exactly. FYI, here are the
machines known to support MPFR (MPFR uses GMP, but MPFR also uses
alloca directly):
* alphaev56-dec-osf4.0f (Alpha, gcc 4.1.1),
* alphaev56-unknown-linux-gnu (Alpha, gcc 4.1.1),
* alphaev6-unknown-linux-gnu (Alpha, gcc 3.3.5),
* alphaev67-unknown-freebsd5.4 (Alpha, gcc 3.4.2),
* alphaev68-dec-osf5.1 (Alpha, gcc 3.2.1),
* alphaev68-dec-osf5.1b (Alpha, gcc 4.1.1),
* armv5tel-unknown-linux-gnu (XScale-PXA255, gcc 2.95.2),
* hppa2.0w-hp-hpux11.31 (PA-RISC 8900, HP cc B.11.11.16),
* i386-pc-solaris2.9 (gcc 4.1.1),
* i386-suse-linux-gnu,
* i386-unknown-freebsd5.4 (Intel Pentium III, gcc 3.4.2),
* i386-unknown-freebsd6.2 (Intel Pentium III, gcc 3.4.6),
* i386-unknown-netbsdelf2.0 (Intel Pentium III, gcc 3.3.3),
* i686-pc-linux-gnu (Dual Core AMD Opteron, gcc 3.3.5),
* i686-pc-linux-gnu (Intel Pentium D, gcc 4.1.3 prerelease),
* ia64-suse-linux-gnu,
* ia64-unknown-linux-gnu (Itanium, gcc 3.2.3 prerelease),
* ia64-unknown-linux-gnu (Itanium, gcc 4.1.2 prerelease),
* mips-sgi-irix6.5 (MIPSpro 7.3.1.3m),
* powerpc-apple-darwin8.10.0 (PowerPC G5, gcc 4.0.1),
* powerpc-unknown-linux-gnu (PowerPC G4, gcc 4.1.3 prerelease),
* powerpc64-ibm-aix5.2.0.0,
* powerpc64-unknown-linux-gnu (POWER5, gcc 4.1.2 prerelease),
* ppc-suse-linux-gnu,
* ppc64-suse-linux-gnu,
* s390-suse-linux-gnu,
* s390x-suse-linux-gnu,
* sparc-sun-solaris2.7 (UltraSPARC-II, Sun WorkShop 6 2000/04/07 C 5.1),
* sparc-sun-solaris2.8 (gcc 4.1.1),
* sparc-sun-solaris2.10 (Sun C 5.8 Patch 121015-03 2006/10/18),
* x86_64-solaris2.10 (gcc 4.1.1),
* x86_64-suse-linux-gnu,
* x86_64-unknown-linux-gnu (AMD Opteron, gcc 3.3.5),
* x86_64-unknown-linux-gnu (AMD Opteron, gcc 4.1.2 prerelease),
* Cygwin (Intel Celeron, gcc 3.4.2),
* MINGW32_NT-5.1 (Intel Pentium M, gcc 3.4.2).
On the other hand, I would like to know what bugs have been found in
alloca and on which platform. It's a bit strange that there aren't
any references about them.
--
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
Information forwarded to debian-bugs-dist@lists.debian.org, Martin Schulze <joey@debian.org>:
Bug#461100; Package manpages-dev.
(full text, mbox, link).
Acknowledgement sent to "Michael Kerrisk" <mtk.manpages@googlemail.com>:
Extra info received and forwarded to list. Copy sent to Martin Schulze <joey@debian.org>.
(full text, mbox, link).
Message #22 received at 461100@bugs.debian.org (full text, mbox, reply):
On Jan 24, 2008 4:57 PM, Vincent Lefevre <vincent@vinc17.org> wrote:
> On 2008-01-24 16:36:29 +0100, Michael Kerrisk wrote:
> > While I don't think we can take one developer's experience as gospel
> > (though it would be useful to know the range of platforms that
> > Torbjorn has tested), [...]
>
> That's quite a lot, but I don't know exactly. FYI, here are the
> machines known to support MPFR (MPFR uses GMP, but MPFR also uses
> alloca directly):
>
> * alphaev56-dec-osf4.0f (Alpha, gcc 4.1.1),
> * alphaev56-unknown-linux-gnu (Alpha, gcc 4.1.1),
> * alphaev6-unknown-linux-gnu (Alpha, gcc 3.3.5),
> * alphaev67-unknown-freebsd5.4 (Alpha, gcc 3.4.2),
> * alphaev68-dec-osf5.1 (Alpha, gcc 3.2.1),
> * alphaev68-dec-osf5.1b (Alpha, gcc 4.1.1),
> * armv5tel-unknown-linux-gnu (XScale-PXA255, gcc 2.95.2),
> * hppa2.0w-hp-hpux11.31 (PA-RISC 8900, HP cc B.11.11.16),
> * i386-pc-solaris2.9 (gcc 4.1.1),
> * i386-suse-linux-gnu,
> * i386-unknown-freebsd5.4 (Intel Pentium III, gcc 3.4.2),
> * i386-unknown-freebsd6.2 (Intel Pentium III, gcc 3.4.6),
> * i386-unknown-netbsdelf2.0 (Intel Pentium III, gcc 3.3.3),
> * i686-pc-linux-gnu (Dual Core AMD Opteron, gcc 3.3.5),
> * i686-pc-linux-gnu (Intel Pentium D, gcc 4.1.3 prerelease),
> * ia64-suse-linux-gnu,
> * ia64-unknown-linux-gnu (Itanium, gcc 3.2.3 prerelease),
> * ia64-unknown-linux-gnu (Itanium, gcc 4.1.2 prerelease),
> * mips-sgi-irix6.5 (MIPSpro 7.3.1.3m),
> * powerpc-apple-darwin8.10.0 (PowerPC G5, gcc 4.0.1),
> * powerpc-unknown-linux-gnu (PowerPC G4, gcc 4.1.3 prerelease),
> * powerpc64-ibm-aix5.2.0.0,
> * powerpc64-unknown-linux-gnu (POWER5, gcc 4.1.2 prerelease),
> * ppc-suse-linux-gnu,
> * ppc64-suse-linux-gnu,
> * s390-suse-linux-gnu,
> * s390x-suse-linux-gnu,
> * sparc-sun-solaris2.7 (UltraSPARC-II, Sun WorkShop 6 2000/04/07 C 5.1),
> * sparc-sun-solaris2.8 (gcc 4.1.1),
> * sparc-sun-solaris2.10 (Sun C 5.8 Patch 121015-03 2006/10/18),
> * x86_64-solaris2.10 (gcc 4.1.1),
> * x86_64-suse-linux-gnu,
> * x86_64-unknown-linux-gnu (AMD Opteron, gcc 3.3.5),
> * x86_64-unknown-linux-gnu (AMD Opteron, gcc 4.1.2 prerelease),
> * Cygwin (Intel Celeron, gcc 3.4.2),
> * MINGW32_NT-5.1 (Intel Pentium M, gcc 3.4.2).
Is alloca() used and tested on each of those platforms?
> On the other hand, I would like to know what bugs have been found in
> alloca and on which platform. It's a bit strange that there aren't
> any references about them.
Unfortunately, I have no info about that. The sentence about bugs was
added in the days before man-pages had change logs (i.e., before I
became maintainer).
Cheers,
Michael
--
Michael Kerrisk
Maintainer of the Linux man-pages project
http://www.kernel.org/doc/man-pages/
Want to report a man-pages bug? Look here:
http://www.kernel.org/doc/man-pages/reporting_bugs.html
Information forwarded to debian-bugs-dist@lists.debian.org, Martin Schulze <joey@debian.org>:
Bug#461100; Package manpages-dev.
(full text, mbox, link).
Acknowledgement sent to Torbjorn Granlund <tg@swox.com>:
Extra info received and forwarded to list. Copy sent to Martin Schulze <joey@debian.org>.
(full text, mbox, link).
Message #27 received at 461100@bugs.debian.org (full text, mbox, reply):
Please never CC my private email address on mail to debian. They
publish the addresses and refuse to clean up the archives afterwards.
(They have some policy in effect about helping email harvesters.)
--
Torbjörn
Information forwarded to debian-bugs-dist@lists.debian.org, Martin Schulze <joey@debian.org>:
Bug#461100; Package manpages-dev.
(full text, mbox, link).
Acknowledgement sent to Vincent Lefevre <vincent@vinc17.org>:
Extra info received and forwarded to list. Copy sent to Martin Schulze <joey@debian.org>.
(full text, mbox, link).
Message #32 received at 461100@bugs.debian.org (full text, mbox, reply):
On 2008-01-24 17:02:31 +0100, Michael Kerrisk wrote:
> Is alloca() used and tested on each of those platforms?
That's very probable. The only way to avoid alloca() is to build GMP
with --disable-alloca and to build MPFR using the GMP build directory
(i.e. with --with-gmp-build). MPFR uses alloca() for its low level
functions.
--
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
Information forwarded to debian-bugs-dist@lists.debian.org, Martin Schulze <joey@debian.org>:
Bug#461100; Package manpages-dev.
(full text, mbox, link).
Acknowledgement sent to Michael Kerrisk <mtk.manpages@googlemail.com>:
Extra info received and forwarded to list. Copy sent to Martin Schulze <joey@debian.org>.
(full text, mbox, link).
Message #37 received at 461100@bugs.debian.org (full text, mbox, reply):
Vincent Lefevre wrote:
> On 2008-01-24 17:02:31 +0100, Michael Kerrisk wrote:
>> Is alloca() used and tested on each of those platforms?
>
> That's very probable. The only way to avoid alloca() is to build GMP
> with --disable-alloca and to build MPFR using the GMP build directory
> (i.e. with --with-gmp-build). MPFR uses alloca() for its low level
> functions.
Hi Vincent,
So, I'm not quite clear. Are you happy with the new man page description
of alloca()?
Cheers,
Michael
--
Michael Kerrisk
Maintainer of the Linux man-pages project
http://www.kernel.org/doc/man-pages/
Want to report a man-pages bug? Look here:
http://www.kernel.org/doc/man-pages/reporting_bugs.html
Information forwarded to debian-bugs-dist@lists.debian.org, Martin Schulze <joey@debian.org>:
Bug#461100; Package manpages-dev.
(full text, mbox, link).
Acknowledgement sent to Vincent Lefevre <vincent@vinc17.org>:
Extra info received and forwarded to list. Copy sent to Martin Schulze <joey@debian.org>.
(full text, mbox, link).
Message #42 received at 461100@bugs.debian.org (full text, mbox, reply):
On 2008-01-25 12:03:15 +0100, Michael Kerrisk wrote:
> So, I'm not quite clear. Are you happy with the new man page
> description of alloca()?
I don't like very much the "Its use is discouraged." without any
information since in practice
1. it seems to be very well supported,
2. it can improve the efficiency (for instance, it was completely
removed from the MPFR trunk for a few days to fix a bug, as it
was also used for very large memory allocations, but I had to
re-add it for small allocations since the loss in small precisions
was important in raw timings, and could still be significant in
some practical applications).
Perhaps something like:
This function can improve efficiency in some applications compared
to malloc()/free(). Otherwise its use is discouraged.
--
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
Information forwarded to debian-bugs-dist@lists.debian.org, Martin Schulze <joey@debian.org>:
Bug#461100; Package manpages-dev.
(full text, mbox, link).
Acknowledgement sent to Michael Kerrisk <mtk.manpages@googlemail.com>:
Extra info received and forwarded to list. Copy sent to Martin Schulze <joey@debian.org>.
(full text, mbox, link).
Message #47 received at 461100@bugs.debian.org (full text, mbox, reply):
Hello Vincent,
Vincent Lefevre wrote:
> On 2008-01-25 12:03:15 +0100, Michael Kerrisk wrote:
>> So, I'm not quite clear. Are you happy with the new man page
>> description of alloca()?
>
> I don't like very much the "Its use is discouraged." without any
> information since in practice
> 1. it seems to be very well supported,
> 2. it can improve the efficiency (for instance, it was completely
> removed from the MPFR trunk for a few days to fix a bug, as it
> was also used for very large memory allocations, but I had to
> re-add it for small allocations since the loss in small precisions
> was important in raw timings, and could still be significant in
> some practical applications).
>
> Perhaps something like:
> b
> This function can improve efficiency in some applications compared
> to malloc()/free(). Otherwise its use is discouraged.
>
Fair enough. I reworked the text some more:
NOTES
The alloca() function is machine- and compiler-dependent.
For certain applications, its use can improve efficiency
compared to the use of malloc(3) plus free(3). In cer-
tain cases, it can also simplify memory deallocation in
applications that use longjmp(3) or siglongjmp(3). Oth-
erwise, its use is discouraged.
Because the space allocated by alloca() is allocated
within the stack frame, that space is automatically freed
if the function return is jumped over by a call to
longjmp(3) or siglongjmp(3).
Good enough now?
Cheers,
Michael
--
Michael Kerrisk
Maintainer of the Linux man-pages project
http://www.kernel.org/doc/man-pages/
Want to report a man-pages bug? Look here:
http://www.kernel.org/doc/man-pages/reporting_bugs.html
Information forwarded to debian-bugs-dist@lists.debian.org, Martin Schulze <joey@debian.org>:
Bug#461100; Package manpages-dev.
(full text, mbox, link).
Acknowledgement sent to Vincent Lefevre <vincent@vinc17.org>:
Extra info received and forwarded to list. Copy sent to Martin Schulze <joey@debian.org>.
(full text, mbox, link).
Message #52 received at 461100@bugs.debian.org (full text, mbox, reply):
Hi Michael,
On 2008-01-30 11:07:32 +0100, Michael Kerrisk wrote:
> Good enough now?
Yes, thanks.
--
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
Reply sent to Martin Schulze <joey@infodrom.org>:
You have taken responsibility.
(full text, mbox, link).
Notification sent to Vincent Lefevre <vincent@vinc17.org>:
Bug acknowledged by developer.
(full text, mbox, link).
Message #57 received at 461100-close@bugs.debian.org (full text, mbox, reply):
Source: manpages
Source-Version: 2.77-1
We believe that the bug you reported is fixed in the latest version of
manpages, which is due to be installed in the Debian FTP archive:
manpages-dev_2.77-1_all.deb
to pool/main/m/manpages/manpages-dev_2.77-1_all.deb
manpages_2.77-1.diff.gz
to pool/main/m/manpages/manpages_2.77-1.diff.gz
manpages_2.77-1.dsc
to pool/main/m/manpages/manpages_2.77-1.dsc
manpages_2.77-1_all.deb
to pool/main/m/manpages/manpages_2.77-1_all.deb
manpages_2.77.orig.tar.gz
to pool/main/m/manpages/manpages_2.77.orig.tar.gz
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 461100@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Martin Schulze <joey@infodrom.org> (supplier of updated manpages package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Format: 1.7
Date: Sat, 02 Feb 2008 21:31:56 +0100
Source: manpages
Binary: manpages manpages-dev
Architecture: source all
Version: 2.77-1
Distribution: unstable
Urgency: low
Maintainer: Martin Schulze <joey@debian.org>
Changed-By: Martin Schulze <joey@infodrom.org>
Description:
manpages - Manual pages about using a GNU/Linux system
manpages-dev - Manual pages about using GNU/Linux for development
Closes: 461100
Changes:
manpages (2.77-1) unstable; urgency=low
.
* New upstream version
. Weaken warning against use of alloca(3) (closes: Bug#461100)
Files:
9105c8df9baa6ca422bb19bad1808484 584 doc important manpages_2.77-1.dsc
4ba3fa20fe9dc5da9e1275afcf48b799 1278973 doc important manpages_2.77.orig.tar.gz
edd304dbf2dde4b41086ace8114a40f5 46997 doc important manpages_2.77-1.diff.gz
82d69e8251c296eb2044a36228b194b2 550302 doc important manpages_2.77-1_all.deb
6bb89c59f3b2c843d25254ceb90e0e31 1363158 doc optional manpages-dev_2.77-1_all.deb
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFHpNRRW5ql+IAeqTIRAlMsAJwNdVv6hYMhKOPzuUhLc3d2MLAu/ACePHfU
x/Stk/5jbXIQEKaWCcK45n0=
=dqUR
-----END PGP SIGNATURE-----
Bug archived.
Request was from Debbugs Internal Request <owner@bugs.debian.org>
to internal_control@bugs.debian.org.
(Thu, 13 Mar 2008 07:25:40 GMT) (full text, mbox, link).
Send a report that this bug log contains spam.
Debian bug tracking system administrator <owner@bugs.debian.org>.
Last modified:
Thu Mar 9 09:58:06 2023;
Machine Name:
buxtehude
Debian Bug tracking system
Debbugs is free software and licensed under the terms of the GNU
Public License version 2. The current version can be obtained
from https://bugs.debian.org/debbugs-source/.
Copyright © 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson,
2005-2017 Don Armstrong, and many other contributors.