1.11.1 release seems broken (edit: fixed now)

[lazka]

The version released today fails when called like ninja --version and doesn't have a zero return code.

$ ninja --version
1.11.1.git.kitware.jobserver-1
$ echo $? 
245

This makes for example meson fail which calls ninja --version to detect the ninja version.

$ meson _build
The Meson build system
[...]
ERROR: Could not detect Ninja v1.8.2 or newer

This is on Ubuntu 22.04 using Python 3.10.7

[lazka]

Just calling ninja or ninja --help is also broken, both exit with an error code.

[mayeut]

Thanks for the report. Don't know how it passed all tests in the first place because the simple reproducer indeed shows the failure.
@henryiii, @jcfr, can one of you yank the release on PyPI please. I can't do that.

[henryiii]

I do not have manage permissions for either cmake or ninja. Only @jcfr or @thewtex. I really think yank permissions should match release permissions. Delete, sure, but yanking is non-destructive.

Edit: if it's only a manylinux1 problem, the whole release doesn't need yanking. Just the manylinux1 file (which could maybe just be deleted?)

[henryiii]

We should make sure we check the return code in the tests. Edit: it looks like we do...

FYI, this is okay on macOS.

[henryiii]

If you run it without the Python wrapper, it's:

root@87dda27e737d:/# usr/local/lib/python3.10/dist-packages/ninja/data/bin/ninja --version
1.11.1.git.kitware.jobserver-1
Segmentation fault

The released binary seems fine.

[henryiii]

I think I'll have a rebuild out for the 1.11.1 issue soon. Looks like ninja 1.11.1 isn't compatible with manylinux1. Though why is it passing tests? Anyway, manylinux2010 builds don't suffer the same problem, and I can upload 2010 builds to the same release. ;)

[eli-schwartz]

Isn't manylinux1 vs manylinux2010 just about which version of glibc and libstdc++ you build against? Seems bizarre that ninja would be incompatible with anything there. It might fail to run due to missing symbols on too-old systems, but that should not manifest as successfully printing the version, then failing during cleanup+exit.

[henryiii]

It's segfaulting. It seems to get prettied up a bit by the python subprocess call. I locally rebuilt both manylinux1 and 2010 versions, and only the manylinux1 segfaults. I've uploaded a 2010 version, let's see if that helps - it shouldn't hurt anything, other than the tiny bit of wasted space.

It should have failed the tests, though I think those also run in a manylinux1 container.

I'd say it seems equally unlikely that the ninja developers would still be testing on CentOS, an operating system that has been end-of-life for something like five years.

Technically manylinux1 and even manylinux2010 are also EoL, though due to old pip versions running around, they still are useful to ship. CentOS 8 shipped with pip 9. 🤦