unofficial mirror of meta@public-inbox.org
 help / color / mirror / Atom feed
From: Dominique Martinet <asmadeus@codewreck.org>
To: Eric Wong <e@80x24.org>
Cc: Julien Moutinho <julm+public-inbox@sourcephile.fr>,
	meta@public-inbox.org
Subject: Re: Test failures with 1.7.0
Date: Wed, 8 Dec 2021 19:56:24 +0900	[thread overview]
Message-ID: <YbCPWGaJEkV6eWfo@codewreck.org> (raw)
In-Reply-To: <20211208040836.GA27368@dcvr>

Hi,

Eric Wong wrote on Wed, Dec 08, 2021 at 04:08:36AM +0000:
> > And another reviewer fails 3 times with:
> > > t/extsearch.t              (Wstat: 2048 Tests: 145 Failed: 8)
> > >   Failed tests:  68-69, 75-76, 86, 98, 102, 139
> > >   Non-zero exit status: 8
> > > t/imapd.t                  (Wstat: 256 Tests: 186 Failed: 1)
> > >   Failed test:  183
> > >   Non-zero exit status: 1
> > > t/nntpd.t                  (Wstat: 256 Tests: 110 Failed: 1)
> > >   Failed test:  104
> > >   Non-zero exit status: 1

(I'm that one)

So instead of giving the output of prove -bvw t/nntpd.t (I couldn't
reproduce manually..), I'll go straight to the solution: it looks like
there's a problem with the chattr fallback when btrfs is present on the
machine (to disable cow, lib/PublicInbox/NDC_PP.pm)

I had initial messages about chattr not being found; adding chattr to
the build inputs gave another error message that chattr +C doesn't work
on tmpfs.
The problem here seems to be that the fallback here just checks
/proc/self/mounts and calls chattr "just in case", saying it's ok if it
fails, but some tests probably rely on stderr output being empty?

If so it looks more like a test problem than anything else to me, but
perhaps the fallback path could be a bit more prudent in its calling of
chattr (or simply try silencing its output?)

For testing, being a bit forceful and removing that chattr call made all
the tests pass for me.


Now the $100 question is I don't know why the Inline::C version wasn't
used; this one properly calls statfs() and does the ioctl directly only
if required so would have worked.
As far as I can see we're installing Inline::C in the build chroot, I
see it in the PERL5LIB paths; and make/gcc are also available so it
probably should work. Is there a way to check that?


> Sorry for the problems....
> 
> I wonder if it's a missing dependency that the tests forget to
> account for...  Can they run the tests individually using "prove"
> and show more output?
> 
>    e.g.: make && prove -bvw t/nntpd.t
> 
> Also, "./lei.sh sucks"  will dump the relevant deps+versions
> (either Inline::C or Socket::MsgHdr is required for lei to work)

Here's what this gives me:
---
lei 1.7.0
perl 5.34.0 / Linux 5.10.81 / x86_64 ptrsize=8 nproc=4
git 2.33.1 / JSON::PP 4.06
SQLite 3.32.3, DBI 1.643, DBD::SQLite 1.66
Xapian 1.4.18, bindings: Search::Xapian 1.2.25.4
public-inbox blob OIDs of loaded features:
  2c9c4395c02edbb86683573612f5b454115ce719 PublicInbox/Address.pm
  0f002e5e62c260fbb5078bbbb25c67b1468fbbec PublicInbox/Config.pm
  bacc9cdda12498abbb0ada5d2a2e2faec10190f2 PublicInbox/ContentHash.pm
  bf8c4466218a37a43688aaaca2b063c65e98c86e PublicInbox/DS.pm
  9206da9cb710186462ffefd10cb4af0764f7e615 PublicInbox/DirIdle.pm
  485f637a3e7b41a9117cb37a9acfd8e7649dadfa PublicInbox/Eml.pm
  80fc7364fc9a1943759585c30487ab0c5d36ca0c PublicInbox/EmlContentFoo.pm
  309f80dbfcf001e51f130cddee1a14ee38303dd3 PublicInbox/Git.pm
  3e299448b334629fb6427e7df02976381ec19242 PublicInbox/IPC.pm
  60ce7b66419b3ee0e9ad2dca4b93644497539378 PublicInbox/Import.pm
  ffe26a44ab3d9e38d46447fd69543e0a9d4e5c8d PublicInbox/In2Tie.pm
  1579d500136a8f814f532275f486bc117c3e0441 PublicInbox/Inbox.pm
  887025de5dedb608576b2263b4f20c0596fce8e5 PublicInbox/LEI.pm
  30bb1a4579c74d8245d1eec7b66b9687bd526e71 PublicInbox/LeiExternal.pm
  fa0e78667b3b051cdf3dda96d0b8fba24e1f19f2 PublicInbox/LeiHelp.pm
  352ee60131aaf6bc9baabfbd4ae735c4a0f06568 PublicInbox/LeiQuery.pm
  8e866fc96655a9dd5a6342de43217da0a57e14f5 PublicInbox/LeiSucks.pm
  7cedc3493f872df866755e1c2c9d5d545df7c319 PublicInbox/Listener.pm
  0ee2a8bd60bd964a13c0c24f958f43e0ca9a6b5b PublicInbox/Lock.pm
  f82194a347b867aa22d416b75576e3ac624527ee PublicInbox/MDA.pm
  35b517e09f5d12ff264bcd0bd8afe77f1b96e69d PublicInbox/MID.pm
  dd28417b70c043b092f231147d82580ba94e31cf PublicInbox/MsgIter.pm
  5ee087fd50fea18612798d094046b4ada12d16e1 PublicInbox/MsgTime.pm
  615bc450998beea1e82606db35c0d456450d966b PublicInbox/OnDestroy.pm
  30ad949dd027153f30835f928c962d00e5d9f82a PublicInbox/Over.pm
  4c434566d31f90104d921b76adf1844a9d6aefde PublicInbox/PktOp.pm
  97e9c268f8d1e91aa0f8c1225112dc42cd623768 PublicInbox/ProcessPipe.pm
  523003b3c269ae42e9ee210e91415b2846735daa PublicInbox/Search.pm
  81e5a1b1dd88e99d25bf37aadbb1f520e8a6503f PublicInbox/Sigfd.pm
  260ce6bb065e930adfd9030d50f5a06359e809ce PublicInbox/Smsg.pm
  6ca1ca2a0be3538b3cb9dc663422698b6b94952b PublicInbox/Spawn.pm
  c00385b94db84b63facf7a8d57296ac76b3b1421 PublicInbox/Syscall.pm
  3040dd77d457d02f4517088edcad4f4cf858228f PublicInbox/Tmpfile.pm
  950bd17052a569b7e6792f875791d801525d821d PublicInbox/WQWorker.pm
Let us know how it sucks!  Please include the above and any other
relevant information when sending plain-text mail to us at:
meta@public-inbox.org -- archives: https://public-inbox.org/meta/
---

> > Nix being Nix we can assume the exact same code is used for all,
> > but our systems are different (eg. CPU(s), filesystem(s), etc.)
> 
> Perhaps you guys can compare installed package lists easily and
> help narrow it down?  There's a lot of optional stuff in
> public-inbox since we try to support some old systems and users
> who don't want extra dependencies; but yes, it gets difficult to
> support so many possible combinations.

That's the thing with nixos, in theory the package list really should be
identical, so we're down to environmental differences (like me and btrfs
present in /proc/self/mounts).
The build happens in a chroot with just the "input" packages present
(which also incidentally makes it somewhat harder to debug, I couldn't
reproduce my error manually...).


> > One reviewer and a bot fail with:
> > > t/lei_to_mail.t .............. 1/? Use of uninitialized value in open at t/lei_to_mail.t line 263.
> > > Bailout called.  Further testing stopped:  No such file or directory
> > > FAILED--Further testing stopped: No such file or directory

(waiting to see if the ones who produce this can give more details about
their environment)


Thanks,
-- 
Dominique Martinet | Asmadeus

  reply	other threads:[~2021-12-08 10:56 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-08  1:07 Test failures with 1.7.0 Julien Moutinho
2021-12-08  4:08 ` Eric Wong
2021-12-08 10:56   ` Dominique Martinet [this message]
2021-12-08 18:22     ` [PATCH] nodatacow: quiet chattr errors [was: Test failures with 1.7.0] Eric Wong
2021-12-08 21:14       ` Dominique Martinet
2021-12-08 22:01         ` Dominique Martinet
2022-01-30 21:49           ` Eric Wong
2022-01-30 23:18             ` Dominique Martinet
2022-01-31  2:03               ` Eric Wong
2022-01-31  3:34                 ` Dominique Martinet
2022-02-01  1:27                   ` Eric Wong
2021-12-09  1:37     ` Test failures with 1.7.0 Julien Moutinho
2021-12-09  2:53       ` Dominique Martinet
2022-02-01  9:37         ` Eric Wong
2022-02-01 23:27       ` FD_CLOEXEC w/ nix-shell [was: Test failures with 1.7.0] Eric Wong
2022-02-02  0:23         ` Dominique Martinet
2022-02-02  2:11           ` Dominique Martinet
2022-02-01 23:34       ` [PATCH] test_lei: use consistent locale for error messages Eric Wong
2022-02-17 21:02       ` [PATCH] t/lei-sigpipe: attempt to improve diagnostics for stuck test Eric Wong
2022-02-20  1:38         ` Julien Moutinho
2022-02-22  6:44           ` Eric Wong
2022-02-27  4:15             ` Julien Moutinho
2022-02-27  6:41               ` Julien Moutinho
2022-02-27  7:23                 ` Dominique Martinet
2022-02-27  8:04                   ` Julien Moutinho
2022-02-27 11:17                     ` [PATCH] t/lei-sigpipe: ensure SIGPIPE is unblocked for this test Eric Wong
2022-03-11 10:42                       ` [PATCH] t/lei-sigpipe.t: ensure SIGPIPE is not ignored instead of not blocked Julien Moutinho
2022-03-14 22:14                         ` Eric Wong
2022-03-15  2:56                           ` Julien Moutinho
2022-03-01  2:30   ` Test failures with 1.7.0 Julien Moutinho
2022-03-01  4:05     ` Eric Wong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://public-inbox.org/README

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YbCPWGaJEkV6eWfo@codewreck.org \
    --to=asmadeus@codewreck.org \
    --cc=e@80x24.org \
    --cc=julm+public-inbox@sourcephile.fr \
    --cc=meta@public-inbox.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).