We request assistance with maintaining the cargo package, as well as Rust
packaging in general.

Firefox's next versions[1] will require rust, but the Debian pkg-rust team is
severely short on time to maintain these packages.

sylvestre@ and I are just about managing to keep rustc in Debian up-to-date
in our spare time.

lucab@ and gus@ know more about the rust ecosystem than either of us, but they
have not been very active recently. lucab@ had been maintaining cargo.

Right now, cargo needs to be updated to the next version, there are some open
bugs about it:

https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=cargo

I have not yet looked at this package myself but if there are any questions you
can probably prod lucab@ to answer them. He has a different handle on IRC, you
can join #debian-rust on OFTC to talk to us.

After this, we will need to update rustc to 1.16.0. This is packaged in git,
and it works (doko@ has already uploaded it to Ubuntu) however it uses some
deprecated Makefiles which are to be removed in the next 1.17.0 release.
Therefore, we should try to upload 1.16.0 using the new "rustbuild" buildsystem
which also build-depends on cargo. (To try this out, remove --disable-rustbuild
from d/rules.)

After that, we will have to figure out how to cross-compile cargo and rust
for other architectures. So far, we have been bootstrapping rustc on other
arches by using upstream's binary blobs, but this is not the ideal approach,
and will become even harder once we have the rustc<->cargo cyclic build
dependency. Upstream themselves prefer the cross-compilation approach, and had
previously given me some tips that I need to go dig out again from my IRC logs.

At some point we should also start packaging actual rust packages. Josh
Triplett had been planning to automate a large part of this, the work is still
incomplete but we have a Rust Packaging policy already:

https://wiki.debian.org/Teams/RustPackaging/Policy

Package automation tools:

https://anonscm.debian.org/cgit/pkg-rust/dh-cargo.git (low-level dh glue)
https://crates.io/crates/debcargo (high-level automater)

[1] https://buildd.debian.org/status/package.php?p=firefox&suite=experimental

Ximin Luo:


I've updated our cargo.git with some documentation on how to update the package, and updated some configs and scripts etc to match.

Now things will "work" if you run:

$ debian/make_orig_multi.sh 0.16.0
# move the files over
$ gbp import-orig ../cargo_0.16.0.orig.tar.gz # also imports the -deps tarball automatically

However, I've decided to not yet push these 0.16.0 commits, because I'm not sure if we need to tweak the -deps tarball further.

Luca, could you give us some guidance on how to proceed?

Perhaps we need to first expand clean-cargo-deps.patch or deps-tarball-filter.txt?

X

Ximin Luo:

I've made some more process and have pushed 0.17.0 to git. However we're getting build errors and I don't know how to proceed:

https://anonscm.debian.org/cgit/pkg-rust/cargo.git/tree/debian/TODO
https://anonscm.debian.org/cgit/pkg-rust/cargo.git/tree/debian/cargo-vendor-pack.py

I'm not familiar with the Cargo repo formats, and I don't know how d/cargo-vendor-pack.py should be fixed. Help would be appreciated.

Josh, is this anything related to how your dh-cargo works? Any code that we can reuse?

X

Not directly, until we're ready to package all the individual crate
dependencies (which we'll want to do at some point).  But you can
definitely use the same mechanism; it'd be much easier to generate a
directory registry than the full Cargo index format.  Rather than
generating an index file and repo, just:

1) Copy every crate directory, verbatim, into a subdirectory of a vendor
   directory.

2) Create a file .cargo-checksum.json in the crate directory, containing
   {"package":"$SHA256","files":{}} , where $SHA256 is the sha256 of the
   .crate file.

3) Create a directory containing a file "config", containing:

[source.crates-io]
replace-with = "my-registry"

[source.my-registry]
directory = "/path/to/the/vendor/directory"

4) Set CARGO_HOME to the directory containing that config file, and
   build.

debcargo can help a bit with this.  Run it on a crate, move
debian/cargo-checksum.json to .cargo-checksum.json , aggregate
debian/copyright, remove the rest of debian/ , and put the resulting
directory into the registry directory.

...and looking at git from 20 minutes ago, it looks like you've switched
over to directory registries now.

Josh Triplett:

Thanks for the tip, yes I figured this out by looking at both your dh-cargo code and also the Fedora cargo package. [1]

The new version is uploaded to experimental, but there's some more things I'd like to tidy up before uploading it to unstable.

- I get errors about missing "cargotest" and "hamcrest" when I try to `make test`, it looks like cargotest is actually in the rustc package:

https://github.com/rust-lang/rust/tree/master/src/tools/cargotest

Any suggestions on how to deal with this? I guess the obvious thing to do is to package a librust-cargotest-xxx-dev package but I wonder if there are better options.

- cargo still embeds libgit2-sys source code, and I can see that in the deps-tarball-filter.txt Luca was explicitly leaving it in. Is that because they patch the source code?

Can we just get rid of it, and link to libgit2 instead?

X

[1] https://src.fedoraproject.org/cgit/rpms/cargo.git/tree/cargo.spec

git2-rs doesn't modify libgit2, but it does use a snapshot from git, via
a submodule.  And unfortunately, while it supports building against a
system version via pkg-config, it doesn't include any version number in
its dependency.  libgit2 itself doesn't have a stable ABI, so either an
older *or* a newer version can potentially fail due to
incompatibilities.  (Also, like many libraries, libgit2 doesn't really
update its SONAME and similar except when releasing, even though many
people run git snapshots.)

Fortunately, git2-rs uses ctest now to attempt to make sure its bindings
match the actual signatures of the functions, so at least an attempt to
build against an older (or sometimes newer) version of libgit2 will tend
to produce compile errors (assuming you get all the environment
variables set correctly to find it).  However, I know of at least one
case where git2-rs pulled in a new snapshot of libgit2 to obtain
critical bugfixes rather than differences in ABI.

In short, I think we *could* switch to pulling in the system version of
libgit2, but we'd need to work very closely with the libgit2 maintainer,
and sometimes package snapshots of libgit2 from git.  We might also want
to work with libgit2 and git2-rs upstreams to 1) get more regular
updates to the version number that appears in the pkg-config file and 2)
get libgit2-sys to declare a pkg-config dependency that matches its
snapshot of libgit2.

- Josh Triplett

It would be nice, but last time I tried upstream was tracking libgit2 from
master: https://github.com/alexcrichton/git2-rs/pull/80

Things may have changed in the meanwhile, I did not re-assess since then.

Ciao, Luca

This is still listed as RFH - is there still help required/appreciated?
I like the rust eco-system and would like to contribute here.

-----BEGIN PGP PUBLIC KEY BLOCK-----

mQINBFiM64ABEAC1oAm0/aU+T+Tb4f5q9KALm/UfaZ34dmgXY3QcU3lF34MEpATC
JxRmiLJoQiBvLyDPpHEuQcAArUrMEImySQOWcst9S1TKlIE51CXNpvCXkA2RQ7BU
mV+UnRbMqndSXo5qkawgb2ogrppeztxvFjL6jkFHp+rnTqV5RvXRLZwOH2dnkDwz
0DP0J01tECFJo+wRaj/rDnaVlLrTEi+58isVv0HDf6JEiD9wp7U59VKqgeJWezUb
YKWbjn7s1KTNw7NG3SDDniwOAw8HCtV86Z4L6sfHUtX9CIn9S/ykLsXXCkbVlCd/
15VcPweblCtC+spXKcL2wY+80Y6QG+wW9Mg1Kd7ifi2sCM7o561hjPAd/nEQXqo5
8pUohCyAfySdTTwlV+rjIpGOARbZfIknCX1938P2ZnWU9QEBRVc2SdPNewJOMBHl
lHp7yUX1GZFXgzHiGhuo9fRyFLvMhDRYKduBpDrPLeuvGKpmbVdw60jjRQKYzluk
bUqnAfQ4k3K83ZxuDQMoNVw6XZqXSu86wGPcC6nGtTpAY56bCmZXVjgVJ5Adu8lT
vqhF2xxh0ikhzRXIO31sQDs19IJSduJD90UjAUe7B3di1FDspUvz/zH2c+OLNrVH
HoejAa2E8iU7dEvzlka0wiNT53mLeFW6OYrkrEoJkdo7tSRLZmb/Zmgp2wARAQAB
tChMYXVyaW4gSGFnZW1hbm4gKHByaXYpIDxsYXVyaW5oZ0BnbXguZGU+iQJVBBMB
CgA/AhsDBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgBYhBNTe458o1Pr66+mJyJMF
9xHAQy4EBQJdimC0BQkIv9w0AAoJEJMF9xHAQy4Ed1UP/0gHxxM6LFDv87OaMvf3
dU0BlVAzGtS9B5icNmaEo+4avTywyEl/G//UL134bll9lQBkxzQeQheINxJ4MRTM
f/9lkigZA0pmY5VS29x9hidO6N8YfvDomYwzan6oZb+/8lgDru749zIGRbvGs/WT
IE8vrGP65/MEPbQ0Ok+57JYHh0DhOLGGVEO9eJE3QWsVyHiPXjaNILkDeOxHjK+u
wfyqx5VVDNtKqTbNsUCTu0M8g/jtwWbBl/EvhvzbkHrbEnL/7Yz421wN1gCreYZL
e3mEh/3aHo/TKqm8rG1EeLoD6PQbNVJQj0/wVUzwRS85R2us4ozy13G79AbS27qe
hEUc+4UJeN45h4LXTXzHrI/zQ3Ge14QhfeF+g0OMMC8F/yU9Mx8vGbR8p+6K3Z+L
mShIy6v8Vxg4HgM3gEkoQM8zRhSsjQrBzeuy1XZWsFRUuNmHylAW/oRCfKECg9jr
ZrDOUHxqunarGPGQp4LXfQiMnN3PrKoxHo0Cs1qT/j7J6qxjal9N5F4IwsRPbRAb
Of1j06IUi5e86+3oK2/27sjBS286TPTuuKr0RHU9iOJWHzsgKvCnyZfi1gHlluxI
OqMBvAu1Zs8NcWS6nvSkcIQLUwKiqEQMR3ePZmAP16dtZAV32/2alXQgD121uSZ0
00To44F8DrNB8Zx78bQ63reuuQINBFiM64ABEADzLYr10BFIdqpeiw21IPLXbChz
RfIxEV3xq4UlwtIdAoSTtQOm0AHfiweSJb1PeRMV9LAmu8UJZbhbLnZvDU4p/ecv
XN3dkrxhde9GqQZDij6WdYb2ZDtQG1uk4f1BrOACojP0KxgOEsRS5a8GRnl5GZXJ
gJb3+kpiM0o5OUockxtuSgH8eQimlkPlVDjTs92wQs0ZQgM8xdu0H7pQy36u9/wi
bhMQXWXHaUWmjQDnenRc8QFi3kNUsrzIRiKLgjWqHHGmKCce+FWvm7OQg32f/1r4
n6OViIZwCevjCrsTGv/WcxP6vev2upk8G6nOpucIt4XnUPTnMEE7hXRSE4lasUtG
kWaMATxheKk5su3+PzmsquG7tn5tgvikMZ0Ft0iTkWFez3IS1FA55+H4AW2zIl04
RkX6yhjRpud1mUwjFCBXU65g5BmVsyTuCMG5QhzkuiA9Sj9rYAQgqQITXVzRYxD7
eGhWJX6XtYOlUUKMOx32KMTLATqdkb59XdQ5/23gw6n/6GAlAgyu3fLNTYFwr60L
rRPcwtqwZENO7Bgm79lI6Ibn+oFrXY3C8UIbB7gJzLqbXgTzzGjDwM97+nWLc+B9
eGCu2C1UGXAuGfaZbpnYTF4vgoNzXeI0UpnQMmFmZgIuJRxZ9YJcZRsTVp0xc6SB
gQ20KoSWQKQvigE9HQARAQABiQI8BBgBAgAmAhsMFiEE1N7jnyjU+vrr6YnIkwX3
EcBDLgQFAl1cI0wFCQW8hcwACgkQkwX3EcBDLgRgGA/+Lz4ahjcNlpoQLZH/LVAE
y6lEj50YuVnWlVy2+08IsXEWtQFC+OCf1yahxynUQFg9EUJGkwGVkp6pOhQJhkYj
fDETv0T7CdKAY2qIKkIaJFFTORlDLpBtBB3bdYxZ9DlU4Yfv4Nsbs2RrHXZPp7x1
6dpoI3Yf9XG1CodhN6ez1X/BuiKeKFURb/pb6XhfSCGuSqgPoFmDMYDyJI2Qa+h2
cTaQVnBXoWHlC269u5kfiE1OLNjbhZs2tgx4sGjARI3eL1uj48A3lcGZpD05TZtx
Q6E57+hcd+IFh6In8ai8EarMv3jbx1lIY/qNvf9IwrLxIyCm5iVglbDOzsvMTDbo
dwkjaWil8Gj5GHtFPNHRLynqHgWCcPHPqzQ0GjGQ4IRitqS7Ysmd7GAQBnrdTWOX
HL1O3K9qNndFXYbCUTxy3rDTptm5eZ9iK1GyBP4m0M4tDIwmWxLySL71XMCpiJsj
5MM+2IfVVFu9th3RTAFFvdq+kDp95MXAxoBfKG+fvzUP6g2++5eiwBZaviA5+kBr
iFn6mHi1ul96Jm9auUd2QJvirWk5yxEaczwpWZBW7byyo4dIOeKzi4mwtpFCfWWl
T3BMYHPN0JY9KxJiVAviUFmCqseQuSYP+/wvnslGrFYotEDUS5g5gIApdut9xOKm
CYjPkDA2K1CR/XA27Y87NWg=
=lXQM
-----END PGP PUBLIC KEY BLOCK-----

Control: owner -1 !

Hi!

time flies, I guess, but I guess better a late reply than none at all.

rustc and cargo are in reasonable shape nowadays, while not in freeze the
toolchain is usually not far behind the last upstream stable release, and
the day to day business is not too troublesome in that area.

that being said - help is always welcome, both in the toolchain and in the
broader Rust packaging team. the toolchain packages themselves do require
a quite substantial commitment and a certain level of technical knowledge
and the desire to dig deep if and when needed. as such, it is probably not
the best area to start contributing as a beginner (unless you are really
motivated, patient and have a lot of time ;)). if you already have quite
a bit of experience with either rustc itself, or other, similarly complex
toolchains (or their packaging), it's probably easier to get going.

anybody who is interested to help out or get involved, please don't
hesitate to contact me or the Debian Rust team, either here in this bug,
over on IRC in #debian-rust or on our discussion mailing list:

debian-rust@lists.debian.org

thanks!
Fabian