PyPi package of 1.11.1 contains broken binary

[mwichmann]

The PyPi package that just dropped (Nov 5) is definitely not working - blows up all the tests in the SCons CI build that touch Ninja - looks like a segv from the binary (return code -11). x86_64 - my setup here is Fedora 36, on GitHub the runners provision with Ubuntu. If I just go directly to the place the binary sits and try it:

$ ./ninja --version
Segmentation fault (core dumped)

Rolling back the version:

$ ./ninja --version
1.10.2.git.kitware.jobserver-1

This might be related to #2198, or not - decided to file a new issue since that one was closed.

[ibc]

It seems that it just fails on Linux:

ninja 1.11.1 in Linux Debian fails:

ninja-1.11.1-py2.py3-none-manylinux_2_5_x86_64.manylinux1_x86_64.whl

ninja 1.10.2.4 in Linux Debian works:

ninja-1.10.2.4-py2.py3-none-manylinux_2_5_x86_64.manylinux1_x86_64.whl

ninja 1.11.1 in macOS version works:

ninja-1.11.1-py2.py3-none-macosx_10_9_universal2.macosx_10_9_x86_64.macosx_11_0_arm64.macosx_11_0_universal2.whl

[ibc]

From Meson chat:

it's because ninja returns "1.11.1.git.kitware.jobserver-1" for "ninja --version" and meson fails to parse that

[WarrenWeckesser]

I created #2212 a little while ago, but I suspect it is a duplicate of this issue. On my Linux machine, ninja --version doesn't generate a seg. fault, but it returns error code 245. That is enough to break meson, which expects that command to return with error code 0.

[WarrenWeckesser]

Whether or not a fix can be released soon, it would probably be a good idea for the ninja devs to yank the 1.11.1 release from PyPI.

[eli-schwartz]

Note that the ninja project itself doesn't actually release those PyPI binaries, it's done totally unofficially by a third-party project that also adds various patches.

On a fresh clone and build of ninja:

$ ./ninja --version
1.12.0.git
$ echo $?
0

So the bug was most likely introduced downstream...

[eli-schwartz]

Whether or not a fix can be released soon, it would probably be a good idea for the ninja devs to yank the 1.11.1 release from PyPI.

The scikit-build devs, rather.

Who are, indeed, aware of the problem: scikit-build/ninja-python-distributions#157

[mwichmann]

Gack... if you follow the PyPI links it just points here, that's really irritating.

[eli-schwartz]

Gotta love those unofficial distributions.

[WarrenWeckesser]

Thanks @eli-schwartz, I hadn't noticed that.

[henryiii]

It seems to be a problem building ninja on CentOS 5 (manylinux1). Manylinux2010 seems fine (CentOS 6 based).

[henryiii]

Can you retry? I uploaded a manylinux2010 wheel for 64-bit Intel.

This fixed it for me. I haven't seen such a weird failure before, but I'm guessing Ninja doesn't support being built on CentOS 5-like systems anymore.

[henryiii]

it's done totally unofficially by a third-party project that also adds various patches.

We add one patch, which has also been proposed upstream in #1140, and has been in production for 6 years. The Kitware build for it works fine too. It's only a problem building on manylinux1, which has nothing to do with the one patch.

1.11.1 on PyPI is fine now unless you are can't get manylinux2010, say for a very old pip or if you are actually running something older than GLIBC 2.12 (in which case, you likely have other problems).

[henryiii]

if you follow the PyPI links it just points here,

All the links on the sidebar except download point to scikit-build/ninja-python-distributions? Also in the readme?

https://pypi.org/project/ninja

[eli-schwartz]

We add one patch, which has also been proposed upstream in #1140

I don't keep close track of the fork status, but that PR is a patch series, not a patch. :p Anyway, my main point is not that it's a large number of patches but rather that verifying whether the Kitware modifications are the issue is something that requires actual investigation no matter how trivial.

and has been in production for 6 years.

And regularly rebased, too, of course. Which means that the code in production now isn't the code that was in production 6 years ago -- rebasing issues can occur and shouldn't be dismissed out of hand. :)

The Kitware build for it works fine too. It's only a problem building on manylinux1, which has nothing to do with the one patch.

This however is the really useful information at hand, thanks for the status update. ;)

[eli-schwartz]

All the links on the sidebar except download point to scikit-build/ninja-python-distributions? Also in the readme?

As a matter of curiosity, why does the download link point to ninja-build/ninja? It seems like the odd one out here, as technically the only valid download location is PyPI itself (or https://github.com/scikit-build/ninja-python-distributions/releases, depending).

[henryiii]

As a matter of curiosity, why does the download link point to ninja-build/ninja?

I have no idea. I've never understood the point of a download link on PyPI, which is literally a place to download things. ¯\_(ツ)_/¯

Though pointing at https://github.com/scikit-build/ninja-python-distributions/releases seems to make sense.

[henryiii]

shouldn't be dismissed out of hand

Checking the download at https://github.com/scikit-build/ninja-python-distributions/releases was the first thing I tried, actually. :) Though macOS worked, so that meant it was very unlikely to be an issue with the jobserver patch. And yes, there's also a patch that adds the custom version number extension. :) Otherwise, I think it's supposed to be that proposed patch - several commits can be "a patch". Though I don't normally touch ninja-python-distributions that much unless things explode. ;)

[eli-schwartz]

I have no idea. I've never understood the point of a download link on PyPI, which is literally a place to download things. ¯\_(ツ)_/¯

I think this literally exists for absolutely zero reasons other than "before 2014, PyPI didn't have to host release files, you could use it as a metadata hub but then have pip download the source from elsewhere" -- and originally, PyPI literally didn't support hosting release files at all, so external URLs was the only option.

Maybe you should just remove that metadata field altogether?

[mwichmann]

OP swinging back here - apologies, I hadn't realized the PyPI package came from elsewhere - I guess I followed the wrong link from the PyPI page. I see now that the "Source Code" link points off to the scikit-build project, where this has been discussed and fixed. I'm fine with this being closed...

[henryiii]

This is looking like it might be a bug with stdlib++ or with RH's dev tools 2. Manylinux1 with static linking looks like it works. Any way, it's not a bug in ninja itself.

[jhasse]

-> scikit-build/ninja-python-distributions#157