Thegeninfo error thatappears in theubuntu-24.04 build logs from commit2dd9560:

geninfo: ERROR: "/opt/hostedtoolcache/Python/3.12.9/x64/lib/python3.12/site-packages/pybind11/include/pybind11/pytypes.h":1562: mismatched exception tag for id 1, 1: '1' -> '0'

..seems to relate to this line of code:https://github.com/pybind/pybind11/blob/a2e59f0e7065404b44dfe92a28aca47ba1378dc4/include/pybind11/pytypes.h#L1562

From what I gather from starting to read a separate-but-similar discussion thread inlinux-test-project/lcov#209, this means that there's a mismatch betweenlcov's expectation about exceptions in the code during coverage testing.

It looks like the verion of gcov has gone from 11 -> 13 as well.

Perlinux-test-project/lcov#209 (comment) I suspect that we are seeing the lines from the pybind11 headers showing up sometimes in exceptions and sometimes not hence confusing the tools. I suspect we should go the route of flagging these as ignorable?

It looks like the verion of gcov has gone from 11 -> 13 as well.

Perlinux-test-project/lcov#209 (comment) I suspect that we are seeing the lines from the pybind11 headers showing up sometimes in exceptions and sometimes not hence confusing the tools. I suspect we should go the route of flagging these as ignorable?

Thanks - possibly, yep. I've been trying to figure out what the cause of that is. As best I can tell, it's a string conversion (CVT) macro inpybind11 that is emitting the error -- and it's within apy::str class declared by that library. I have aguess that it may be atypecast topy::str where the mismatch occurs -- but I haven't experimented with that yet.

I did buildpybind11 locally with coverage enabled, ran thepytest suite for it, and those didnot result in anlcov mismatch error -- so there may be a coverage gap that we can report upstream to them if we can identify it.

It looks like the verion of gcov has gone from 11 -> 13 as well.

Perlinux-test-project/lcov#209 (comment) I suspect that we are seeing the lines from the pybind11 headers showing up sometimes in exceptions and sometimes not hence confusing the tools. I suspect we should go the route of flagging these as ignorable?

I've opened a discussion thread (a request for assistance, really) about this at:pybind/pybind11#5573

I think I will go ahead and ignore those warnings/errors, at least in the short term. The main reason for this is that I would like to merge this -- adding additional test coverage -- before removing Ubuntu 20.04 from the test mix to resolve#29766.

Note: my updated understanding from therelevantlcov manual section is that mentioning an error-name (e.g.mismatch) a single time (as opposed to repeated twice or more) in the--ignore-errors list means that corresponding errors are downgraded towarning-level -- so they should still be visible, without failing the build.

I've a local rebase/squash of these changes prepared, and can push that soon, if preferred. There were a few details in some of the interim commits - particularly the GLESv2 requirement if we want to enable GTK4 - that could be relevant for easier inspection, though.

I've a local rebase/squash of these changes prepared, and can push that soon, if preferred. There were a few details in some of the interim commits - particularly the GLESv2 requirement if we want to enable GTK4 - that could be relevant for easier inspection, though.

(clarification: by this I mean that the interim commits are slightly easier to inspect during code review if not replaced by force-pushes; in this case I would prefer to squash the commits before merge)

I do not understand the circleci error. It looks like it is trying to run on the branch from@jayaddison 's account rather than on the PR from the mpl org. We should not hold merging on that.

Thanks@tacaswell - that has confused me slightly too; I don't have a CircleCI account.