[Pkg-rust-maintainers] rust ecosystem worries of a release team member
infinity0 at debian.org
Thu Jan 9 13:38:53 GMT 2020
> Hi all,
> On 05-01-2020 14:39, Ximin Luo wrote:
>> Paul Gevers:
>>>  Now thunderbird is blocked by rust-cbindgen (last version migrated
>>> in September with uploads since October), which is blocked by rust-syn
>>> (last version migrated in July, with new uploads since August). Involved
>>> is rust-proc-macro2 (last version migrated in July, with new uploads
>>> since August (and currently triggers an autopkgtest regression)),
>>> rust-unicode-xid (which has been trying to migrate to testing since
>>> August), rust-quote (trying to migrate since August). And I may be
>>> missing others. rustc was involved at some moment, cargo was involved
>>> (and FTBFS for some time) etc...
> And today another firefox-esr, with CVE fixes, appeared, which is also
> blocked by this.
I just had a look, and both firefox-esr and thunderbird still are vendoring their own rust source code in third_part/rust/* and make no attempt to integrate with dh-cargo or our cargo-debian-wrapper in d/rules in the way that I prescribe here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907629#30
So their current build-dependencies on any librust-* packages are bogus, and can simply be dropped to progress with migration.
Likewise, rustc and cargo are purposefully designed to vendor their own crates, and *not* depend on any librust-* packages, and so they shouldn't affect migration either.
>> As discussed in #debian-release, this huge migration involving
>> unicode-xid, proc-macro2, etc, is blocked on some packages in NEW as
>> well as other things including the autopkgtests.>
>> Please be aware that rust autopkgtests are a new experimental thing
>> and as such will take a while to iron out. After that though, future
>> stuff should be much easier.
> If it really helps migrating this lot sooner, I am willing to accept
> *new* autopkgtest results that fail (so no regressions) if you'll keep
> on working to fix it. If so, please let me know which ones.
Well, I'm pretty sure most of the regressions are "there used to be 0 tests, now there are >0 tests that fail". This is not specific, this is a general change done to debcargo between versions 2.2 and 2.4, so I do not have specific names to give you. Perhaps you can simply count "there used to be 0 tests, now there are >0 tests that fail" as "not a regression"?
>> To help this process, is there a way we can mass-download all the
>> logs of all the failures? I basically want to grep all the rust-*
>> failure logs for ^error, and group them per source package. That way
>> it'll be easier to see which things we have to automate solutions
>> for, and which things we can get away with a manual override.
> As discussed on IRC, there is the excuses.(html|yaml) file that helps
> with that. At least for migration blocking items.
> Note, rust-debcargo (with your autopkgtest improvements) is also having
> issues to migrate (due to rust-cargo, rust-git2, rust-glob, rust-im-rc,
> rust-toml, rustc).
Yes I'm aware of that. I wrote a script to output stuff in more detail a few days ago. The current migration status is being tracked here:
More information about the Pkg-rust-maintainers