Bug 1184920

I have grepped the build logs for openSUSE:Backports:SLE-15-SP3
and found 19 packages using the llvm-7 or llvm-devel-7 or clang-devel-7 metapackage

armagetron autofdo bat blender cilium darktable gedit-code-assistance gnustep-libobjc2 icecream kdevelop5 libclc mk-configure OpenShadingLanguage parsec pijul rstudio rtags sparse tvm

But there are 148 overall pulling in llvm7 or clang7 some way
e.g. bitcoin is such an example

For gnustep-libobjc2 that also includes a llvm regression for bug 1067478

(In reply to Bernhard Wiedemann from comment #1)
> I have grepped the build logs for openSUSE:Backports:SLE-15-SP3
> and found 19 packages using the llvm-7 or llvm-devel-7 or clang-devel-7
> metapackage
Thanks, I assume you mean llvm version 7?

Let's go through them as good as I can:

- LLVM as code generation: blender (probably GPU targets, maybe also CPU), cilium (BPF), OpenShadingLanguage (GPU targets), tvm.
- Clang libraries for parsing/indexing/completion: gedit-code-assistance, kdevelop5, rstudio, rtags, sparse.
- Just for the build: armagetron, darktable (test compiling OpenCL programs), gnustep-libobjc2, libclc (resulting package is LLVM IR), mk-configure.
- Special: icecream (for rewriting includes).
- Unclear to me: autofdo, bat, parsec, pijul.

The first category is hard to estimate. The backends have of course generally improved, though sometimes with compile time regressions. (Optimizing more seems to take longer unsurprisingly.)

In the second category there have of course also been improvements here and there, but most noticeable will be that newer Clangs have much better C++20 support. (https://clang.llvm.org/cxx_status.html)

Put the other way around: shipping an older Clang might be very visible to some users because their code parsing tool/IDE doesn't understand their code any longer.

In the third category it will likely not change much. (Perhaps the compiled binaries are a bit faster, but they should be functionally identical.)

> But there are 148 overall pulling in llvm7 or clang7 some way
> e.g. bitcoin is such an example
It could be that some packages are transitively using it without explicitly declaring the dependency. That's hard to tell.

So I have opened https://build.opensuse.org/request/show/887102, let's see where this goes. If it's really not possible, I guess it'll get rejected.

Hello  we want to update llvm ideally in SP3:Update prior SP3 GA.
Please avoid forking the package in Leap 15.3 itself.

Thank you

I did open internal feature tracker:

internal: https://jira.suse.com/browse/SLE-17825
public: https://jira.suse.com/browse/OPENSUSE-24  (requires jira.suse.com account)
https://en.opensuse.org/Portal:Jump/Policy/CommunitySLEChangeRequests#Weekly_reviews_of_open_features

It's bit unfortunate that the issue was found now.
We'll consider other options prior e.g. forking the package in Leap

I'm still thinking whether migration scenario could not be solved via openSUSE-release package or adding llvm9 to patterns.

and perhaps followed with release notes entry

(In reply to Lubos Kocman from comment #7)
> I'm still thinking whether migration scenario could not be solved via
> openSUSE-release package or adding llvm9 to patterns.

The problem here is which llvm version will be pulled via llvm meta package ie. when BuildRequires/Rquires: llvm/clang/llvm-devel, I can't see anything matter to the release package or patterns

(In reply to Lubos Kocman from comment #6)
> It's bit unfortunate that the issue was found now.
We did find it a while ago, but I didn't know where to raise it.

(In reply to Lubos Kocman from comment #7)
> ... or adding llvm9 to patterns.
That would get rid of the regression, but I'd actually go with llvm11 because the assumption is that the metapackage always points to the latest version.

(In reply to Max Lin from comment #9)
> The problem here is which llvm version will be pulled via llvm meta package
> ie. when BuildRequires/Rquires: llvm/clang/llvm-devel, I can't see anything
> matter to the release package or patterns
Exactly, this is mostly about build dependencies. Users can always install whichever version of clang/llvm or the devel packages they want, but if another tool is built against an older llvm they can't change that.

Hmm, seems the change was already let in. Not sure if intentional.

I had a look at the fallout. Two packages fail to build, two are unresolvable.

* Cilium is running into bug 1178241. Should be an easy fix.
* OpenShadingLanguage is using -std=c++11, but LLVM needs c++14 now. Also easy.
* kdevelop5 and python3-pyside2 are unresolvable because libqt5-qttools-doc requires clang7, which conflicts with (some) newer Clangs in SLE.

The last issue is due to clang containing the so called "builtin headers" before I moved them to libclang in https://build.opensuse.org/request/show/684104, but this change seems to have not made it to SLE. So I think I'll have to poke the Qt people to update LLVM there or relax the Requires.

(In reply to Aaron Puchert from comment #11)
> * Cilium is running into bug 1178241. Should be an easy fix.
Reopened the bug. There is no separate patch, maintainer just updated and that fixed it. Either an update is in order or the patch can be ported back.

> * OpenShadingLanguage is using -std=c++11, but LLVM needs c++14 now. Also
> easy.
Opened bug 1185204.

> * kdevelop5 and python3-pyside2 are unresolvable because libqt5-qttools-doc
> requires clang7, which conflicts with (some) newer Clangs in SLE.
Opened bug 1185203.

(In reply to Aaron Puchert from comment #12)
> (In reply to Aaron Puchert from comment #11)
> > * Cilium is running into bug 1178241. Should be an easy fix.
> Reopened the bug. There is no separate patch, maintainer just updated and
> that fixed it. Either an update is in order or the patch can be ported back.

https://build.opensuse.org/staging_workflows/openSUSE:Backports:SLE-15-SP3/staging_projects/openSUSE:Backports:SLE-15-SP3:Staging:adi:14 should fix it.

> 
> > * OpenShadingLanguage is using -std=c++11, but LLVM needs c++14 now. Also
> > easy.
> Opened bug 1185204.

https://build.opensuse.org/request/show/887527 and https://build.opensuse.org/request/show/887528 fixed it.

> 
> > * kdevelop5 and python3-pyside2 are unresolvable because libqt5-qttools-doc
> > requires clang7, which conflicts with (some) newer Clangs in SLE.
> Opened bug 1185203.

Yes, that is because libqt5-qttools is built in SLE with llvm7. I have asked Antonio have a look these two fails, change buildrequires/requires to the exact llvm* version rather than to use meta package should fix the issue.

With respect to kdevelop5 and python3-pyside2, I've backported some changes to the llvm7 packages from Factory to SUSE:SLE-15-SP1:Update. The main backported fix is the move of header files from the clang7 package to libclang7 (but given that I was backporting changes, I added some other fixes too). With this change, we can remove the "%requires_eq clang7" statement in libqt5-qttools-doc which should fix the build of both kdevelop5 and python3-pyside2. I'll submit everything as soon as it finishes building and I test everything.

(In reply to Max Lin from comment #13)
> (In reply to Aaron Puchert from comment #12)
> > (In reply to Aaron Puchert from comment #11)
> > > * Cilium is running into bug 1178241. Should be an easy fix.
> > Reopened the bug. There is no separate patch, maintainer just updated and
> > that fixed it. Either an update is in order or the patch can be ported back.
> 
> https://build.opensuse.org/staging_workflows/openSUSE:Backports:SLE-15-SP3/
> staging_projects/openSUSE:Backports:SLE-15-SP3:Staging:adi:14 should fix it.
> 
> > 
> > > * OpenShadingLanguage is using -std=c++11, but LLVM needs c++14 now. Also
> > > easy.
> > Opened bug 1185204.
> 
> https://build.opensuse.org/request/show/887527 and
> https://build.opensuse.org/request/show/887528 fixed it.
Thanks, I've closed both bugs accordingly!

(In reply to Antonio Larrosa from comment #14)
> With respect to kdevelop5 and python3-pyside2, I've backported some changes
> to the llvm7 packages from Factory to SUSE:SLE-15-SP1:Update. The main
> backported fix is the move of header files from the clang7 package to
> libclang7 (but given that I was backporting changes, I added some other
> fixes too). With this change, we can remove the "%requires_eq clang7"
> statement in libqt5-qttools-doc which should fix the build of both kdevelop5
> and python3-pyside2. I'll submit everything as soon as it finishes building
> and I test everything.
That seems to be the ideal fix: disentangling libqt5-qttools-doc from clang7 should come with very little risk and allows dependents to go with newer versions of llvm-devel/clang-devel.

https://build.suse.de/request/show/240143 (to SLE-15-SP1 / llvm7)
and
https://build.suse.de/request/show/240144 (to SLE-15-SP2 / libqt5-qttools)

should fix the build of kdevelop5 and python3-pyside2

SUSE-RU-2021:1618-1: An update that has four recommended fixes can now be installed.

Category: recommended (moderate)
Bug References: 1067478,1109367,1145085,1184920
CVE References: 
JIRA References: 
Sources used:
SUSE Linux Enterprise Module for Packagehub Subpackages 15-SP3 (src):    llvm7-7.0.1-3.19.2
SUSE Linux Enterprise Module for Packagehub Subpackages 15-SP2 (src):    llvm7-7.0.1-3.19.2
SUSE Linux Enterprise Module for Development Tools 15-SP3 (src):    llvm7-7.0.1-3.19.2
SUSE Linux Enterprise Module for Development Tools 15-SP2 (src):    llvm7-7.0.1-3.19.2
SUSE Linux Enterprise Module for Desktop Applications 15-SP3 (src):    libqt5-qtdeclarative-5.12.7-4.2.1, libqt5-qttools-5.12.7-3.3.10
SUSE Linux Enterprise Module for Desktop Applications 15-SP2 (src):    libqt5-qtdeclarative-5.12.7-4.2.1, libqt5-qttools-5.12.7-3.3.10
SUSE Linux Enterprise Module for Basesystem 15-SP3 (src):    double-conversion-3.1.5-3.2.1, libqt5-qtdeclarative-5.12.7-4.2.1, llvm7-7.0.1-3.19.2
SUSE Linux Enterprise Module for Basesystem 15-SP2 (src):    double-conversion-3.1.5-3.2.1, libqt5-qtdeclarative-5.12.7-4.2.1, llvm7-7.0.1-3.19.2

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.

Both kdevelop5 and python3-pyside2 are resolvable again and seem to build successfully. Thanks to all involved!

openSUSE-RU-2021:0768-1: An update that has four recommended fixes can now be installed.

Category: recommended (moderate)
Bug References: 1067478,1109367,1145085,1184920
CVE References: 
JIRA References: 
Sources used:
openSUSE Leap 15.2 (src):    double-conversion-3.1.5-lp152.2.3.1, libqt5-qtdeclarative-5.12.7-lp152.3.3.1, libqt5-qttools-5.12.7-lp152.2.3.1