On Tue, Mar 10, 2026 at 11:32 AM Michael J Gruber <[email protected]> wrote:
> Am Di., 10. März 2026 um 10:43 Uhr schrieb Nikita Popov <[email protected] > >: > > > > > > On Mon, Mar 9, 2026 at 1:39 PM Michael J Gruber <[email protected]> > wrote: > >> > >> Hi there > >> > >> Apparently, LLVM changed something in the python API even though their > >> release notes seem to claim otherwise. Here's a failed scratch build > >> of a rawhide commit which worked before LLVM 22 landed > >> > >> https://koji.fedoraproject.org/koji/taskinfo?taskID=143160960 > >> > >> Builds against other Fedoras work (until LLVM 22 lands there). > >> > >> This is unfortunate at this point in the release cycle. It's made > >> worse by the fact that we do not ship python-clang compat packages. Is > >> there a particular reason why not? > > > > > > I believe the reason we don't ship python-clang in compat packages is > that we don't know how to do that correctly. Normally, all the compat > packages are shipped in /usr/lib64/llvmNN, so that would be something like > /usr/lib64/llvmNN/lib/python3.14/site-packages/clang for python-clang. But > I assume that wouldn't actually work because that's not the location where > Python packages are expected to be located? > > > > I tried to look at what some compat packages from the Python ecosystem > do. Looking at a package like python3-sqlalchemy1.4 it seems to just ship > the files in the same location as the normal package and conflicts with it. > This seems very fishy to me, and not really viable for us (as we'd have to > conflict across all present and future compat packages). > > > > First of all, those breakages should be caught before merging LLVM 22 > between two freezes. Everything else is work-arounds. Indeed, if > there's clang21 but no python3-clang21 then testing packages which > build require python-clang is much more important than testing those > which BR clang. > LLVM updates generally rely on packages that are not compatible with the latest version to switch to the compat packages instead. The fact that this does not work for packages with python-clang BuildRequires wasn't on our radar -- I think this just never came up in the past. Probably a combination of few packages using python-clang, and those bindings being relatively stable. Ideally we'll address this by shipping an additional compat package, but testing these python-clang BR packages in advance would be a fallback if that's not possible. > As for the path: It depends on the goal - (when) does it make sense to > have different LLVM versions installed in parallel? If the answer is > "no/never" (which is the answer from a build requires perspective), > then the standard path and conflicts are appropriate. > > If it's rather something to be installed on top and used on a case by > case basis, then a package specific path seems appropriate. Users > would need to set their PYTHONPATH to prefer those specific paths, and > probably adjust other env variables or build scripts so that a > versioned clang is used instead of the unversioned one. > > One could also rename the python package (module) itself and put it in > the standard path, but this would require adjusting a lot of import > statements (import foo21 as foo and such). > > In summary, I'd rather know what changed and how to fix it ;-) I took a quick look at this, the key change is the second bullet point in https://releases.llvm.org/22.1.0/tools/clang/docs/ReleaseNotes.html#clang-python-bindings-potentially-breaking-changes, the removal of elaborated types. The mupdf wrap script uses ELABORATED in some places, but there's also some other consequences as a result of that. In particular, some places that use get_declaration() now get a forward declaration, rather than the definition they're looking for. The following patch fixes the *first* error that shows up, but it's not the only one. diff --git a/scripts/wrap/parse.py b/scripts/wrap/parse.py index c3bd1278c..f0fe0c5f5 100644 --- a/scripts/wrap/parse.py +++ b/scripts/wrap/parse.py @@ -251,8 +251,8 @@ def has_refs( tu, type_): if keep_fn_cursor: if verbose: jlib.log( 'There is a keep() fn for this type so it uses reference counting: {keep_name=}') - base_type_cursor = get_base_type( type_).get_declaration() - if base_type_cursor.is_definition(): + base_type_cursor = get_base_type( type_).get_declaration().get_definition() + if base_type_cursor is not None: if verbose: jlib.log( 'Type definition is available so we look for .refs member: {key=} {type_.spelling=} {fileline(base_type_cursor)=}') if verbose: @@ -289,7 +289,7 @@ def has_refs( tu, type_): ' declaration, so have to hard-code the size and offset' ' of the refs member.' ) - if base_type_cursor.is_definition(): + if base_type_cursor is not None: if key == 'pdf_document': ret = 'super.refs', 32 elif key == 'pdf_page': -- 2.53.0
-- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
