In reply to @janne.hess:helsinki-systems.de

This is probably what's needed to disable lseek:

diff --git a/src/copy.c b/src/copy.c
index cb9018f93..2a4ccc061 100644
--- a/src/copy.c
+++ b/src/copy.c
@@ -502,7 +502,7 @@ write_zeros (int fd, off_t n_bytes)
   return true;
 }

-#ifdef SEEK_HOLE
+#if 0
 /* Perform an efficient extent copy, if possible.  This avoids
    the overhead of detecting holes in hole-introducing/preserving
    copy, and thus makes copying sparse files much more efficient.
@@ -1095,7 +1095,7 @@ infer_scantype (int fd, struct stat const *sb,
          && ST_NBLOCKS (*sb) < sb->st_size / ST_NBLOCKSIZE))
     return PLAIN_SCANTYPE;

-#ifdef SEEK_HOLE
+#if 0
   scan_inference->ext_start = lseek (fd, 0, SEEK_DATA);
   if (0 <= scan_inference->ext_start)
     return LSEEK_SCANTYPE;
@@ -1377,7 +1377,7 @@ copy_reg (char const *src_name, char const *dst_name,
       off_t n_read;
       bool wrote_hole_at_eof = false;
       if (! (
-#ifdef SEEK_HOLE
+#if 0
              scantype == LSEEK_SCANTYPE
              ? lseek_copy (source_desc, dest_desc, buf, buf_size, hole_size,
                            scan_inference.ext_start, src_open_sb.st_size,
diff --git a/tests/seek-data-capable b/tests/seek-data-capable
index cc6372214..6e7a9ec1e 100644
--- a/tests/seek-data-capable
+++ b/tests/seek-data-capable
@@ -1,5 +1,7 @@
 import sys, os, errno, platform

+sys.exit(1)
+
 # Pass an _empty_ file
 if len(sys.argv) != 2:
     sys.exit(1)

In reply to @vcunat:matrix.org
I also confirm that this patch fixes peertube build, atop staging-next. (same machine: all ext4 on LVM, x86_64-linux)

In reply to @janne.hess:helsinki-systems.de
Also, is your /tmp on tmpfs?

In reply to @janne.hess:helsinki-systems.de
Awesome! Thank you. The build fails because presumably a file is broken, right? It's not because cp fails in the build process?

I haven't poked into details of the error. It looks like it attempts some tests after build and those all end with

Error: The service is no longer running

In reply to @vcunat:matrix.org
No, it's all ext4 on LVM.

In reply to @janne.hess:helsinki-systems.de
Because that's one big difference between us. For you, it's the same filesystem, for me it's not

In reply to @vcunat:matrix.org
Build on progress. (plain staging-next, all same except for tmpfs on /tmp)

It still fails, but the error is different; I think it happens a bit earlier than with ext4 (before any tests start)

Generating browser application bundles (phase: building)...node:events:368
      throw er; // Unhandled 'error' event
      ^

Error: write EPIPE

In reply to @vcunat:matrix.org

I haven't poked into details of the error. It looks like it attempts some tests after build and those all end with

Error: The service is no longer running

In reply to @vcunat:matrix.org

It still fails, but the error is different; I think it happens a bit earlier than with ext4 (before any tests start)

Generating browser application bundles (phase: building)...node:events:368
      throw er; // Unhandled 'error' event
      ^

Error: write EPIPE

In reply to @moritz.hedtke:matrix.org
What's wrong with the reply feature?!?

In reply to @vcunat:matrix.org
I can't see anything wrong really. Perhaps just not too ergonomic in my opinion (in Element UI at least).

In reply to @moritz.hedtke:matrix.org
Regarding the first error are you sure it's when the tests are running? I will check later but I though it was still while building but I didn't really pay attention that closely