| 24 Apr 2026 |
 matthewcroughan | i.e a toplevel containing it as a closure | 14:12:17 |
| matthewcroughan | * i.e a toplevel containing it in the closure | 14:12:38 |
| matthewcroughan | An app that depends on it was failing due to it, so that's how I tested it | 14:12:51 |
 leona | imo fine to merge it then. (ideally a maintainer approves as always) | 14:13:06 |
| matthewcroughan | It's kind of been sitting there for a bit, I wanted to speed it up, I can almost guarantee that if I do nothing it'll still be there in a week, and nobody will review it. | 14:13:51 |
| matthewcroughan | Which would be fine if it weren't such a trivial change | 14:15:05 |
 Alyssa Ross | I think I need to start being less indirect when I'm writing commetns on your PRs :)
In this case, what I meant is "if you confirm that your best guess is that upstream would probably consider it sensible to list this in their pyproject.toml dependencies, I would merge the PR if it were changed to do that" | 14:16:36 |
| matthewcroughan | Rather my understanding is that this mistake of putting pybind11 in nativeBuildInputs seems to be common throughout nixpkgs | 14:17:16 |
| Alyssa Ross | I wonder why that specifically | 14:17:52 |
| matthewcroughan | and that this is one example of a trivial fix, but I didn't understand what build-system mapped to until you commented | 14:17:56 |
| matthewcroughan | There's another package I can test this on actually | 14:19:36 |
| matthewcroughan | laszip | 14:20:00 |
| matthewcroughan | In that case, pybind11 is in build-system but cross works | 14:20:12 |
| matthewcroughan | Oh, that doesn't seem to contain pybind, is my grep fscked up | 14:21:40 |
| matthewcroughan | Uh no there is pkgs/by-name/la/laszip and pkgs/development/python-modules/laszip | 14:22:28 |
| matthewcroughan | is it considered an issue when there is a by-name package that name clashes with something in a package set? | 14:22:42 |
| matthewcroughan | So ignore what I said.. let me try that again.. | 14:23:01 |
| matthewcroughan | Yes! My assumptions are correct :) | 14:23:40 |
| matthewcroughan | nix-build -A pkgsCross.raspberryPi.python3Packages.laszip fails like:
CMake Error at /nix/store/y4ippakbr3qyk3kv6iskdwix6jha5hbb-python3.13-pybind11-3.0.1/share/cmake/pybind11/FindPythonLibsNew.cmake:224 (message):
Python config failure: Python is 64-bit, chosen compiler is 32-bit
| 14:23:56 |
| matthewcroughan | Or not, seems this has nothing to do with pybind, although it was a good candidate | 14:24:32 |
| matthewcroughan | Oh wait yes it does, pybind is containing the cmake file that is producing that error | 14:25:58 |
| matthewcroughan | if(NOT _PYBIND11_CROSSCOMPILING
AND CMAKE_SIZEOF_VOID_P
AND (NOT "${PYTHON_SIZEOF_VOID_P}" STREQUAL "${CMAKE_SIZEOF_VOID_P}"))
if(PythonLibsNew_FIND_REQUIRED)
math(EXPR _PYTHON_BITS "${PYTHON_SIZEOF_VOID_P} * 8")
math(EXPR _CMAKE_BITS "${CMAKE_SIZEOF_VOID_P} * 8")
message(FATAL_ERROR "Python config failure: Python is ${_PYTHON_BITS}-bit, "
"chosen compiler is ${_CMAKE_BITS}-bit")
endif()
set(PYTHONLIBS_FOUND FALSE)
set(PythonLibsNew_FOUND FALSE)
return()
endif()
| 14:28:54 |
| matthewcroughan | It's checking the bits of the cmake binary | 14:29:16 |
| matthewcroughan | and then saying that this represents the bits of the python interpreter | 14:29:29 |
| matthewcroughan | which is not even remotely true :( | 14:29:32 |
| matthewcroughan | so putting cmake into buildInputs instead of nativeBuildInputs fixed this case | 14:29:49 |
| matthewcroughan | * It's checking the bits of the cmake binary and the python interpreter | 14:31:24 |
| matthewcroughan | * Maybe somehow it gets the path to the wrong python | 14:31:35 |
| matthewcroughan | * whoops | 14:31:41 |
| matthewcroughan | how do you pass the path to all the right things without removing cmake from the nativeBuildInputs though | 14:32:11 |
