Re: Bug#1064031: bookworm-pu: package rustc-web/1.70.0+dfsg1-7~deb12u1

[Andres Salomon]

Hi,






Thanks,
Andres


On 2/15/24 19:25, Andres Salomon wrote:

It was pointed out that this bug never made it to the d-release list for some reason. Would someone from the release team mind taking a peek at this so I can get chromium in bookworm with rust sorted out please?

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian....@packages.debian.org
Usertags: pu



[ Reason ]






[ Impact ]


[ Tests ]


[ Risks ]
Low/no risk.

[ 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 (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]


The changelog entry:

rustc-web (1.70.0+dfsg1-7~deb12u1) bookworm; urgency=medium

   * Non-maintainer upload.
   * Rename rustc backport to rustc-web, intended to be used for browsers.
   * Generate & include bootstrap compilers via an orig-stage0.tar.xz.
   * Add mipsel bootstrap compiler back, as mipsel is still in bookworm.
   * Disable profiler on mipsel, as it likely doesn't work either.
   * Disable wasm.
   * Drop -all virtual package, which doesn't make sense for us.



I've included a diff against unstable's rustc (1.70.0+dfsg-7).

[ Other info ]
See d-release thread below.



On 2/13/24 19:32, Andres Salomon wrote:

Chromium now requires a Rust compiler to build, and it specifically needs a rustc with profiler support built into it. This package can hopefully be shared with firefox and other browser/web engines that end up needing a newer rustc. Chromium 121 started removing C++ code in favor of Rust. For 121 in bookworm we reverted that patch, but that's not a long-term solution as more C++ code gets replaced with Rust code. Chromium requires a Rust compiler with profiler support built into it, which was only added in rustc 1.70.0+dfsg1-3 (see #1043311). Since bookworm's rustc lacks this, we need a backport. We don't want to risk breaking existing Rust packages in bookworm by backporting the profiler patches to 1.63, so instead we'll do something similar to what firefox did in the past with rustc-mozilla and backport a newer rustc. Note the name "rustc-web" breaks with the traditional rustc-mozilla naming, since it's not really mozilla-specific any more. As mentioned below in the mailing list thread, the firefox maintainer isn't certain if 1.70 will be new enough for firefox-esr 128; however, if a newer rustc is needed, they can update this package and I will make sure the newer version continues to work with chromium. There's no impact for bookworm users, as packages in stable must explicitly choose to build against rustc-web. The rustc-web and libstd-rust-web-dev packages have appropriate conflicts/replaces to ensure there's no accidental installation with bookworm's existing rustc packages. Chromium 121.0.6167.160-1~deb12u1 succeeds in building and running on bookworm with this rustc-web package. Many of the changes were modeled after the older rustc-mozilla package from bullseye, but with some updates for the state of things in bookworm. As with rustc-mozilla, the bootstrap compilers are included in orig-stage0.tar.xz. Because I'd already backported llvm-toolchain-16 to bookworm, there was no need to modify rustc's llvm 16 dependencies.

Okay, so I've gotten rustc 1.70.0+dfsg-6 (the prior version needed some bootstrap fixes) built on bookworm, and managed to use it to build chromium as well. Unfortunately -6 isn't building on mips64el, but I strongly suspect that this is something that won't happen in bookworm.

On 1/22/24 21:22, Timothy Pearson wrote:

I'm going to name the package rustc-web, and I'll send a patch for review hopefully tomorrow. Chromium 122's planned for release on Feb 20th, and I haven't yet checked if they've removed more C++ code in favor of Rust.

----- Original Message -----

From: "Andres Salomon" <dilin...@queued.net>

Cc: "Timothy Pearson" <tpear...@raptorengineering.com>
Sent: Monday, January 22, 2024 8:17:15 PM
Subject: Re: chromium and rustc in bookworm

To: "Adrian Bunk" <b...@debian.org>, debian-release@lists.debian.org, pkg-rust-maintain...@alioth-lists.debian.net, debian@fabian.gruenbichler.email, infini...@debian.org, sylves...@debian.org

On 1/22/24 15:34, Mike Hommey wrote:

On Mon, Jan 22, 2024 at 03:39:08AM +0200, Adrian Bunk wrote:

On Sun, Jan 21, 2024 at 06:55:31PM -0500, Andres Salomon wrote:

...

c) Much like the Firefox maintainer(s) created rustc-mozilla for

'rustc-1.70').



work on that option.

(old)oldstable, we create a 'rustc-chromium' package for bookworm. It could even be used for Firefox if their ESR updates start needing newer Rust language features (in which case, maybe 'rustc-newer' or 'rustc-browsers' is a better name for it? Or like Clang, include the major version and call it As I'm still messing around with bookworm's rustc(+profiler) as well as trying to get Chromium 121.x to build in Sid, I don't have a strong opinion on this yet. However, I wanted to bring it to everyone's attention, and see if anyone else did have strong opinions either way. If one of the teams feels strongly against option (b) for example, I won't bother continuing to

AFAIK rustc 1.78 (to be released in May) will be required by the next

IMHO c) would be best, with one rustc-* package shared for both browsers. Firefox ESR 128, and bookworm will switch to 128 in September/October.

At this point, there is no saying which specific version will be
required, but the one thing that is sure is that it will be at least

like it might as well stay 1.70.

Interestingly, 1.70 is what we currently have in unstable, which means
unstable is > 6 months outdated already.

Mike

1.70. If I had to guess, I'd say it might be 1.75, but so far, it looks

Sounds like (c) is the winner. Now for the bikeshedding -
rustc-browsers? rustc-backport?  rustc-unstable?

Agreed on the course of action.  For the bikeshed, rustc-web?  I'm thinking of embedded browsers (things like electron) that may end up depending on it, and web might be more descriptive for all of that?

As far as release cadence, at least from my end if firefox-esr needs a
newer rustc backport then chromium will be able to quickly adjust. We

newer rustc. In the other direction, I'm expecting/hoping that we can
just manually enable experimental features in chromium crates until a
newer rustc is absolutely necessary. As with clang, I expect that would
be roughly every 12-18 months.

have almost weekly security updates, which can be adapted to work with a

I'm a bit less optimistic, but we can see what the cadence settles in as.  Personally I'd be surprised if we can get away with anything slower than a 6 month cadence, just based on how rapidly Google is iterating, but we just won't know until we have a number of Rust-dependent releases under our belt.

OpenPGP_0x645D0247C36E7637.asc
Description: OpenPGP public key

OpenPGP_signature.asc
Description: OpenPGP digital signature