Eric Wong wrote:
> +++ b/t/cindex.t
> @@ -210,7 +210,7 @@ EOM
> my $cmd = [ qw(-cindex -u --all --associate -d), "$tmp/ext",
> '-I', $basic->{inboxdir} ];
> $cidx_out = $cidx_err = '';
> - ok(run_script($cmd, $env, $opt), 'associate w/o search');
> +
These only spring up with libgit2-devel installed, but
3/3 seems important for all users of older Perl in
order to avoid future surprises.
Eric Wong (3):
gcf2client: add alias for PublicInbox::Git::fail
gcf2: fix autodie usage for older Perl
treewide: more autodie safety fixes for older
Ensure we can ->fail properly from other subs we can within
Gcf2Client. This doesn't fix the test failures on CentOS 7.x,
but tries to make it easier to fix underlying problems and
report OOM errors and other things which the test suite doesn't
touch on.
---
lib/PublicInbox/Gcf2Client.pm | 1 +
Avoid mixing autodie use in different scopes since it's likely
to cause problems like it did in Gcf2. While none of these
fix known problems with test cases, it's likely worthwhile to
avoid it anyways to avoid future surprises.
For Process::IO, we'll add some additional tests in t/io.t
to ensure
At least on Perl v5.16.3 on CentOS 7.x, use-ing autodie within
BEGIN {} affects all subroutines in that package, too. So just
use autodie at the top-level and rely on CORE::* and try_cat
to handle cases where autodie isn't desired.
---
lib/PublicInbox/Gcf2.pm | 13 ++---
1 file changed,
Konstantin Ryabitsev wrote:
> t/gcf2_client.t .. 1/? Can't locate object method "fail" via
> package "PublicInbox::Gcf2Client" at
> /home/mricon/public-inbox-test/blib/lib/PublicInbox/Git.pm line 269.
> (in cleanup) Can't locate object method "fail" via package
>
On Wed, Nov 15, 2023 at 01:06:42AM +, Eric Wong wrote:
> Konstantin Ryabitsev wrote:
> > Looks like the last time I am able to successfully run "make test" is before
> > this commit:
> >
> > b231d91f42d791becf7b6861e723833d71e73237 is the first bad commit
> >
> > The error I start
Konstantin Ryabitsev wrote:
> There are two sources of potential discrepancy:
>
> - differences in CPAN module versions I have installed
> - different git or xapian14 versions
Could also be CPU count or CPU speeds since IPC bugs are
sensitive to that. That said, I can't get cindex.t to fail
Konstantin Ryabitsev wrote:
> Looks like the last time I am able to successfully run "make test" is before
> this commit:
>
> b231d91f42d791becf7b6861e723833d71e73237 is the first bad commit
>
> The error I start getting after this commit is:
>
> t/extsearch.t 160/?
> #
Unlike modern Perls, Perl 5.16.3 on CentOS doesn't accept
negative string signals like "-TERM" .
This only became a problem since commit b231d91f42d7
(treewide: enable warnings in all exec-ed processes)
made our code stricter by enabling more warnings.
In both cases, the kill is probably
Neither of these fix the t/cindex.t stuck problem Konstantin is
encountering, though...
Eric Wong (2):
lei: use -signal numbers for old Perl
t/lei-import: account for more verbose error
lib/PublicInbox/LEI.pm| 2 +-
lib/PublicInbox/LeiXSearch.pm | 2 +-
t/lei-import.t
Perl 5.16.3 on CentOS seems more verbose in one of the EIO
tests. Relax the regexp so we can account for extra errors
reported by Perl.
---
t/lei-import.t | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/lei-import.t b/t/lei-import.t
index bd562617..b4446b56 100644
---
On Tue, Nov 14, 2023 at 06:51:00PM -0500, Konstantin Ryabitsev wrote:
> On Tue, Nov 14, 2023 at 11:46:20PM +, Eric Wong wrote:
> > My, that's a lot of pipes...
> >
> > I should've told you to try this debug patch earlier, but this
> > might help... (and our test suite should really be able
On Tue, Nov 14, 2023 at 11:46:20PM +, Eric Wong wrote:
> My, that's a lot of pipes...
>
> I should've told you to try this debug patch earlier, but this
> might help... (and our test suite should really be able to
> watch messages like this while capturing)
Will try this shorty -- currently
Konstantin Ryabitsev wrote:
> On Tue, Nov 14, 2023 at 10:46:57PM +, Eric Wong wrote:
> > > I can't do +E because that's not available to me under CentOS7 (I can't
> > > wait
> > > until we move on, but just when we think the yak is fully shaved, we find
> > > more
> > > clumps of thick fur
On Tue, Nov 14, 2023 at 10:46:57PM +, Eric Wong wrote:
> > I can't do +E because that's not available to me under CentOS7 (I can't wait
> > until we move on, but just when we think the yak is fully shaved, we find
> > more
> > clumps of thick fur we hadn't considered). Is the output of the
Konstantin Ryabitsev wrote:
> On Tue, Nov 14, 2023 at 10:16:53PM +, Eric Wong wrote:
> > Konstantin Ryabitsev wrote:
> > > └─-cindex -u --al,4432
> > > ├─cidx shard[0],4646
> > > └─cidx shard[1],4647
> > >
> > > Anything I can do to figure out why this is
On Tue, Nov 14, 2023 at 10:16:53PM +, Eric Wong wrote:
> Konstantin Ryabitsev wrote:
> > └─-cindex -u --al,4432
> > ├─cidx shard[0],4646
> > └─cidx shard[1],4647
> >
> > Anything I can do to figure out why this is happening?
>
> You can show me strace and
Konstantin Ryabitsev wrote:
> └─-cindex -u --al,4432
> ├─cidx shard[0],4646
> └─cidx shard[1],4647
>
> Anything I can do to figure out why this is happening?
You can show me strace and lsof +E of the processes (any other
processes (join|sort|awk|perl)?). This
Eric:
I'm trying to have tests pass on CentOS7 with the current master and I'm
apparently not able to get past the "associate w/o search" test.
When I run `prove -bvw t/cindex.t` I get to:
ok 76 - xcpdb compact
and then it just sits there. If I look at the process table, I can see that
the
Thanks, pushed as commit 58e6ee9df4f74b1078541c8924cf2918ceec0765
il "no strace --version: $v";
+ xbail "no strace -V: $v";
eval("v$1");
};
$ver ge v4.16 or skip "$cmd too old for syscall injection (".
---
base-commit: 1f3fdeee8919d06b9293d34a2446a61cba730a0c
cha
Noticed while working on another feature...
---
lib/PublicInbox/CodeSearchIdx.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/PublicInbox/CodeSearchIdx.pm b/lib/PublicInbox/CodeSearchIdx.pm
index 4ed5ea64..9ceef16c 100644
--- a/lib/PublicInbox/CodeSearchIdx.pm
+++
Hi Konstantin,
> From: Konstantin Ryabitsev
> Sent: Tuesday, November 14, 2023 4:59 PM
> To: Eric Wong
>
> On Tue, Nov 14, 2023 at 04:36:29PM +, Eric Wong wrote:
> > In any case, kernel.org folks should be able to import missing
> > messages from GNU.org idempotently into lore/qemu-devel
Konstantin Ryabitsev wrote:
> On Tue, Nov 14, 2023 at 04:36:29PM +, Eric Wong wrote:
> > In any case, kernel.org folks should be able to import missing
> > messages from GNU.org idempotently into lore/qemu-devel without
> > having to resend:
> >
> >
On Tue, Nov 14, 2023 at 04:36:29PM +, Eric Wong wrote:
> In any case, kernel.org folks should be able to import missing
> messages from GNU.org idempotently into lore/qemu-devel without
> having to resend:
>
> https://lists.gnu.org/archive/mbox/qemu-devel/2023-10
>
On Tue, Nov 14, 2023 at 04:11:41PM +, Salil Mehta wrote:
> It is not just me there other people (from other organizations CC'ed in this
> mail)
> I requested to check below set of links and they experienced the same behavior
> i.e. except first link no other link opens (ends up in Not Found)
ng kernel.org also missed.
Based on recent messages it was pointing towards towards a local
WWW cache/firewall issue:
https://public-inbox.org/meta/9c354ab0ce1743c4994a57e28e42b...@huawei.com/
https://public-inbox.org/meta/20231114-delectable-fennec-of-unity-8c85bc@nitro/
... but that's clearly not
Noticed while working on another feature...
---
lib/PublicInbox/CodeSearchIdx.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/PublicInbox/CodeSearchIdx.pm b/lib/PublicInbox/CodeSearchIdx.pm
index 4ed5ea64..9ceef16c 100644
--- a/lib/PublicInbox/CodeSearchIdx.pm
+++
Hi Konstantin
> From: Konstantin Ryabitsev
> Sent: Tuesday, November 14, 2023 3:11 PM
> To: Salil Mehta
>
> On Tue, Nov 14, 2023 at 11:03:38AM +, Salil Mehta wrote:
> > I have cross confirmed the behavior with other people across companies and
> > all of them are having issues in viewing
Salil Mehta wrote:
> I have cross confirmed the behavior with other people across companies and
> all of them are having issues in viewing above links. Surprising part is
> these were present at the first instance when the review comments were floated
> by Igor - I can assure you that.
Does my
On Tue, Nov 14, 2023 at 11:03:38AM +, Salil Mehta wrote:
> I have cross confirmed the behavior with other people across companies and
> all of them are having issues in viewing above links. Surprising part is
> these were present at the first instance when the review comments were floated
> by
Hi Konstantin,
> From: Salil Mehta
> Sent: Monday, November 13, 2023 10:26 PM
> To: 'Konstantin Ryabitsev'
>
> > From: Konstantin Ryabitsev
> > Sent: Monday, November 13, 2023 8:44 PM
> > To: Salil Mehta
> >
> > On Mon, Nov 13, 2023 at 07:39:21PM +, Salil Mehta wrote:
> > > > When you go
33 matches
Mail list logo
