diff -Nru monotone-1.1/debian/changelog monotone-1.1/debian/changelog
--- monotone-1.1/debian/changelog	2015-09-18 07:36:07.000000000 +0000
+++ monotone-1.1/debian/changelog	2015-11-15 17:15:51.000000000 +0000
@@ -1,3 +1,10 @@
+monotone (1.1-7) unstable; urgency=medium
+
+  * Modify patch 51-sigpipe-test.diff: increase bytes written to 1M to
+    increase chances to overflow the pipe buffer even further.
+
+ -- Markus Wanner <markus@bluegap.ch>  Sun, 15 Nov 2015 18:14:19 +0100
+
 monotone (1.1-6) unstable; urgency=medium
 
   * Patch Makefile.am to not rebuild NLS (i.e. pot and po files) so as
diff -Nru monotone-1.1/debian/patches/51-sigpipe-test.diff monotone-1.1/debian/patches/51-sigpipe-test.diff
--- monotone-1.1/debian/patches/51-sigpipe-test.diff	2015-09-18 07:32:35.000000000 +0000
+++ monotone-1.1/debian/patches/51-sigpipe-test.diff	2015-11-15 17:13:59.000000000 +0000
@@ -1,12 +1,12 @@
 Description: Attempt to fix 'log_quits_on_SIGPIPE' failure on powerpc
- Double the number of commits in preparation for the SIGPIPE test, so
+ Quatruple the number of commits in preparation for the SIGPIPE test, so
  we're not just writing (somewhere above) 256K but 512K.
  .
  This is a somewhat desperate but conservative attempt at fixing a
  buildd issue that's hard to reproduce.
 Bug-Debian: https://bugs.debian.org/797386
 Forwarded: no
-Last-Update: 2015-09-18
+Last-Update: 2015-11-15
 
 --- a/test/func/log_quits_on_SIGPIPE/__driver__.lua
 +++ b/test/func/log_quits_on_SIGPIPE/__driver__.lua
@@ -15,12 +15,12 @@
  -- out how much buffer space the kernel provides, so we resort to
  -- writing a ridiculous amount of data.  Typical pipe capacities are
 --- 4K and 64K, so "ridiculous" in this case is "approximately 256K."
-+-- 4K and 64K, so "ridiculous" in this case is "approximately 512K."
++-- 4K and 64K, so "ridiculous" in this case is "approximately 1M."
  --
  -- We would like to make that data realistic -- typical commits to the
  -- monotone repository have between 100 and 200 characters of commit
 --- log -- but in order to get the ridiculous 256K, we would need
-+-- log -- but in order to get the ridiculous 512K, we would need
++-- log -- but in order to get the ridiculous 1M, we would need
  -- several thousand commits, which would take too long to execute.
 --- So instead we make four commits each with 64K commit messages.
 --- (There is a temptation to make it sixteen; I can imagine someone
@@ -28,7 +28,7 @@
 --- But the time this test takes is proportional to the number of
 --- commits, so I won't.  I tried having a bigger log message but that
 --- crashed "mtn commit".)
-+-- So instead we make eight commits each with 64K commit messages.
++-- So instead we make 16 commits each with 64K commit messages.
  --
  -- The following 1024-byte block of nonsense is courtesy of the Eater
  -- of Meaning.
@@ -37,7 +37,7 @@
  mtn_setup()
  addfile("file", "fnord")
 -for i = 1,4 do
-+for i = 1,8 do
++for i = 1,16 do
     writefile("file", "commit "..tonumber(i).."\n")
     commit(nil, message)
  end