Dear Maintainer,

During a ratt run for src:ossp-uuid, I see
  2024/09/26 16:46:59 Building package 68 of 123: gscan2pdf

It's currently 2024-09-26T17:03:48+02:00,
and the process tree looks like this:
  2992217   1628 S 0.0 0.0 0:00.00  └─ sh /usr/bin/xvfb-run -a dh_auto_test
  2992230   5284 S 0.0 0.0 0:00.11     ├─ perl /usr/bin/dh_auto_test
  2992237   2064 S 0.0 0.0 0:00.02     │  └─ make -j24 test TEST_VERBOSE=1
  2992252   5336 S 0.0 0.0 0:00.63     │     └─ perl -MExtUtils::Command::MM -MTest::Harness -e undef *Test::Harness::Switches; test_harness(1,
  3001120  75204 S 0.0 0.2 0:02.01     │        └─ perl t/1113_save_pdf_with_error.t
  3001252  75204 S 0.0 0.2 0:00.14     │           └─ perl t/1113_save_pdf_with_error.t
  2992227  50892 S 0.0 0.1 0:02.35     └─ Xvfb :99 -screen 0 1280x1024x24 -nolisten tcp -auth /tmp/xvfb-run.wk10k0/Xauthority
and hasn't changed the last few times I looked (3001252 is a thread).

strace says
  recvmsg(4, {msg_namelen=0}, 0)          = -1 EAGAIN (Resource temporarily unavailable)
  recvmsg(4, {msg_namelen=0}, 0)          = -1 EAGAIN (Resource temporarily unavailable)
  ppoll([{fd=4, events=POLLIN}, {fd=10, events=POLLIN}], 2, {tv_sec=0, tv_nsec=99179000}, NULL, 8) = 0 (Timeout)
  recvmsg(4, {msg_namelen=0}, 0)          = -1 EAGAIN (Resource temporarily unavailable)
  recvmsg(4, {msg_namelen=0}, 0)          = -1 EAGAIN (Resource temporarily unavailable)
  ppoll([{fd=4, events=POLLIN}, {fd=10, events=POLLIN}], 2, {tv_sec=0, tv_nsec=99457000}, NULL, 8) = 0 (Timeout)
  recvmsg(4, {msg_namelen=0}, 0)          = -1 EAGAIN (Resource temporarily unavailable)
  recvmsg(4, {msg_namelen=0}, 0)          = -1 EAGAIN (Resource temporarily unavailable)
  ppoll([{fd=4, events=POLLIN}, {fd=10, events=POLLIN}], 2, {tv_sec=0, tv_nsec=99636000}, NULL, 8) = 0 (Timeout)
  recvmsg(4, {msg_namelen=0}, 0)          = -1 EAGAIN (Resource temporarily unavailable)
  recvmsg(4, {msg_namelen=0}, 0)          = -1 EAGAIN (Resource temporarily unavailable)
  ppoll([{fd=4, events=POLLIN}, {fd=10, events=POLLIN}], 2, {tv_sec=0, tv_nsec=99280000}, NULL, 8^Cstrace: Process 3001120 detached

  futex(0x7f7054000ca4, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, NULL, FUTEX_BITSET_MATCH_ANY^Cstrace: Process 3001252 detached

  epoll_wait(3, ^Cstrace: Process 2992227 detached

This is a ratt run, so the build is in a schroot.
I created the chroot this morning, so no funny business there.

I SIGINTed the test, and the tests continued.
The same happened with t/133_save_tiff_with_error.t later.
The same happened with t/1612_import_TIFF_with_error.t later.
The same happened with t/1626_import_PDF_with_error.t later.
The same happened with t/1632_import_ppm_with_error.t later.
The same happened with t/213_rotate_with_error.t later.
The same happened with t/243_threshold_with_error.t later.
The same happened with t/253_negate_with_error.t later.
The same happened with t/263_unsharp_mask_with_error.t later.
The same happened with t/273_crop_with_error.t later.
The same happened with t/283_to_png_with_error.t later.
The same happened with t/377_user_defined_with_error.t later.
One has to wonder if the error is that it hangs.

I'm attaching the build log.

Don't think this is the same as #1012250 since that's autopkgtests.

Naturally,
2024/09/26 17:21:32 building gscan2pdf failed: exit status 2
but I'm forced to assume this is due to whatever flakiness in the test?

I reproduce this behaviour with a plain sbuild -d unstable gscan2pdf
so it's not the fault of the new src:ossp-uuid.

Best,

I can't reproduce this. The tests pass elsewhere in chroots:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/gscan2pdf.html

What is different about your setup?

El 28/9/24 a las 12:31, Jeff escribió:

Most probably, the fact that he's building the package as root.
This is from the build log:

LOGNAME=root

Hi наб, you should probably say this in your reports.

Thanks.

retitle 1082815 analizo: FTBFS (tests fail) on sid if building as root
retitle 1082810 gscan2pdf: deadlock in tests if building as root
# 1082804 is already ledgersmb: FTBFS (test failure) if building as root
thanks
Yeah, I didn't so much as consider running as root being the issue.

Best,

If that is the case, I wonder if this really should be severity=serious.

Maybe severity=normal?

severity 1082810 normal
thanks

If the build should not be done as root, perhaps debian/rules should
be extended with a call to ! dh_testroot, to ensure the build fail
with root privileges?