http://bugzilla.suse.com/show_bug.cgi?id=1164454 http://bugzilla.suse.com/show_bug.cgi?id=1164454#c1 Richard Biener changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |aaronpuchert@alice-dsl.net, | |mlin@suse.com Flags| |needinfo?(mlin@suse.com) --- Comment #1 from Richard Biener --- What are the actual duplicate binaries? For SLE15 none fo the above cited sub-packages should make it to the media, for Leap we probably want the full llvm9 though. libc++1, yes - doing it properly would need some similar mechanism as we have for the GCC runtime (some %define as to which one becoming the main one in the project config and suffixing the other). What's the solution for Factory here? Ah, we update the old package to no longer build libcxx and python3-clang. The spec file says # install python bindings # The python bindings use the unversioned libclang.so, # so it doesn't make sense to have multiple versions of it %if %{with pyclang} install -d %{buildroot}%{python3_sitelib}/clang Note applying the Factory solution to SLE would mean updating llvm7 in SP2 and thus splitting it, requiring future maint updates to be done twice, once for SP1 and once for SP2+ which doesn't sound appealing to me. Can't you apply some magic to the "product config" to prefer the llvm9 variants for Leap? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1164454 http://bugzilla.suse.com/show_bug.cgi?id=1164454#c3 Max Lin changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(mlin@suse.com) | --- Comment #3 from Max Lin --- (In reply to Richard Biener from comment #1)

What are the actual duplicate binaries? For SLE15 none fo the above cited sub-packages should make it to the media, for Leap we probably want the full llvm9 though.

The actual duplicated binaries: libc++-devel, libc++1, libc++abi-devel, libc++abi1 and python3-clang RPMs, llvm7 and llvm9 both had provide those RPMs. For Leap, if we had both full llvm9 and full llvm7, OBS scheduler will just picks one of duplicated RPM if any package build requires it.

libc++1, yes - doing it properly would need some similar mechanism as we have for the GCC runtime (some %define as to which one becoming the main one in the project config and suffixing the other).

What's the solution for Factory here? Ah, we update the old package to no longer build libcxx and python3-clang.

The spec file says

# install python bindings # The python bindings use the unversioned libclang.so, # so it doesn't make sense to have multiple versions of it %if %{with pyclang} install -d %{buildroot}%{python3_sitelib}/clang

Note applying the Factory solution to SLE would mean updating llvm7 in SP2 and thus splitting it, requiring future maint updates to be done twice, once for SP1 and once for SP2+ which doesn't sound appealing to me.

Can't you apply some magic to the "product config" to prefer the llvm9 variants for Leap?

for duplicated RPMs, prefer llvm9 variants has not fix this issue, Prefer: is used for RPM. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1164454 http://bugzilla.suse.com/show_bug.cgi?id=1164454#c5 --- Comment #5 from Max Lin --- Mesa and llvm9 are still in Leap's staging project, I don't dare to merge them due to this issue, so I'll move them to ignore list until we have a solution. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1164454 http://bugzilla.suse.com/show_bug.cgi?id=1164454#c7 --- Comment #7 from Richard Biener --- (In reply to Aaron Puchert from comment #6)

(In reply to Richard Biener from comment #1)

...

What's the solution for Factory here? Ah, we update the old package to no longer build libcxx and python3-clang. Correct, this is documented in README.packaging in the llvm metapackage. (Perhaps not the place one would expect it...)

...

Note applying the Factory solution to SLE would mean updating llvm7 in SP2 and thus splitting it, requiring future maint updates to be done twice, once for SP1 and once for SP2+ which doesn't sound appealing to me. Are the packages otherwise shared between SPs? Because Leap has different repos, as far as I know. And so far I didn't run into rebase conflicts because of turning off the libc++ builds for older packages.

Yes, in SLE the actual binary rpm packages are shared.

By the way, we should also update the llvm metapackage (https://build.opensuse.org/package/show/openSUSE:Leap:15.2/llvm), so that llvm9 would be used by most packages. I don't think that defaulting to the old version is a good idea.

There was also a major version update to LLVM between Leap 15.0 and 15.1, specifically from 5 to 7. So I don't think there is anything new here. We'd just need to repeat what was done back then.

This was also done for SLE15 SP1 but there llvm5 was not adjusted (the issue doesn't arise there since the setup is different - a service pack is just a set of update rpms ontop of the GA product). If we ever need to update llvm5 we'd need to disable the pieces that would otherwise conflict.

So I'd prefer the Factory solution for Leap 15.2: disable the libc++ & python-clang builds for llvm7, update the llvm metapackage to 9.0.1.

That works for me but then the origin should be the Factory packages rather than the SLE ones. Note that in SLE15 SP2 we have quite some packages that use clang/llvm-devel and all of those (but Mesa!) still use llvm7 - I'm not sure whether they build if we update the 'llvm' package or which one would need adjustment to build-require llvm7/clang7 variants. This and because the "update" for SP2 was late is the reason I refrained from touching the 'llvm' meta-package and made sure we only use llvm9 from Mesa (where it was requested as a feature) for SP2. I also wonder if we want to drop llvm5/7 from Leap 15.2 if we introduce llvm9. But as said all this is quite some work and I currently have no spare cycles for a proper solution in Leap. We can of course try pulling llvm and llvm9 from Factory into a staging and see what breaks... -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1164454 http://bugzilla.suse.com/show_bug.cgi?id=1164454#c9 --- Comment #9 from Aaron Puchert --- I've filed submit requests for llvm [1] and llvm7 [2] from Factory to Leap 15.2, let's see where this goes. [1] https://build.opensuse.org/request/show/777941 [2] https://build.opensuse.org/request/show/777943 -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1164454 http://bugzilla.suse.com/show_bug.cgi?id=1164454#c10 --- Comment #10 from Max Lin --- FYI I leave those SRs on backlog, for diverging from SLE we need agreement from release manager and package maintainer. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1164454 http://bugzilla.suse.com/show_bug.cgi?id=1164454#c11 --- Comment #11 from Aaron Puchert --- My idea was that we stage this and try if it works, as Richard Biener suggested in comment 7. If it doesn't work, there is no point in discussing it. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1164454 http://bugzilla.suse.com/show_bug.cgi?id=1164454#c13 --- Comment #13 from Max Lin --- As Aaron has mentioned at https://build.opensuse.org/request/show/774578 , rust is build failed with llvm9, rust is also from SLE thus it's potentially rust should be build fail also in SLE... -- You are receiving this mail because: You are on the CC list for the bug.

SLE has 'llvm' still at version 7 so packages wanting to use llvm9 need to explicitely build-require llvm9-devel and friends. Only Mesa-drivers does that at the moment. Correct, which is a bit of a problem though (or could be): linking with multiple versions of libLLVM.so is not supported, but Mesa consists of

http://bugzilla.suse.com/show_bug.cgi?id=1164454 http://bugzilla.suse.com/show_bug.cgi?id=1164454#c15 --- Comment #15 from Aaron Puchert --- (In reply to Richard Biener from comment #14) libraries, so if an application links with the default libLLVM.so.7 and has a graphical interface, it will also link with libLLVM.so.9 through Mesa at runtime. That doesn't work. That's why I think Mesa should follow the system-wide default. Rust on the other hand could still link with libLLVM.so.7, because it's a leaf executable that doesn't have anything to do with Mesa. Side note: the libraries in Mesa-gallium link with libLLVM, and the library in Mesa-libOpenCL links additionally with libclang-cpp. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1164454 http://bugzilla.suse.com/show_bug.cgi?id=1164454#c17 --- Comment #17 from Aaron Puchert --- My suggestion would be to change rust in SLE and Leap to require llvm7-devel instead of llvm-devel >= 6.0 and update the llvm metapackage to version 9. Otherwise we're just going to run into issues with packages like kdevelop5 or libqt5-creator that use libLLVM and Mesa. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1164454 http://bugzilla.suse.com/show_bug.cgi?id=1164454#c19 --- Comment #19 from Max Lin --- (In reply to Richard Biener from comment #18)

(In reply to Aaron Puchert from comment #17)

...

My suggestion would be to change rust in SLE and Leap to require llvm7-devel instead of llvm-devel >= 6.0 and update the llvm metapackage to version 9.

Otherwise we're just going to run into issues with packages like kdevelop5 or libqt5-creator that use libLLVM and Mesa.

I'm not against such change, it would be an update to SLE15-SP1 rust (we don't want to split sources for this). Given rust isn't happy with llvm9 the >= 6.0 check is "bogus" anyways. There's only a group of maintainers though, CCing.

So if we "fix" rust then pulling 'llvm' from Factory into Leap works? Can you stage that (change rust in Leap) to try?

FYI I've added rust to staging E[1] from Factory, the rust version is 1.40, there is no build error appeared in staging E at least. [1] https://build.opensuse.org/project/show/openSUSE:Leap:15.2:Staging:E -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1164454 Lubos Kocman changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P5 - None |P2 - High -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1164454 http://bugzilla.suse.com/show_bug.cgi?id=1164454#c25 --- Comment #25 from Swamp Workflow Management --- SUSE-RU-2020:0839-1: An update that has one recommended fix can now be installed. Category: recommended (moderate) Bug References: 1164454 CVE References: Sources used: SUSE Linux Enterprise Module for Open Buildservice Development Tools 15-SP1 (src): rust-1.36.0-7.1 SUSE Linux Enterprise Module for Development Tools 15-SP1 (src): rust-1.36.0-7.1 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. -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1164454 Chenzi Cao changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|screening-team-bugs@suse.de |rguenther@suse.com -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1164454 Stefan Weiberg changed: What |Removed |Added ---------------------------------------------------------------------------- CC|sweiberg@suse.com | -- You are receiving this mail because: You are on the CC list for the bug.