Seeking contact info for Rust packagers

[brson]

rust@lists.fedoraproject.org

Thanks I’ve noted it.

[anatol]

For Arch Linux please contact the package maintainer Alexander Rødseth, his email is xyproto@archlinux.org. As a backup you can contact me (I am an Arch developer as well).

[djc]

rust@gentoo.org is probably the best way to contact the Gentoo side.

FWIW, I’m currently stuck on https://github.com/rust-lang/rust/issues/39540. But haven’t tried witb the latest comments yet.

[brson]

Reply thanks @anatol and @djc.

[semarie]

For future notification about Rust packaging, you could contact me (semarie@openbsd.org) for OpenBSD.

[ishitatsuyuki]

I’m doing rust-git AUR packaging, which reflects the latest rustbuild changes. I have no contact with the repo version packager though.

Email: ishitatsuyuki@gmail.com

[brson]

Noted and noted.

I have not used this list for anything yet, but I really should have. After the big rustbuild change I am positive that broke downstream packaging.

Other changes recently have included the way we vendor sources. At the moment, only the tarballs come with vendored dependencies, and are thus able to build offline (theoretically). The git sources do not contain the vendored dependencies.

The other big change I would have told packagers is that we are now bundling all the Rust tooling that we consider part of the the Rust product in tree, and I’d suggest packagers source e.g. cargo from there, and no longer attempt to obtain it independently. The same will soon be true of rls, rustfmt and clippy. All these things will at some point in the near future be part of Rust proper.

[semarie]

Currently, if it is possible to build rustc using vendored crates provided in tarball, it isn’t the case for cargo: some required crates are missing. But I expect that src/vendor in tarball to be generated for rustc only.

It makes building all the Rust tooling at the same time complex (for packagers that try to do it offline): the build method are too differents.

At OpenBSD, I am building rustc on one side (using vendored crates), and cargo on another side (using the same tarball). For cargo, I setup a specific build environment where all the required crates at downloaded at first (controlled) step, there are extracted in a directory, metadata for vendoring at generated, and cargo is configured to search crates in vendored directory. The list of crates is manually maintained and changed at each release.

[brson]

some required crates are missing

I seem to recall something about this and it is a bug. There may even be a PR open to fix it cc @alexcrichton.

[notriddle]

michael@notriddle.com recently took over the Chocolatey (Windows) package.

[ishitatsuyuki]

it isn’t the case for cargo: some required crates are missing

This is something that is fixed recently by me, and it should have already landed in nightly. Mind trying it out?

[djc]

Yeah, I’ve had trouble updating the Gentoo packages. For 1.16.0 in the end another Gentoo Rust team member in the end just added --disable-rustbuild to the configure options, but so far I haven’t been able to update to 1.17.0. I filed https://github.com/rust-lang/cargo/issues/3965 after working through some other issues. In the mean-time, I’ve thrown away my previous 1.17.0 ebuild and now I forgot what I did to it, because apparently the build has changed again in some inscrutable way.

Having better “support” for packagers in some way would be much appreciated.

[semarie]

for rustc-1.17.0:

• configure: generate a config.toml file in your build directory (for example see the file located at rust-src/src/bootstrap/config.toml.example).
• build: invoke python rust-src/x.py build

(note the x.py tool has help: python rust-src/x.py help)

at OpenBSD, I am building using x.py dist (it generates a tarball with installer), and next at install stage I unpack the tarball and launch install.sh --prefix=MY-PREFIX.

@brson I think having a channel of communication for packagers would be valuable (mailing-list ? discourse ?). Packagers would be able to share their problems and seen how other resolv them, and Rust developers would be more aware of packager-specifics issues.

[djc]

But that will download a bunch of stuff, right? I need to handle the downloads up front, since our install phase has a network sandbox. What’s the best way to do this?

[semarie]

with vendor = true in config.toml, the build doesn’t require network access.

my install stage neither: the tarball used is generated locally (by ./x.py dist).

[djc]

Even with a config.toml which sets build.vendor to true, x.py build seems to start out downloading rust-std for me.

[semarie]

you need a complete rust suite at 1.16.0 (compiler + std library + cargo) on the build host to build rustc-1.17.0. if you didn’t specify rustc and cargo path in build.rustc and build.cargo, the build will try to download them automatically.

my config.toml looks like:

[build]
rustc = "path-to/rustc"
cargo = "path-to/cargo"
prefix = "/usr/local"
vendor = true

[rust]
channel = "stable"

[target.x86_64-unknown-openbsd]
llvm-config = "/usr/local/bin/llvm-config"

[dumbbell]

Hi!

@brson: For FreeBSD, you can contact rust@freebsd.org.

Thank you!

[djc]

So my problem is that there seems to be little or no documentation about how this whole thing is supposed to work. So far cobbling things together has not been very productive for me, and while responses I’ve gotten in IRC and the issue tracker have been helpful, it’s been clear to me that this whole use case of controlling how Rust is (self-) compiled is really not a priority for the team. And I sort of understand that, but I also think providing some high-level documentation about how the system is supposed to work could be high leverage.

Or maybe Gentoo is just more critical in how we try to control the build system, and/or I’m too fussy/critical of how things are supposed to work.

[system]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.