bug#44953: lsof: LTlock test consistently fails (possibly due to btrfs)

bug#44953: lsof: LTlock test consistently fails (possibly due to btrfs)

[Mark H Weaver]

In the 'lsof' test suite, the 'LTlock' test consistently fails on my
system, possibly related to the fact that I use 'btrfs' for my local
filesystems.  Here's the relevant build log excerpt:

--8<---------------cut here---------------start------------->8---
Optional tests:
LTbigf ... OK
LTdnlc ... /tmp/guix-build-lsof-4.94.0.drv-0/lsof-4.94.0-checkout/tests found: 100.00%
           OK
LTlock ... lock mismatch: expected W, got " "
           lock mismatch: expected R, got " "
           lock mismatch: expected w, got " "
           lock mismatch: expected r, got " "
Failed tests: 1

make: *** [Makefile:118: opt] Error 1
command "make" "standard" "optional" failed with status 2
note: keeping build directory `/tmp/guix-build-lsof-4.94.0.drv-0'
builder for `/gnu/store/cgkl1prkfmaz7b7j37xlzyhh8nhqkdyw-lsof-4.94.0.drv' failed with exit code 1
build of /gnu/store/cgkl1prkfmaz7b7j37xlzyhh8nhqkdyw-lsof-4.94.0.drv failed
--8<---------------cut here---------------end--------------->8---

The following commit made this into a fatal build error, which I agree
is an improvement:

--8<---------------cut here---------------start------------->8---
commit 2bf502138c9c8cad945866061772fe0e1f4b7175
Author: Tobias Geerinckx-Rice <me@tobias.gr>
Date:   Mon Nov 23 05:05:41 2020 +0100

  gnu: lsof: Make test failures fatal.
  
  * gnu/packages/lsof.scm (lsof)[source]: Add patch to make test suite
  failures stop the build.
  * gnu/packages/patches/lsof-fatal-test-failures.patch: New file.
  * gnu/local.mk (dist_patch_DATA): Add it.
--8<---------------cut here---------------end--------------->8---

Previously, the same test failure occurred on my system with lsof-4.91,
but the failure was ignored and I didn't notice it until now.  Before
that, our lsof-4.89 package did not run the test suite, so I do not know
if it had the same bug.

     Mark

bug#44953: lsof: LTlock test consistently fails (possibly due to btrfs)

[Mark H Weaver]

I should mention that 'gnome' depends on 'lsof' via the following
dependency path (among others):

gnome -> gnome-shell -> ruby-sass -> ruby-sass-spec -> ruby-terminfo ->
   ruby-rdoc -> ruby-rubocop -> ruby-parallel -> lsof

      Mark

bug#44953: lsof: LTlock test consistently fails (possibly due to btrfs)

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

[-- Attachment #1: Type: text/plain, Size: 883 bytes --]

Mark,

Mark H Weaver 写道：
> In the 'lsof' test suite, the 'LTlock' test consistently fails 
> on my
> system, possibly related to the fact that I use 'btrfs' for my 
> local
> filesystems.

Thanks for the report!  I can reproduce this by formatting a btrfs 
image file and loop-mounting it to /tmp.

This looks like an upstream bug to me.  Do you have time to file 
one?  We're using the <https://github.com/lsof-org/lsof> upstream 
since Victor Abell retired.

Alternatively we could disable this test in Guix ‘for now’ with a 
comment--but we both know how long it will remain unfixed.

Side note: I tried to implement upstream's test workflow[0] but 
got new failures (i.e. we're not running all the tests yet).  I 
haven't tried fixing those yet.

Kind regards,

T G-R

[0]: 
https://github.com/lsof-org/lsof/pull/144#issuecomment-732204193

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

bug#44953: lsof: LTlock test consistently fails (possibly due to btrfs)

[Mark H Weaver]

Hi Tobias,

Thanks for the super quick response and for reproducing the bug.

> This looks like an upstream bug to me.

Agreed.

> Do you have time to file 
> one?  We're using the <https://github.com/lsof-org/lsof> upstream 
> since Victor Abell retired.

I have time, but there's another problem: it appears that I cannot file
a bug report on Github without first creating an account, which in turn
requires me to formally agree to their legal agreement.  Among other
things, it includes an indemnification clause, meaning that I would have
to promise to pay their legal fees if some dispute arises involving me
and they decide to retain laywers to deal with it.  They also claim the
right to change the terms of the agreement at any time without notifying
me, and by continuing to use the service I would implicitly agree to
those new terms.

I refuse to sign that agreement, which means that I cannot file bug
reports on Github.  Oh well.

I don't actually care about 'lsof', except for the fact that our 'gnome'
package depends on it.  For now, I'll just disable the 'lsof' test suite
on my private branch.

> Alternatively we could disable this test in Guix ‘for now’ with a
> comment--but we both know how long it will remain unfixed.

Sounds fine to me, unless someone who has already has a Github account
wants to use it to file a bug.

  Thanks again,
      Mark

bug#44953: lsof: LTlock test consistently fails (possibly due to btrfs)

[raingloom]

On Sun, 29 Nov 2020 20:30:20 -0500
Mark H Weaver <mhw@netris.org> wrote:

> Hi Tobias,
> 
> Thanks for the super quick response and for reproducing the bug.
> 
> > This looks like an upstream bug to me.  
> 
> Agreed.
> 
> > Do you have time to file 
> > one?  We're using the <https://github.com/lsof-org/lsof> upstream 
> > since Victor Abell retired.  
> 
> I have time, but there's another problem: it appears that I cannot
> file a bug report on Github without first creating an account, which
> in turn requires me to formally agree to their legal agreement.
> Among other things, it includes an indemnification clause, meaning
> that I would have to promise to pay their legal fees if some dispute
> arises involving me and they decide to retain laywers to deal with
> it.  They also claim the right to change the terms of the agreement
> at any time without notifying me, and by continuing to use the
> service I would implicitly agree to those new terms.
> 
> I refuse to sign that agreement, which means that I cannot file bug
> reports on Github.  Oh well.
> 
> I don't actually care about 'lsof', except for the fact that our
> 'gnome' package depends on it.  For now, I'll just disable the 'lsof'
> test suite on my private branch.
> 
> > Alternatively we could disable this test in Guix ‘for now’ with a
> > comment--but we both know how long it will remain unfixed.  
> 
> Sounds fine to me, unless someone who has already has a Github account
> wants to use it to file a bug.
> 
>   Thanks again,
>       Mark
> 
> 
> 

My usual workaround to this is to do a shallow clone (git clone --depth
1) and look for frequently occuring email addresses in git log.
Then I just send the bug/patch to them. It hasn't failed so far.

bug#44953: lsof: LTlock test consistently fails (possibly due to btrfs)

[Maxim Cournoyer]

Hello,

For the record it seems Tobias had gotten around filing a bug here:
https://github.com/lsof-org/lsof/issues/152.

It seems the issue is real and a new Linux-specific tool lsfd is being
devised.  I guess we should disable the test, as the package is still
probably mostly functional on Btrfs, and wait for a proper resolution
from upstream?

Mark, could you share your patch disabling the test if you still have it
handy?

Thanks,

Maxim

bug#44953: lsof: LTlock test consistently fails (possibly due to btrfs)

[Maxim Cournoyer]

Hello again,

Mark, I've figured it out and disabled it locally.  Will push shortly to
core-updates-frozen.

Thanks!

Maxim

bug#44953: lsof: LTlock test consistently fails (possibly due to btrfs)

[Mark H Weaver]

[-- Attachment #1: Type: text/plain, Size: 636 bytes --]

Hi Maxim,

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

> For the record it seems Tobias had gotten around filing a bug here:
> https://github.com/lsof-org/lsof/issues/152.
>
> It seems the issue is real and a new Linux-specific tool lsfd is being
> devised.  I guess we should disable the test, as the package is still
> probably mostly functional on Btrfs, and wait for a proper resolution
> from upstream?
>
> Mark, could you share your patch disabling the test if you still have it
> handy?

Here's what I did on my private branch, which has diverged quite a bit
from master, so I don't know whether it will apply cleanly.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: [PATCH] Revert "gnu: lsof: Make test failures fatal." --]
[-- Type: text/x-patch, Size: 3345 bytes --]

From 1a658341538b8ea1470ef1bd02dfb3922011df79 Mon Sep 17 00:00:00 2001
From: Mark H Weaver <mhw@netris.org>
Date: Sun, 29 Nov 2020 16:03:57 -0500
Subject: [PATCH] Revert "gnu: lsof: Make test failures fatal."

This reverts commit 2bf502138c9c8cad945866061772fe0e1f4b7175.
---
 gnu/local.mk                                  |  1 -
 gnu/packages/lsof.scm                         |  3 +-
 .../patches/lsof-fatal-test-failures.patch    | 58 -------------------
 3 files changed, 1 insertion(+), 61 deletions(-)
 delete mode 100644 gnu/packages/patches/lsof-fatal-test-failures.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index eaa358266a..f53ceb35e9 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -1378,7 +1378,6 @@ dist_patch_DATA =						\
   %D%/packages/patches/lm-sensors-hwmon-attrs.patch		\
   %D%/packages/patches/lrcalc-includes.patch    		\
   %D%/packages/patches/lsh-fix-x11-forwarding.patch		\
-  %D%/packages/patches/lsof-fatal-test-failures.patch		\
   %D%/packages/patches/lua-CVE-2014-5461.patch                      \
   %D%/packages/patches/lua-pkgconfig.patch                      \
   %D%/packages/patches/lua51-liblua-so.patch                    \
diff --git a/gnu/packages/lsof.scm b/gnu/packages/lsof.scm
index b317902ee7..3e527a272f 100644
--- a/gnu/packages/lsof.scm
+++ b/gnu/packages/lsof.scm
@@ -41,8 +41,7 @@
             (commit version)))
       (file-name (git-file-name name version))
       (sha256
-       (base32 "0yxv2jg6rnzys49lyrz9yjb4knamah4xvlqj596y6ix3vm4k3chp"))
-      (patches (search-patches "lsof-fatal-test-failures.patch"))))
+       (base32 "0yxv2jg6rnzys49lyrz9yjb4knamah4xvlqj596y6ix3vm4k3chp"))))
    (build-system gnu-build-system)
    (native-inputs
     `(("groff" ,groff)                  ; for soelim
diff --git a/gnu/packages/patches/lsof-fatal-test-failures.patch b/gnu/packages/patches/lsof-fatal-test-failures.patch
deleted file mode 100644
index e874ba6ad4..0000000000
--- a/gnu/packages/patches/lsof-fatal-test-failures.patch
+++ /dev/null
@@ -1,58 +0,0 @@
-From: Tobias Geerinckx-Rice <me@tobias.gr>
-Date: Mon, 23 Nov 2020 05:36:53 +0100
-Subject: [PATCH] gnu: lsof: Make test failures fatal.
-
-Submitted upstream[0].
-
-[0]: https://github.com/lsof-org/lsof/pull/144
-
-diff --git a/tests/Makefile b/tests/Makefile
-index 08574a0..2923bb8 100644
---- a/tests/Makefile
-+++ b/tests/Makefile
-@@ -27,7 +27,7 @@ all:	${CKTSTDB} ${BASTST} ${STDTST} FRC
- 	  exit 1 ;\
- 	fi
- 	@rm -f config.LT*
--	-@err=0; \
-+	@err=0; \
- 	echo ""; \
- 	echo "Basic test:"; \
- 	./${BASTST}; \
-@@ -54,8 +54,11 @@ all:	${CKTSTDB} ${BASTST} ${STDTST} FRC
- 	    echo "Suggestion: try the optional tests: \"make opt\""; \
- 	    echo ""; \
- 	  fi; \
--	fi;
--	@rm -f config.LT*
-+	fi; \
-+	rm -f config.LT*; \
-+	if [ $$err -ne 0 ]; then \
-+	  exit 1; \
-+	fi
- 
- auto:	ckDB silent FRC
- 
-@@ -112,7 +115,7 @@ LTunix: LTunix.c ${CONFIG} ${LIBOBJ} ${HDR} config.ldflags
- 
- opt:	${CKTSTDB} ${OPTTST} FRC
- 	@rm -f config.LT*
--	-@err=0; \
-+	@err=0; \
- 	echo ""; \
- 	echo "Optional tests:"; \
- 	for i in ${OPTTST}; do \
-@@ -126,8 +129,11 @@ opt:	${CKTSTDB} ${OPTTST} FRC
- 	else \
- 	  echo "All optional tests succeeded."; \
- 	fi; \
--	echo "";
--	@rm -f config.LT*
-+	echo ""; \
-+	rm -f config.LT*; \
-+	if [ $$err -ne 0 ]; then \
-+	  exit 1; \
-+	fi
- 
- optional: opt
- 
-- 
2.31.1


[-- Attachment #3: Type: text/plain, Size: 154 bytes --]


-- 
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about <https://stallmansupport.org>.

bug#44953: lsof: LTlock test consistently fails (possibly due to btrfs)

[Maxim Cournoyer]

Hello,

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

> Hello again,
>
> Mark, I've figured it out and disabled it locally.  Will push shortly to
> core-updates-frozen.

core-updates-frozen was merged into master long ago :-)

Closing.

Maxim