[ Reason ]
Clang 19 is getting a little long in the tooth for chromium. In
addition, we're going to need newer version of rustc-web for both
chromium and upcoming firefox-esr 153; but newer versions of rustc
require at least llvm-toolchain-20.

Note that 22.1.6-1 is currently in testing, but 22.1.7-1 is about to
migrate. If for some reason 22.1.7-1 fails to migrate in a timely
manner, I can fall back to 22.1.6-1.

[ Impact ]
Minimal, as this only impacts packages which intentionally choose to
build against llvm-toolchain-22.

Note that this version of llvm-toolchain-$VERSION (unlike past versions)
builds libc++1, libc++abi1, and llvm-libunwind1 packages *without* the
major version in the package name. This could cause problems in future
backports of llvm-toolchain-$VERSION, but won't be a problem for trixie
since it was released with an older version of llvm-toolchain-19 that
included libc++1-19 (and friends).

[ Tests ]
Chromium 149.0.7827.53-1~deb13u1 succeeded in building using clang-22
22.1.7-1~deb13u1 packages, and I'm currently using those chromium
packages for browsing.

[ Risks ]
Low risk for the above stated reasons.

[ Checklist ]
   [x] *all* changes are documented in the d/changelog
   [x] I reviewed all changes and I approve them
   [x] attach debdiff against the package in stable
   [x] the issue is verified as fixed in unstable

[ Changes ]
Since llvm-toolchain-22 isn't currently in trixie, I've included the
diff between what's in 22.1.7-1 (in sid) and what's changed in
22.1.7-1~deb13u1. The g++-multilib change happens automatically as
d/control gets regenerated from d/control.in and s390x gets filtered out
of MULTIARCH_LIBS; I'm merely documenting it in d/changelog.

Control: tags -1 moreinfo
from src:llvm-defaults.

# apt-get install starpu-examples/trixie libomp5/sid
...
The following packages have unmet dependencies:
 libomp5 : Conflicts: libomp-x.y
 libomp5-19 : Conflicts: libomp-x.y
E: Unable to correct problems, you have held broken packages.
E: The following information from --solver 3.0 may provide additional context:
   Unable to satisfy dependencies. Reached two conflicting decisions:
   1. libomp5-19:amd64 is selected for install because:
      1. starpu-examples:amd64=1.4.7+dfsg-2 is selected for install
      2. starpu-examples:amd64=1.4.7+dfsg-2 Depends libomp5-19 (>= 0.20130412)
   2. libomp5-19:amd64 is not selected for install because:
      1. libomp5:amd64=1:22.1.7-1 is selected for install
      2. libomp5-19:amd64 Conflicts libomp-x.y
         [selected libomp5:amd64=1:22.1.7-1]
#

In practice this might mean that when both starpu-examples/trixie and
libomp5/trixie are installed, then llvm-toolchain-22/1:22.1.7-1~deb13u1
in trixie might result in a dist-upgrade removing starpu-examples.

I assume that didn't run into #1128822, adding trixie to SPIRV_DISABLE_DISTRO
would be an alternative.

cu
Adrian

Thanks! You're right, I didn't look at libomp. For right now, I think
what I'll do is simply drop the unversioned lib packages (libc++1,
libc++abi1, llvm-libunwind1, and libomp5) until I come up with a better
solution. Chromium (and rust) can continue statically linking against
the various libraries.

I'm having the -22 dev packages depend upon -19 libs. Despite having a
stable ABI, this is not really supported; the llvm-toolchain packages
support that kind of thing in the other direction (-22 dev packages can
be made to depend on -23 libs). However, at least for trixie (and
potentially bookworm, but I haven't tested it yet), this will be fine
for rust & chromium since they're building statically against those dev
packages. Simply dropping the library deps in those dev packages results
in llvm build failures, as internally llvm appears to link to them
dynamically, and I didn't feel like spending too long investigating why.

Please see the attached patch for the updated diff. I tested this by
build chromium (statically) with it on trixie.

I didn't hit that, no. Hopefully I don't hit it for bookworm, either!

Hi,

Emilio suggested uploading now to save a round-trip, so I just uploaded
22.1.8-1~deb13u1 to trixie. I've attached the diff between 22.1.8-1 and
22.1.8-1~deb13u1, though it's really the same as the previous
22.1.7-1~deb13u1.

Thanks,
Andres

Hi,

The packages as uploaded to NEW have some dependency issues:

     pkg:
      package: liboffload-22
      version: 1:22.1.8-1~deb13u1
      architecture: amd64
      unsat-dependency: libomp5 (>= 1:22.1)

trixie has libomp5 1:19.0-63.

Is that "just" a sign of the packages not being built in the correct
environment, or something that needs source changes?

Regards,

Adam

D'oh, I think I see the problem. d/rules has the following:

echo 'libomp $(SONAME_OPENMP) libomp5 (>= 1:$(LLVM_VERSION).1)' >>
debian/shlibs.common

I'll fix it and kick off another rebuild soon.

I am not a member of the release team, but I fail to see how that makes
any difference now after the deadline for the point release.

Doing anything in a hurry now is just stress for everyone with high
risk of introducing regressions, and it is anyway doubtful that it
would be compatible with doing the point release on Saturday.

cu
Adrian

Okay, that took a little longer than expected because building chromium
on trixie with llvm-toolchain-22 broke (related to trixie's older
bindgen), but we have a workaround for chromium and I was able to test
chromium builds with this new ~deb13u2 package.

I've attached the full debdiff between sid's version and this backport,
but the only non-changelog difference between ~deb13u1 and ~deb13u2 is
the bit at the end:


+@@ -1833,7 +1833,7 @@
+ 	echo 'libc++ 1 libc++1 (>= 1:$(LLVM_VERSION).1)' > debian/shlibs.common
+ 	echo 'libc++abi 1 libc++abi1 (>= 1:$(LLVM_VERSION).1)' >>
debian/shlibs.common
+   ifneq (,$(filter $(DEB_HOST_ARCH), $(OMP_ARCHS)))
+-	echo 'libomp $(SONAME_OPENMP) libomp5 (>= 1:$(LLVM_VERSION).1)' >>
debian/shlibs.common
++	echo 'libomp $(SONAME_OPENMP) libomp5-19' >> debian/shlibs.common
+   endif
+   ifneq (,$(filter $(DEB_HOST_ARCH), $(LIBUNWIND_ARCHS)))
+ 	echo 'libunwind 1 llvm-libunwind1 (>= 1:$(LLVM_VERSION).1)' >>
debian/shlibs.common

it would probably be good if we could wait for this MR to land:

https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/merge_requests/224

to avoid the need for another bump for rustc(-web)?

Fabian

[...]
[...]


Ah jeez - if that were a smaller commit, I'd just cherry-pick it and
roll a ~deb13u3. Given the size though, I'll wait for the llvm packages
to pick it up and migrate to forky.

Mike & Emilio, are you good with another 2-4 week delay for the llvm
backoprt?

Also in the meantime, I'd appreciate testing of the current packages:

https://people.debian.org/~dilinger/llvm22/

You can grab the orig from sid/forky if you want to rebuild, I'm on a
train right now and don't have very good wifi. I've only tested it
building chromium, so builds of firefox or rustc would help shake out
any additional changes we might need to make.

Thanks,
Andres

FWIW, the actual change is the first small hunk, the rest is testsuite
changes that I don't think the Debian build even runs. Let me
double-check and verify (and minimize accordingly).

I can give them a spin to build a dlstage0 backport of rustc 1.96 from
experimental (the earlier versions are still on LLVM 21) over the
weekend.

Fabian

updated MR (original one got merged already) opened, since what I wrote
above holds.

rustc 1.96.1 from experimental (with a slight adaptation to match
trixie's libgit2, and the `pkg.rustc.dlstage0` (no 1.95 in trixie yet)
and `nowasm` (lack of wasm-tools) build profiles works as expected with
your current test packages.

I'm not seeing an updated MR, but if it's just skipping all the test/
stuff that's easy enough. I'll start up a deb13u3 build shortly.

Great, thank you!

https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/merge_requests/226

and yes, exactly, same patch, just without all the test hunks :)

Okay, I stuck the new packages at
https://people.debian.org/~dilinger/llvm22/. If you have a way of
reproducing the OOB issue, would you mind giving them another whirl
building rustc to make sure the included fix works as intended? If
everything looks good I'll upload them tonight or tomorrow. I've already
successfully built chromium with these.

Hi,

Do you have test packages or a .dsc somewhere?

Cheers,
Emilio

put a test build of rustc 1.96.0 with nowasm,pkg.rustc.dlstage0 and Andres'
LLVM 22 packages here:

https://people.debian.org/~fabiang/rustc-trixie-llvm-22/

package release.debian.org
tags 1139451 = trixie pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian trixie.

Thanks for your contribution!

Upload details
==============

Package: llvm-toolchain-22
Version: 22.1.8-1~deb13u2

Explanation: new package to support chromium builds

package release.debian.org
tags 1139451 = trixie pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian trixie.

Thanks for your contribution!

Upload details
==============

Package: llvm-toolchain-22
Version: 22.1.8-1~deb13u1

Explanation: new package to support chromium builds

package release.debian.org
tags 1139451 = trixie pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian trixie.

Thanks for your contribution!

Upload details
==============

Package: llvm-toolchain-22
Version: 22.1.8-1~deb13u3

Explanation: new package to support chromium builds

package release.debian.org
tags 1139451 = trixie pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian trixie.

Thanks for your contribution!

Upload details
==============

Package: llvm-toolchain-22
Version: 22.1.8-1~deb13u2

Explanation: new package to support chromium builds

package release.debian.org
tags 1139451 = trixie pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian trixie.

Thanks for your contribution!

Upload details
==============

Package: llvm-toolchain-22
Version: 22.1.8-1~deb13u1

Explanation: new package to support chromium builds

package release.debian.org
tags 1139451 = trixie pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian trixie.

Thanks for your contribution!

Upload details
==============

Package: llvm-toolchain-22
Version: 22.1.8-1~deb13u3

Explanation: new package to support chromium builds

Hi,

The deb13u3 package failed to build on a bunch of architectures on trixie:

https://buildd.debian.org/status/package.php?p=llvm-toolchain-22&suite=trixie

The ppc64el build failure is an upstream bug that's fixed in newer
versions of LLVM, but for 22 we can just work around it (which Emilio
did successfully for his deb12u1 upload
https://people.debian.org/~pochu/llvm-bookworm.debdiff ).

The i386 invalid build-dep is related to libomp not being built on
trixie (though it was later added to 19 after trixie's release). Emilio
also fixed that in his bookworm upload.

The remaining two architectures (armel, s390x) not getting built are
because of a bug in d/rules; when I switched from using llvm-libunwind1
to libunwind-19, I missed the spot where the list of architectures for
that package is generated for the build-dep.

I've prepared deb13u4 to fix all of those build failures. I've attached
a debdiff between deb13u3 and deb13u4. If it looks good, I'll do a
source-only upload to trixie.

(Emilio, you'll probably want to pull that libunwind fix into bookworm
and possibly bullseye's llvm-toolchain-22.)

Thanks,
Andres

deb13u4 failed on armel for a new reason; I'll need to prep deb13u5 once
I figure it out. At least it succeeded on the other archs.
[...]

Actually, maybe firefox-esr doesn't care about armel? I see that
firefox-esr ftbfs on trixie for armel (and has for some time), and
oldstable/lts doesn't appear to build armel?

If that's the case, then I won't bother and we can just go with deb13u4.
Chromium certainly doesn't care about armel.

After an IRC discussion with Emilio (and based on chromium's upcoming
release) - please accept deb13u4 into s-p-u.

We'll need to do deb13u5 later on to fix armel, but there's some urgency
to get chromium w/ llvm 22 able to build on armhf/ppc64. I also haven't
been able to test s390x yet. So once deb13u4 is accepted, I'll be able
to see how the s390x build fares and any additional fixes needed there
can be included alongside armel fixes.

package release.debian.org
tags 1139451 = trixie pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian trixie.

Thanks for your contribution!

Upload details
==============

Package: llvm-toolchain-22
Version: 22.1.8-1~deb13u4

Explanation: fix various build failures

package release.debian.org
tags 1139451 = trixie pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian trixie.

Thanks for your contribution!

Upload details
==============

Package: llvm-toolchain-22
Version: 22.1.8-1~deb13u4

Explanation: fix various build failures