Arch Linux User Repository

@jshholland Can you try a clean build? I can no longer reproduce the problem on 5.2.1, it's all good on my end.

$ makepkg --version
makepkg (pacman) 5.2.1

According to the pacman NEWS file, the gzip bug was fixed in 5.2.0, but I'm still seeing this same bug.

@UndeadKernel: Ah, figured it out! Eli Schwartz confirmed on IRC that it's a recently-introduced upstream bug: https://git.archlinux.org/pacman.git/commit/?id=99c5809bbf01725829ce67458565b46bce32eaa9

It's fixed in pacman-git but hasn't been released in pacman yet. Once it's released, it will restore the old auto-extraction behaviour.

Given that circumstance, I'm not gonna push a hotfix, since I'd have to just revert it soon once Pacman is updated

@UndeadKernel: Hmm, you're right, something has clearly changed in makepkg, this exact PKGBUILD (plus leela-zero-git's almost-identical one) definitely used to work as-is a few weeks ago.

I think makepkg used to implicitly extract *.gz resources and now it doesn't anymore. I'll try to get to the bottom of this before just pushing out a hotfix.

I'm observing an error while installing:

==> Starting package()...
install: cannot stat '/home/boy/.cache/yay/leela-zero/src/weights.txt': No such file or directory
==> ERROR: A failure occurred in package().
    Aborting...
Error making: leela-zero

I don't see anywhere in the PKGBUILD where the weights.txt.gz file is uncompressed. Am I missing something obvious?

@janwil You will have more luck posting your findings so far in the ticket linked by @Liso; it's likely this is just a bug with Leela-Zero itself, not this particular package of it.

(You might also want to give leela-zero-git a try, just in case whatever the problem is has already been fixed. Leela-Zero is very slow to tag actual releases, so this is not too unlikely)

Hope that helps!

@Liso, I can confirm that my results of 'coredump gdb' and 'where' are similar to yours. What does this mean now and what can I do to fix this? Is there anything I can do in the first place? I am unfortunately not very good at debugging and fixing C++ myself :(

Best regards, Jan

Now I found that it is same as this issue https://github.com/leela-zero/leela-zero/issues/2438

@janwil , it seems I have same problem (in my case AMD Radeon RX 550X).

If I do coredumpctl list I get

Sun 2019-07-28 17:00:46 CEST 19240 1000 1000 11 present /var/tmp/pamac-build-i/leela-zero/src/leela-zero/build/tests

Then you could use "exe" to investigate problem:

coredumpctl gdb /var/tmp/pamac-build-i/leela-zero/src/leela-zero/build/tests

then you could write where and see stack. I got this:

(gdb) where

0 0x0000000000000000 in ?? ()

1 0x00007f90acde36a2 in ?? () from /usr/lib/libMesaOpenCL.so.1

2 0x00007f90acdd4e3f in ?? () from /usr/lib/libMesaOpenCL.so.1

3 0x00007f90acdd5a13 in ?? () from /usr/lib/libMesaOpenCL.so.1

4 0x00007f90acdd6291 in ?? () from /usr/lib/libMesaOpenCL.so.1

5 0x00007f90acdd31a5 in ?? () from /usr/lib/libMesaOpenCL.so.1

6 0x00007f90acdd0cde in ?? () from /usr/lib/libMesaOpenCL.so.1

7 0x000055c2ad0bf72b in cl::CommandQueue::enqueueWriteBuffer (blocking=0, offset=0, events=0x0, event=0x0, ptr=<optimized out>, size=147456, buffer=..., this=<synthetic pointer>)

at /var/tmp/pamac-build-i/leela-zero/src/leela-zero/src/CL/cl2.hpp:7166

8 Tuner<half_float::half>::tune_sgemmabi:cxx11 (this=0x7ffc804f9b50, m=8, n=25, k=8, batch_size=36, runs=<optimized out>)

at /var/tmp/pamac-build-i/leela-zero/src/leela-zero/src/Tuner.cpp:491

9 0x000055c2ad0c0c3f in Tuner<half_float::half>::load_sgemm_tunersabi:cxx11 (this=0x7ffc804f9b50, m=8, n=25, k=8, batch_size=36)

at /usr/include/c++/9.1.0/ext/new_allocator.h:89

10 0x000055c2ad0d6d18 in OpenCL<half_float::half>::initialize (this=0x55c2ae675570, channels=8, batch_size=1) at /var/tmp/pamac-build-i/leela-zero/src/leela-zero/src/Tuner.cpp:722

11 0x000055c2ad0d738e in OpenCLScheduler<half_float::half>::initialize (this=0x55c2ae675490, channels=8) at /usr/include/c++/9.1.0/bits/unique_ptr.h:357

12 0x000055c2ad0eaacb in Network::init_net (this=0x7f90ace86010, channels=8, pipe=...) at /usr/include/c++/9.1.0/bits/unique_ptr.h:357

13 0x000055c2ad0f2c64 in Network::select_precision (this=0x7f90ace86010, channels=8) at /usr/include/c++/9.1.0/bits/move.h:74

14 0x000055c2ad0f35a8 in Network::initialize (this=0x7f90ace86010, playouts=<optimized out>, weightsfile=...) at /var/tmp/pamac-build-i/leela-zero/src/leela-zero/src/Network.cpp:573

15 0x000055c2ad1245a5 in LeelaEnv::SetUp (this=<optimized out>) at /var/tmp/pamac-build-i/leela-zero/src/leela-zero/src/tests/gtests.cpp:87

16 0x000055c2ad1470d1 in testing::internal::UnitTestImpl::RunAllTests() ()

17 0x000055c2ad15255d in bool testing::internal::HandleExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool>(testing::internal::UnitTestImpl, bool (testing::internal::UnitTestImpl::)(), char const*) ()

18 0x000055c2ad147562 in testing::UnitTest::Run() ()

19 0x000055c2ad07e8f6 in main () at /usr/include/c++/9.1.0/ext/new_allocator.h:89

(gdb)

Do you have same problem?