From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <e@80x24.org>
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net
X-Spam-Level: 
X-Spam-ASN:  
X-Spam-Status: No, score=-4.0 required=3.0 tests=ALL_TRUSTED,BAYES_00
	shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2
Received: from localhost (dcvr.yhbt.net [127.0.0.1])
	by dcvr.yhbt.net (Postfix) with ESMTP id 219541F670;
	Sat, 16 Oct 2021 17:03:52 +0000 (UTC)
Date: Sat, 16 Oct 2021 17:03:52 +0000
From: Eric Wong <e@80x24.org>
To: Kyle Meyer <kyle@kyleam.com>
Cc: meta@public-inbox.org
Subject: Re: [PATCH 2/2] doc: lei: add manpages for remaining commands
Message-ID: <20211016170352.GA22949@dcvr>
References: <20211016053944.494064-1-kyle@kyleam.com>
 <20211016053944.494064-3-kyle@kyleam.com>
 <20211016070753.M426387@dcvr>
 <87lf2t0zq2.fsf@kyleam.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <87lf2t0zq2.fsf@kyleam.com>
List-Id: <meta.public-inbox.org>

Kyle Meyer <kyle@kyleam.com> wrote:
> Thanks, sorry about the mix up.

No worries, will push a regen.

> [*] I did run `make check' before sending, and it looks like that also
>     checks MANIFEST _after_ running the test suite.  That didn't help me
>     catch the MANIFEST sorting issue in this case because the test suite
>     is failing on my end.
> 
>     I believe these failures are recent and was planning on looking into
>     them today, either sending a patch or just reporting, depending on
>     whether I could figure out a fix.  Anyway, here they are:
> 
>       t/psgi_multipart_not.t .......
>       ok 1 - use HTTP::Request::Common;
>       ok 2 - use Plack::Test;
>       ok 3 - use PublicInbox::WWW;
>       not ok 4 - /v2test/?q=%22ain't what it used to be%22&x=t
>       not ok 5 - /v2test/?q=%22ain't what it used to be%22&x=t warns
>       Failed 2/5 subtests

The failure is probably caused by
00d5dff2cce9d2c9 (eml: avoid Encode 2.87..3.12 leak, 2021-10-13)
but I can't reproduce it across CentOS 7.x, FreeBSD 11.x, nor
Debian 10 & 11.

Which versions of Encode and Perl are you using?

At least in Debian, libencode-perl is available as a separate package
but it's also part of libperl5.xx (possibly w/ a different version);
only the latter is required for us, but two packages offering
the same thing gets confusing :/

I use: perl -MEncode -E 'say $Encode::VERSION'
to determine which gets loaded.