Bug 1192429 - Consider bringing newer LLVM to Leap 15.3
Consider bringing newer LLVM to Leap 15.3
Status: RESOLVED FIXED
Classification: openSUSE
Product: openSUSE Distribution
Classification: openSUSE
Component: Development
Leap 15.3
Other Other
: P5 - None : Normal (vote)
: ---
Assigned To: Marcus Meissner
E-mail List
:
Depends on:
Blocks: 1192310
  Show dependency treegraph
 
Reported: 2021-11-07 22:55 UTC by Aaron Puchert
Modified: 2021-12-12 13:55 UTC (History)
5 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Aaron Puchert 2021-11-07 22:55:41 UTC
There were two bugs recently where the topic of a newer LLVM in Leap came up.

* Bug 1192067 wants LLVM 12 for Rust 1.55. Though we could perhaps wait for Rust 1.56 and bring LLVM 13.
* Bug 1192310 wants Clang 12 or newer for Chromium.

Which version should we bring?

* LLVM 12 is at 12.0.1, so it went through some stabilization. It's good enough for Chromium (for now) and exclusively for Rust 1.55. (LLVM 13 won't work there.) It's not awfully recent though.
* LLVM 13 is at 13.0.0, so still somewhat fresh. Though likely it's going to be stable for some time, and we would of course bring 13.0.1 into Leap once it's out. It wouldn't help for Rust 1.55, but 1.56 is already out, as far as I understand, which prefers LLVM 13. (Though perhaps we need to keep 1.55 anyway?)
Comment 1 Aaron Puchert 2021-11-07 23:03:59 UTC
See bug 1179155 for pointers which problems the update might bring. (Duplicate packages?)

We probably don't want to update the llvm metapackage.
Comment 2 William Brown 2021-11-08 00:09:51 UTC
Rust is a bit more flexible here as it has the ability to internally bundle llvm, so I'd say the needs for clang and chromium may be a bit more important to consider.
Comment 3 Marcus Meissner 2021-11-08 08:28:39 UTC
i think a community submisison to openSUSE:Backports:SLE-15-SP3:Update could work.

SLES is probably not eager to have rust12 or rust13 in the sp3 level codebase at this time.
Comment 4 Aaron Puchert 2021-11-09 23:16:20 UTC
(In reply to Marcus Meissner from comment #3)
> i think a community submisison to openSUSE:Backports:SLE-15-SP3:Update could
> work.
True, and the advantage is that we don't necessarily have to carry it over to Leap 15.4 if we have a newer LLVM. SLE is, as I understand it, "append-only".

> SLES is probably not eager to have rust12 or rust13 in the sp3 level
> codebase at this time.
Though if Rust uses it internally, and I understand Rust must be in SLE because Firefox is in SLE, it is effectively part of the distribution. Though of course not as a separately usable component.

Currently I'm tending towards submitting llvm12 to Leap (= Backports), because llvm13 has occasional build failures due to what might be a bug in GCC. (https://bugs.llvm.org/show_bug.cgi?id=50611)
Comment 5 Aaron Puchert 2021-11-19 00:38:39 UTC
(In reply to Aaron Puchert from comment #4)
> Currently I'm tending towards submitting llvm12 to Leap (= Backports),
> because llvm13 has occasional build failures due to what might be a bug in
> GCC. (https://bugs.llvm.org/show_bug.cgi?id=50611)
Decided for that, because of the bug, and because llvm12 from Factory doesn't build a newer clang-tools or libcxx which we don't really want right now. (The standard LLVM version remains at 11 for now, and we'd shadow those packages with an update.)

Request is https://build.opensuse.org/request/show/932377.
Comment 6 Aaron Puchert 2021-11-22 22:53:21 UTC
(In reply to Aaron Puchert from comment #5)
> Request is https://build.opensuse.org/request/show/932377.
Has landed.
Comment 7 Callum Farmer 2021-11-23 19:06:15 UTC
Not landed. Stuck due to SLE conflict.

https://build.opensuse.org/project/show/openSUSE:Maintenance:17181
Comment 8 Aaron Puchert 2021-11-23 23:23:42 UTC
Well, offering a newer version of the same files is pretty much the intention. So perhaps we should mask SUSE_Backports_policy-SLE_conflict in rpmlintrc? Unless I'm missing something, the packages should all have the necessary "Conflicts:".
Comment 9 Richard Biener 2021-11-24 07:20:05 UTC
(In reply to Aaron Puchert from comment #8)
> Well, offering a newer version of the same files is pretty much the
> intention. So perhaps we should mask SUSE_Backports_policy-SLE_conflict in
> rpmlintrc? Unless I'm missing something, the packages should all have the
> necessary "Conflicts:".

I think the policy is quite bogus in this regard - but yes, appropriate
Conflicts should be required.  Maybe that was the intention but the check
was implemented in a too simplistic way.

I can also imagine that we didn't want a Backport to replace supported files
from SLE since that might cause customer confusion since it would invalidate
support for all users of said shared files(?)

Maybe again an exception can be made for replacing files of packages with
lesser support state (whatever that should exactly be ...).  I would consider
all the cited conflicting packages as "unsupported" ...

What's the lifecycle info for llvm5 and llvm7 (and derived packages)?
Comment 10 Marcus Meissner 2021-12-01 13:36:20 UTC
i masked the SLE binary conflict now and pushed it into the qa pipeline.

(it has correct conflicts I hope)

llvm5 is in 15-sp2 legacy only, so eol with end of 15-sp2 in a month.
llvm7 is actively supported currently, no eol set as there is no newer llvmX in sles yet.
Comment 11 Richard Biener 2021-12-01 13:47:56 UTC
(In reply to Marcus Meissner from comment #10)
> i masked the SLE binary conflict now and pushed it into the qa pipeline.
> 
> (it has correct conflicts I hope)
> 
> llvm5 is in 15-sp2 legacy only, so eol with end of 15-sp2 in a month.
> llvm7 is actively supported currently, no eol set as there is no newer llvmX
> in sles yet.

There will not be any newer llvmX in sles (there is pieces of llvm9 and llvm11
but only the parts required by the graphics stack runtime are shipped and supported).  The idea is that llvmX (and clangX) will come from PackageHub
and thus be not L3 supported (apart from the graphics stack requirements, as said).

Is there a way to make llvm7 EOL somehow without providing a (L3) supported replacement?
Comment 12 Marcus Meissner 2021-12-01 14:15:15 UTC
would need a request via jira ... PM ticket. We can at most move it to legacy with 15-sp4 and announce we drop it later. But someone needs to open a PM ticket and convince PM.


For newer llvmxx in packagehub, we can build it internally in IBS (and ship to packagehub) or externally in backports,  depending on what is better.
Comment 13 Richard Biener 2021-12-01 14:26:45 UTC
(In reply to Marcus Meissner from comment #12)
> would need a request via jira ... PM ticket. We can at most move it to
> legacy with 15-sp4 and announce we drop it later. But someone needs to open
> a PM ticket and convince PM.

OK, Micha - can you ping whoever is appropriate to do this?
 
> 
> For newer llvmxx in packagehub, we can build it internally in IBS (and ship
> to packagehub) or externally in backports,  depending on what is better.

I think externally in backports works for me, if populating packagehub
requires internal build in IBS then SLE customers might prefer that (guess
we don't want it in both places - not sure about the interaction between
SLE and Leap here).
Comment 14 Michael Matz 2021-12-01 16:38:45 UTC
(In reply to Richard Biener from comment #13)
> (In reply to Marcus Meissner from comment #12)
> > would need a request via jira ... PM ticket. We can at most move it to
> > legacy with 15-sp4 and announce we drop it later. But someone needs to open
> > a PM ticket and convince PM.
> 
> OK, Micha - can you ping whoever is appropriate to do this?

I have now, but I want to note that deprecation of llvm7 in SLE is orthogonal to
the eventual removal of the unversioned llvm package from SLE (to be replaced by
one in Backports/Leap that tracks the "current" llvm version).

Nevertheless I've asked Rado to create such ticket.
Comment 15 Swamp Workflow Management 2021-12-01 23:17:36 UTC
openSUSE-RU-2021:1516-1: An update that has two recommended fixes can now be installed.

Category: recommended (low)
Bug References: 1192310,1192429
CVE References: 
JIRA References: 
Sources used:
openSUSE Backports SLE-15-SP3 (src):    llvm12-12.0.1-bp153.3.1
Comment 16 Marcus Meissner 2021-12-12 13:55:15 UTC
released