Debian Bug report logs - #202243
utimes() broken

Toggle useless messages

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

From: Roderich Schupp <Roderich.Schupp@partner.bmw.de>

To: submit@bugs.debian.org

Subject: utimes() broken

Date: 21 Jul 2003 08:51:01 +0200

Package: libc6
Version: 2.3.2-1
Severity: important
Tags: patch

When using utimes() to set the timestamps on a file, they
always come out as the epoch (actually 1 second past the epoch :).
Reason is a thinko regarding operator precedence in C, patch below.

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux click 2.4.22-pre5 #2 Mon Jul 14 22:39:42 CEST 2003 i686
Locale: LANG=C, LC_CTYPE=C

Versions of packages libc6 depends on:
ii  libdb1-compat                 2.1.3-7   

-- no debconf information



--- ./debian/patches/10_cvs.dpatch~     2003-07-20 22:10:51.000000000
+0200
+++ ./debian/patches/10_cvs.dpatch      2003-07-20 22:12:13.000000000
+0200
@@ -107975,8 +107975,8 @@
 +  if (tvp != NULL)
 +    {
 +      times = &buf;
-+      buf.actime = tvp[0].tv_sec + tvp[0].tv_usec >= 500000;
-+      buf.modtime = tvp[1].tv_sec + tvp[1].tv_usec >= 500000;
++      buf.actime = tvp[0].tv_sec + (tvp[0].tv_usec >= 500000);
++      buf.modtime = tvp[1].tv_sec + (tvp[1].tv_usec >= 500000);
 +    }
 +  else
 +    times = NULL;
@@ -118962,8 +118962,8 @@
 +  if (tvp != NULL)
 +    {
 +      times = &buf;
-+      buf.actime = tvp[0].tv_sec + tvp[0].tv_usec >= 500000;
-+      buf.modtime = tvp[1].tv_sec + tvp[1].tv_usec >= 500000;
++      buf.actime = tvp[0].tv_sec + (tvp[0].tv_usec >= 500000);
++      buf.modtime = tvp[1].tv_sec + (tvp[1].tv_usec >= 500000);
 +    }
 +  else
 +    times = NULL;

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

From: Paul Eggert <eggert@CS.UCLA.EDU>

To: Jim Meyering <jim@meyering.net>

Cc: bug-gnulib@gnu.org, bug-coreutils@gnu.org, libc-alpha@sources.redhat.com, 202243@bugs.debian.org

Subject: glibc utimes glitch with coreutils 'touch'

Date: 09 Aug 2003 23:48:00 -0700

In <http://mail.gnu.org/archive/html/bug-gnulib/2003-08/msg00038.html>
Jim Meyering <jim@meyering.net> writes:

> Here are the symptoms of the utimes failure I mentioned recently.

You're suffering from Debian bug 202243 ("utimes() broken"); see
<http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=202243>.  The patch
proposed there won't entirely fix the bug, though, since it causes
'utimes' to round instead of truncate.  Historically, utimes truncated
when it couldn't store the microseconds, and the coreutils 'touch' code in
<http://mail.gnu.org/archive/html/bug-coreutils/2003-08/msg00016.html>
relies on this truncation.

I tried to find out why glibc changed from truncation to rounding.
Ulrich Drepper checked in a new Linux version of utimes on 2003-07-12,
to support newer Linux kernels that have utimes support.  On older
kernels this new code attempted to round, even though the usual
practice with timestamps is to truncate when going to a lower
resolution.  I don't know why rounding was introduced here.

(Personally I wish Linux would let me set the file's timestamp to the
nearest nanosecond, as that would avoid all this mess entirely.)

I'll submit an alternate patch to coreutils so that it works around
this glibc glitch.  The simplest workaround is to not invoke utimes
when building with glibc; perhaps I can improve on that, but I don't
know.

I propose the following patch to fix glibc:

2003-08-09  Paul Eggert  <eggert@twinsun.com>

	Revert to utimes's previous (i.e., pre-2003-07-12) behavior of
	truncating fractional parts of timestamps that it can't use,
        instead of attempting to round.
	* sysdeps/unix/sysv/linux/utimes.c (__utimes):
	Fix actime and modtime computation to truncate microseconds
	rather than attempting to round.
	* sysdeps/unix/sysv/linux/futimes.c (__futimes): Likewise.
	* sysdeps/posix/utimes.c (__utimes): Likewise.

Index: sysdeps/unix/sysv/linux/utimes.c
===================================================================
RCS file: /cvs/glibc/libc/sysdeps/unix/sysv/linux/utimes.c,v
retrieving revision 1.3
diff -p -u -r1.3 utimes.c
--- sysdeps/unix/sysv/linux/utimes.c	31 Jul 2003 19:04:13 -0000	1.3
+++ sysdeps/unix/sysv/linux/utimes.c	10 Aug 2003 06:15:53 -0000
@@ -47,8 +47,8 @@ __utimes (const char *file, const struct
   if (tvp != NULL)
     {
       times = &buf;
-      buf.actime = tvp[0].tv_sec + (tvp[0].tv_usec + 500000) / 1000000;
-      buf.modtime = tvp[1].tv_sec + (tvp[1].tv_usec + 500000) / 1000000;
+      buf.actime = tvp[0].tv_sec + tvp[0].tv_usec / 1000000;
+      buf.modtime = tvp[1].tv_sec + tvp[1].tv_usec / 1000000;
     }
   else
     times = NULL;
Index: sysdeps/unix/sysv/linux/futimes.c
===================================================================
RCS file: /cvs/glibc/libc/sysdeps/unix/sysv/linux/futimes.c,v
retrieving revision 1.6
diff -p -u -r1.6 futimes.c
--- sysdeps/unix/sysv/linux/futimes.c	31 Jul 2003 19:04:13 -0000	1.6
+++ sysdeps/unix/sysv/linux/futimes.c	10 Aug 2003 06:15:53 -0000
@@ -58,8 +58,8 @@ __futimes (int fd, const struct timeval 
   if (tvp != NULL)
     {
       times = &buf;
-      buf.actime = tvp[0].tv_sec + (tvp[0].tv_usec + 500000) / 1000000;
-      buf.modtime = tvp[1].tv_sec + (tvp[1].tv_usec + 500000) / 1000000;
+      buf.actime = tvp[0].tv_sec + tvp[0].tv_usec / 1000000;
+      buf.modtime = tvp[1].tv_sec + tvp[1].tv_usec / 1000000;
     }
   else
     times = NULL;
Index: sysdeps/posix/utimes.c
===================================================================
RCS file: /cvs/glibc/libc/sysdeps/posix/utimes.c,v
retrieving revision 1.7
diff -p -u -r1.7 utimes.c
--- sysdeps/posix/utimes.c	31 Jul 2003 19:04:13 -0000	1.7
+++ sysdeps/posix/utimes.c	10 Aug 2003 06:15:53 -0000
@@ -31,8 +31,8 @@ __utimes (const char *file, const struct
   if (tvp)
     {
       times = &buf;
-      buf.actime = tvp[0].tv_sec + (tvp[0].tv_usec + 500000) / 1000000;
-      buf.modtime = tvp[1].tv_sec + (tvp[1].tv_usec + 500000) / 1000000;
+      buf.actime = tvp[0].tv_sec + tvp[0].tv_usec / 1000000;
+      buf.modtime = tvp[1].tv_sec + tvp[1].tv_usec / 1000000;
     }
   else
     times = NULL;

Message #15 received at 202243@bugs.debian.org (full text, mbox, reply):

From: Jim Meyering <jim@meyering.net>

To: Paul Eggert <eggert@CS.UCLA.EDU>

Cc: bug-gnulib@gnu.org, bug-coreutils@gnu.org, libc-alpha@sources.redhat.com, 202243@bugs.debian.org

Subject: Re: glibc utimes glitch with coreutils 'touch'

Date: Sun, 10 Aug 2003 10:19:16 +0200

Paul Eggert <eggert@CS.UCLA.EDU> wrote:
> I'll submit an alternate patch to coreutils so that it works around
> this glibc glitch.  The simplest workaround is to not invoke utimes
> when building with glibc; perhaps I can improve on that, but I don't
> know.

We don't have to condemn the coreutils always
to use the inferior utime interface on glibc systems.
Instead, I'm adding a configure-time test of utimes, so that
if it works, coreutils will use it.

Here's the C program it'll compile and run.
So far it compiles and exits successfully on all systems listed
except for the one with Debian libc6 version 2.3.2-1.

/* tested with gcc on the following:
   AIX 4.3  (both gcc and cc)
   openbsd 3.2
   solaris 9
   netbsd 1.6
   OSF1 V4.0 (both gcc and cc)
   linux 2.4.20, 2.4.21
*/
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/time.h>
#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>
#include <utime.h>

int
main ()
{
  static struct timeval timeval[2] = {{9, 10}, {11, 12}};
  struct stat sbuf;
  char const *file = "x";
  FILE *f;

  exit ( ! ((f = fopen (file, "w"))
	    && fclose (f) == 0
	    && utimes (file, timeval) == 0
	    && lstat (file, &sbuf) == 0
	    && sbuf.st_atime == timeval[0].tv_sec
	    && sbuf.st_mtime == timeval[1].tv_sec) );
}

Message #20 received at 202243@bugs.debian.org (full text, mbox, reply):

From: Dan Kegel <dank@kegel.com>

To: Jim Meyering <jim@meyering.net>

Cc: Paul Eggert <eggert@CS.UCLA.EDU>, 202243@bugs.debian.org

Subject: Re: glibc utimes glitch with coreutils 'touch'

Date: Mon, 11 Aug 2003 12:27:28 -0700

Jim Meyering wrote:
> Instead, I'm adding a configure-time test of utimes, so that
> if it works, coreutils will use it.
> 
> Here's the C program it'll compile and run.

Be sure to allow overriding the test in the usual way,
so the build system's properties can be overridden when cross-compiling glibc...

Thanks,
Dan


-- 
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

Message #27 received at 202243@bugs.debian.org (full text, mbox, reply):

From: GOTO Masanori <gotom@debian.or.jp>

To: Jim Meyering <jim@meyering.net>, 202243@bugs.debian.org

Cc: Paul Eggert <eggert@CS.UCLA.EDU>, bug-gnulib@gnu.org, bug-coreutils@gnu.org, libc-alpha@sources.redhat.com

Subject: Re: Bug#202243: glibc utimes glitch with coreutils 'touch'

Date: Mon, 18 Aug 2003 14:30:14 +0900

At Sun, 10 Aug 2003 10:19:16 +0200,
Jim Meyering wrote:
> Paul Eggert <eggert@CS.UCLA.EDU> wrote:
> > I'll submit an alternate patch to coreutils so that it works around
> > this glibc glitch.  The simplest workaround is to not invoke utimes
> > when building with glibc; perhaps I can improve on that, but I don't
> > know.
> 
> We don't have to condemn the coreutils always
> to use the inferior utime interface on glibc systems.
> Instead, I'm adding a configure-time test of utimes, so that
> if it works, coreutils will use it.
> 
> Here's the C program it'll compile and run.
> So far it compiles and exits successfully on all systems listed
> except for the one with Debian libc6 version 2.3.2-1.

So I patched Jakub's modification for 2.3.2-3, ok?

Regards,
-- gotom

Message #32 received at 202243@bugs.debian.org (full text, mbox, reply):

From: Paul Eggert <eggert@CS.UCLA.EDU>

To: GOTO Masanori <gotom@debian.or.jp>

Cc: Jim Meyering <jim@meyering.net>, 202243@bugs.debian.org, bug-gnulib@gnu.org, bug-coreutils@gnu.org, libc-alpha@sources.redhat.com

Subject: Re: Bug#202243: glibc utimes glitch with coreutils 'touch'

Date: 18 Aug 2003 00:07:28 -0700

GOTO Masanori <gotom@debian.or.jp> writes:

> So I patched Jakub's modification for 2.3.2-3, ok?

If you installed the patch in
<http://sources.redhat.com/ml/libc-alpha/2003-08/msg00062.html>
then you should be OK, but if it's some other patch then I'd like to
know what it was.

Message #37 received at 202243@bugs.debian.org (full text, mbox, reply):

From: GOTO Masanori <gotom@debian.or.jp>

To: Paul Eggert <eggert@CS.UCLA.EDU>, 202243@bugs.debian.org

Cc: GOTO Masanori <gotom@debian.or.jp>, Jim Meyering <jim@meyering.net>, bug-gnulib@gnu.org, bug-coreutils@gnu.org, libc-alpha@sources.redhat.com

Subject: Re: Bug#202243: glibc utimes glitch with coreutils 'touch'

Date: Mon, 18 Aug 2003 21:40:31 +0900

At 18 Aug 2003 00:07:28 -0700,
Paul Eggert wrote:
> GOTO Masanori <gotom@debian.or.jp> writes:
> 
> > So I patched Jakub's modification for 2.3.2-3, ok?
> 
> If you installed the patch in
> <http://sources.redhat.com/ml/libc-alpha/2003-08/msg00062.html>
> then you should be OK, but if it's some other patch then I'd like to
> know what it was.

My previous mention is insufficient.  It's not your patch, Jakub's
2003-07-31 modification, rouding one (the current debian glibc 2.3.2
is based on Mid of July).  Because I found the below sentence in
SuSv3.  It says it may be rounding (or am I missing?):

48734 DESCRIPTION
48735              The utimes( ) function shall set the access and modification times of the file pointed to by the path
48736              argument to the value of the times argument. The utimes( ) function allows time specifications
48737              accurate to the microsecond.
48738              For utimes( ), the times argument is an array of timeval structures. The first array member
48739              represents the date and time of last access, and the second member represents the date and time
48740              of last modification. The times in the timeval structure are measured in seconds and
48741              microseconds since the Epoch, although rounding toward the nearest second may occur.

your reffered "Historically, utimes truncated when it couldn't store
the microseconds" is BSD's original implementation?  Yes, the latest
FreeBSD cvs says:

                tv[0].tv_sec = times->actime;
                tv[1].tv_sec = times->modtime;
                tv[0].tv_usec = tv[1].tv_usec = 0;

Regards,
-- gotom

Message #42 received at 202243@bugs.debian.org (full text, mbox, reply):

From: Paul Eggert <eggert@CS.UCLA.EDU>

To: GOTO Masanori <gotom@debian.or.jp>

Cc: 202243@bugs.debian.org, bug-gnulib@gnu.org, bug-coreutils@gnu.org, libc-alpha@sources.redhat.com

Subject: Re: Bug#202243: glibc utimes glitch with coreutils 'touch'

Date: 18 Aug 2003 13:30:24 -0700

GOTO Masanori <gotom@debian.or.jp> writes:

> "Historically, utimes truncated when it couldn't store the
> microseconds" is BSD's original implementation?

Yes.  I don't know where that phrase in the standard about "rounding"
came from.  Quite possibly it's just a glitch in the standard, and
"truncating" was intended.

Historically, time-related code has always truncated.  For example,
the time() system call, "ls -l", and "date" all truncate.  There are
good reasons for preferring truncation to rounding in timestamps,
despite the greater numeric error.  For example, truncating makes it
easier to answer the question "Was that file modified before
midnight?" when you are looking at lower-resolution timestamps.  And
double-truncation is exact, whereas double-rounding can introduce
extra errors.

When 'utimes()' rounds, it can break applications like 'cp -p' and
'make', because it can cause file timestamps to be in the future
when the timestamps are copied from just-created files.

The current coreutils CVS works around this problem by avoiding
'utimes' if it detects that 'utimes' rounds.  This is unfortunate,
because it disables support for sub-second timestamps in 'cp -p' under
glibc; but at least it doesn't break 'make'.

Please fix this problem by applying the patch in
<http://sources.redhat.com/ml/libc-alpha/2003-08/msg00062.html>.
That will enable coreutils 'cp' to support sub-second timestamps.

Thanks.

Message #47 received at 202243@bugs.debian.org (full text, mbox, reply):

From: GOTO Masanori <gotom@debian.or.jp>

To: Paul Eggert <eggert@CS.UCLA.EDU>, 202243@bugs.debian.org, jakub@redhat.com

Cc: GOTO Masanori <gotom@debian.or.jp>, bug-gnulib@gnu.org, bug-coreutils@gnu.org, libc-alpha@sources.redhat.com

Subject: Re: Bug#202243: glibc utimes glitch with coreutils 'touch'

Date: Tue, 26 Aug 2003 19:05:47 +0900

At 18 Aug 2003 13:30:24 -0700,
Paul Eggert wrote:
> Historically, time-related code has always truncated.  For example,
> the time() system call, "ls -l", and "date" all truncate.  There are
> good reasons for preferring truncation to rounding in timestamps,
> despite the greater numeric error.  For example, truncating makes it
> easier to answer the question "Was that file modified before
> midnight?" when you are looking at lower-resolution timestamps.  And
> double-truncation is exact, whereas double-rounding can introduce
> extra errors.
> 
> When 'utimes()' rounds, it can break applications like 'cp -p' and
> 'make', because it can cause file timestamps to be in the future
> when the timestamps are copied from just-created files.

Exactly.  I fully agreed with your opinion.  I applied.

> The current coreutils CVS works around this problem by avoiding
> 'utimes' if it detects that 'utimes' rounds.  This is unfortunate,
> because it disables support for sub-second timestamps in 'cp -p' under
> glibc; but at least it doesn't break 'make'.
> 
> Please fix this problem by applying the patch in
> <http://sources.redhat.com/ml/libc-alpha/2003-08/msg00062.html>.
> That will enable coreutils 'cp' to support sub-second timestamps.

Jakub, please take care this problem and show the flag to apply Paul's
patch?  I believe there are no point to object his patch.

Regards,
-- gotom

Message #54 received at 202243-close@bugs.debian.org (full text, mbox, reply):

From: Philip Blundell <pb@nexus.co.uk>

To: 202243-close@bugs.debian.org

Subject: Bug#202243: fixed in glibc 2.3.2-4

Date: Tue, 26 Aug 2003 17:34:27 -0400

Source: glibc
Source-Version: 2.3.2-4

We believe that the bug you reported is fixed in the latest version of
glibc, which is due to be installed in the Debian FTP archive:

glibc-doc_2.3.2-4_all.deb
  to pool/main/g/glibc/glibc-doc_2.3.2-4_all.deb
glibc_2.3.2-4.diff.gz
  to pool/main/g/glibc/glibc_2.3.2-4.diff.gz
glibc_2.3.2-4.dsc
  to pool/main/g/glibc/glibc_2.3.2-4.dsc
libc-udeb_2.3.2-4_i386.udeb
  to pool/main/g/glibc/libc-udeb_2.3.2-4_i386.udeb
libc6-dbg_2.3.2-4_i386.deb
  to pool/main/g/glibc/libc6-dbg_2.3.2-4_i386.deb
libc6-dev_2.3.2-4_i386.deb
  to pool/main/g/glibc/libc6-dev_2.3.2-4_i386.deb
libc6-pic_2.3.2-4_i386.deb
  to pool/main/g/glibc/libc6-pic_2.3.2-4_i386.deb
libc6-prof_2.3.2-4_i386.deb
  to pool/main/g/glibc/libc6-prof_2.3.2-4_i386.deb
libc6_2.3.2-4_i386.deb
  to pool/main/g/glibc/libc6_2.3.2-4_i386.deb
locales_2.3.2-4_all.deb
  to pool/main/g/glibc/locales_2.3.2-4_all.deb
nscd_2.3.2-4_i386.deb
  to pool/main/g/glibc/nscd_2.3.2-4_i386.deb



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 202243@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Philip Blundell <pb@nexus.co.uk> (supplier of updated glibc 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: Tue, 26 Aug 2003 17:27:00 +0100
Source: glibc
Binary: libc6.1-prof libc1 libc0.3-pic locales glibc-doc libc6-pic libc-udeb libc1-prof libc0.3 libc0.3-dbg libc6.1-dev libc1-pic libc6-s390x libc6-prof libc1-dbg libc6-dev-sparc64 libc6 libc0.3-dev libc6-dbg nscd libc6.1-dbg libc6.1-pic libc6-sparc64 libc6-dev libc0.3-prof libc6.1 libc6-dev-s390x libc1-dev
Architecture: source i386 all
Version: 2.3.2-4
Distribution: unstable
Urgency: low
Maintainer: GNU Libc Maintainers <debian-glibc@lists.debian.org>
Changed-By: Philip Blundell <pb@nexus.co.uk>
Description: 
 glibc-doc  - GNU C Library: Documentation
 libc-udeb  - GNU C Library: Shared libraries and Timezone data - udeb (udeb)
 libc6      - GNU C Library: Shared libraries and Timezone data
 libc6-dbg  - GNU C Library: Libraries with debugging symbols
 libc6-dev  - GNU C Library: Development Libraries and Header Files.
 libc6-pic  - GNU C Library: PIC archive library
 libc6-prof - GNU C Library: Profiling Libraries.
 locales    - GNU C Library: National Language (locale) data [support]
 nscd       - GNU C Library: Name Service Cache Daemon
Closes: 202243 204728 205110 206464 206783 206839 206895
Changes: 
 glibc (2.3.2-4) unstable; urgency=low
 .
   * Jeff Bailey <jbailey@nisa.net>
     - debian/locales/DEBIAN/postinst: Use tail -n 1 instead of tail -1.
       Thanks to Jurij Smakov (Closes: #206464)
 .
   * Phil Blundell <pb@debian.org>
     - debian/patches/glibc23-arm-waitpid.dpatch: deleted.
     - for arm, Build-Depend on kernel-headers 2.4.19-4 or newer.
       (Closes: #206895)
     - debian/patches/revert-old-libio.dpatch: back out changes causing
       problems with fseek in binaries linked with glibc 2.0.
       (Closes: #206839)
     - debian/libc/DEBIAN/postinst: also restart cucipop (Closes: #206783)
     - debian/patches/arm-output-format.dpatch: Very bad hack to avoid
       problem with libc.so on ARM until a proper fix is forthcoming.
     - debian/patches/81_glibc232-utimes-fix.dpatch: replace with version
       that applies cleanly to current sources.
     - debian/control: require sed 4.0.5-4 or later.
 .
   * GOTO Masanori <gotom@debian.org>
 .
     - debian/po/es.po: Updated Spanish (es) debconf template.
       Patched by Carlos Valdivia Yagüe <valyag@dat.etsit.upm.es>.
     - debian/patches/81_glibc232-utimes-fix.dpatch: Fix utimes wrong time
       calculation.  Patched by Paul Eggert <eggert@CS.UCLA.EDU>.
       (Closes: #204728, #202243, #205110)
Files: 
 bf67d6d312907bb95ef5d7628d9a7336 1571 libs required glibc_2.3.2-4.dsc
 3596e4ac126820e32670cd764c669b9f 1161672 libs required glibc_2.3.2-4.diff.gz
 eab00d5074fa7920746f582c425c30eb 3599350 base required libc6_2.3.2-4_i386.deb
 9a0f06d585b253b59dac1bbc2a762290 1028264 debian-installer required libc-udeb_2.3.2-4_i386.udeb
 749436fe6cf59db4087ce142e88000fd 2574854 libdevel standard libc6-dev_2.3.2-4_i386.deb
 d9536fac17d02ba27e42ad9e0314bdff 1000852 devel extra libc6-prof_2.3.2-4_i386.deb
 18ff8946686e727a0bba9ccc0240f567 8469226 devel extra libc6-dbg_2.3.2-4_i386.deb
 c9b2fed3903d0312c789d7d09b4dc23b 952192 devel optional libc6-pic_2.3.2-4_i386.deb
 6bce03106f03c3db57e9190092b50c00 75002 admin optional nscd_2.3.2-4_i386.deb
 60caed78f6684f053eb1b065f134f278 3785602 base standard locales_2.3.2-4_all.deb
 0ad68a05ca661173a7aea4bad91d2d8b 3084010 doc optional glibc-doc_2.3.2-4_all.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE/S8gOVTLPJe9CT30RAvcrAJ9qWooWC2uZnN7+Wo2uBzcaXhDiPgCgsLQ2
oSLHKK6b02lODDQLI0+4Z/4=
=+3Qo
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.