Debian Rust packaging team
Team project and packaging repos (on salsa): https://salsa.debian.org/rust-team
Public IRC channel: #debian-rust on irc.oftc.net
How to package a Rust application/crates: https://salsa.debian.org/rust-team/debcargo-conf/blob/master/README.rst
Get in touch with us via ML or IRC and join rust-team on salsa :)
Contribute to packaging, bug fixing and testing
Report bugs, QA pitfalls, and stuff missing from drafts and TODO
Packaging of all rust crates is done in a single git repo, because most crates only need two files (d/copyright, d/changelog), everything else is automatically generated by debcargo.
To help, join the salsa team, then git clone firstname.lastname@example.org:rust-team/debcargo-conf and follow instructions in README.rst. We currently have a backlog of about 200 crates to package and upload. Each crate takes about 2-3 minutes to package once everything is set up; the initial set-up may take 10-30 minutes depending on how familiar you are with Debian packaging tools.
For more details about what debcargo does, you can read through the Debian Rust packaging policy.
Toolchain (rustc, cargo)
Library unbundling - see "Embedded libraries" section of rustc's README.source
?Runtime soname and stability
Bootstrapping a new distribution
rustc and cargo both Build-Depends on each other. In order to break the loop, we use Build Profiles.
For rustc, see "Bootstrapping" section of rustc's README.source.
For cargo, we currently don't have an automated way to do it. If you need to do this, the following steps should work: install upstream's cargo binary to /usr/local, install the other Build-Depends, and then dpkg-buildpackage -d.
Porting to a new architecture
Use sbuild --host=$arch --profiles=nocheck $pkg, it should Just Work. $pkg is either rustc or cargo to use what's already in the FTP archive, or a path to a .dsc of your choice.
If it doesn't work, you might need to also give --extra-repository="deb http://incoming.debian.org/debian-buildd buildd-unstable main". This is the work-around that most-often fixes things, so just try it blindly even if you don't understand the below. Technically, this is required when (e.g.) there was recently a new GCC or binutils upload, but not all architectures were built and uploaded to the main FTP yet so some architectures are out-of-sync version-wise on Debian unstable.
If it still doesn't work, and sbuild complains about missing build-dependencies, and these are core packages not directly related to rustc such as gcc, binutils or perl-related packages, you can:
check the relevant buildd logs (e.g. gcc-8, binutils). If it says "Building" for either the source or the target architecture, you will need to wait until the builds are done i.e. if both entries say "Installed". Then the incoming trick above should work. That's just an unfortunate aspect of how cross-building with sbuild works today, sadly.
check the transition tracker (e.g. perl). If there is a transition going on you'll have to wait until it is done, or alternatively use a Debian testing schroot instead of Debian unstable - but be aware that some necessary packages may be out-of-date there (such as the previous version of rustc itself) in which case you'll have to download them and supply them manually to sbuild using --extra-package=.
If it still doesn't work, check that the binary package crossbuild-essential-$arch exists for the desired architecture. If it doesn't, add this to your ~/.sbuildrc:
If it still doesn't work, then file a bug to src:rustc, src:cargo, or debcargo as appropriate. You can also try glaubitz's method which involves more manual steps, though it is probably out-of-date by the time you read this.
For more details about rustc cross-compiling see "Cross-compiling" section of rustc's README.Debian.
We always welcome new contributors, and we are mostly available on IRC for quick questions. Feel free to ping us and join the team:
- Luca Bruno (IRC: kaeso)
- Sylvestre Ledru (IRC: sylvestre)
- Ximin Luo (IRC: infinity0)