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

  • Done
  • quality assurance status badge
Details
4 participants
  • Maxim Cournoyer
  • Tobias Geerinckx-Rice
  • Mark H Weaver
  • raingloom
Owner
unassigned
Submitted by
Mark H Weaver
Severity
normal
M
M
Mark H Weaver wrote on 29 Nov 2020 22:02
(address . bug-guix@gnu.org)
87zh2zdgfh.fsf@netris.org
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:

Toggle snippet (17 lines)
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

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

Toggle snippet (12 lines)
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.

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
M
M
Mark H Weaver wrote on 29 Nov 2020 22:25
(address . 44953@debbugs.gnu.org)
87wny3dfe3.fsf@netris.org
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
T
T
Tobias Geerinckx-Rice wrote on 29 Nov 2020 22:33
(name . Mark H Weaver)(address . mhw@netris.org)
874kl7zw4u.fsf@nckx
Mark,

Mark H Weaver ???
Toggle quote (6 lines)
> 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]:
-----BEGIN PGP SIGNATURE-----

iIMEARYKACsWIQT12iAyS4c9C3o4dnINsP+IT1VteQUCX8QTkQ0cbWVAdG9iaWFz
LmdyAAoJEA2w/4hPVW15IcAA/0Q+oA76FwdyxAASLpvDtTBJJIZuivTWpLs1dCMI
KPtWAQDBYcCYfqjkTTw9tFviD11U38ePYC3oxSE1RlBgt0AhAA==
=msE2
-----END PGP SIGNATURE-----

M
M
Mark H Weaver wrote on 30 Nov 2020 02:30
(name . Tobias Geerinckx-Rice)(address . me@tobias.gr)
87r1obd41k.fsf@netris.org
Hi Tobias,

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

Toggle quote (2 lines)
> This looks like an upstream bug to me.

Agreed.

Toggle quote (4 lines)
> 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.

Toggle quote (3 lines)
> 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
R
R
raingloom wrote on 5 Dec 2020 02:57
(name . Mark H Weaver)(address . mhw@netris.org)
20201205025736.50b83726@riseup.net
On Sun, 29 Nov 2020 20:30:20 -0500
Mark H Weaver <mhw@netris.org> wrote:

Toggle quote (41 lines)
> 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.
M
M
Maxim Cournoyer wrote on 15 Oct 2021 06:15
(name . raingloom)(address . raingloom@riseup.net)
87zgranctj.fsf@gmail.com
Hello,

For the record it seems Tobias had gotten around filing a bug here:

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
M
M
Maxim Cournoyer wrote on 15 Oct 2021 06:29
(name . raingloom)(address . raingloom@riseup.net)
87v91ync5t.fsf@gmail.com
Hello again,

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

Thanks!

Maxim
M
M
Mark H Weaver wrote on 15 Oct 2021 11:11
871r4mbqjw.fsf@netris.org
Hi Maxim,

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

Toggle quote (11 lines)
> 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.
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

Toggle diff (92 lines)
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
--
Disinformation flourishes because many people care deeply about injustice
but very few check the facts. Ask me about https://stallmansupport.org.
M
M
Maxim Cournoyer wrote on 9 Jun 2022 23:23
(name . raingloom)(address . raingloom@riseup.net)
87o7z1h6pw.fsf@gmail.com
Hello,

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

Toggle quote (5 lines)
> 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
Closed
?
Your comment

This issue is archived.

To comment on this conversation send an email to 44953@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 44953
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch