DebConf20 Rust BoF (ad-hoc session, called by Wookey) Please ask on #debian-rust (IRC) for the URL to our meeting on Jitsi. == Participants == Wookey director (?) == Issue with new packages getting stuck in the NEW queue? == In archive: 14,148 binary packages with 2001 package+feature from 767 source packages Q: 14k or 1.4k? NEW status 2020-08-26. 27 packages rust-jemallocator 10 months rust-num-traits 8 months 7 months : 4 6 months: 2 5 months: 3 4 months: 4 3 months: 11 Summary by DKG is useful: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945542#94 Draft notes during the meeting: (sorry, I am not very good at taking notes - foka) Bastian: ... Wookey: Why do we do NEW for binary packages? B: Because the FTP team is not only responsible for license compliance but also archive content, namespacing, and so on, so we look at every binary package to ensure it is usable. W: Can we have a mechanism to... B: There might be one, but we came to the decision that the Rust team would not have that decision. W: .. the new binaries, just artifacts, since like that is not a good time for people to spend time on... B: Someone from the Release Team thought of removing the whole Rust packages and re-introducing them bit-by-bit... because n.. Eriol: W: So B: They thought about it, because tooling wasn't able to cope. The ___ team looks to ... hard to deal with how Cargo works. W: Rust supports dynamic linking, but it is not stable yet. This is a Cargo-specific problem because it creates new packages by feature. Feature creep. Leads to an explosion of binary packages. (Go does not appear to have this exact same problem.) Eriol: Regarding the cycles... upstream project... cargo... crates.. ... collapse all these features into one binary package instead of many ???? ... but it is versioning, and feature... we try not to have too many versions of something. Cargo's naming(?) does not quite map itself nicely to Wookey: JavaScript people do this all the time, but obviously it is wrong. We have been doing this in Debian for a long time, but.... it is manual work, it is more work, instead of .... too many... automatic translation it works, but it is not very Debiany, and it annoys the FTP masters, which is not a good thing. I do not have the answer to this, but... == Issues with Static Linking == seems we have much commonality with the Go people in terms of issue with static liking, and similar tooling to deal with it. At least one go person will attend, and a 'statically-linked languages BoF' has been mooted for later this week 'issues with static linking' siretart pointed me to: https://wiki.debian.org/StaticLinking nodens pointed me to https://lists.debian.org/debian-go/2020/01/msg00060.html Note taking during the meeting (around 14:22 UTC): Reinhart: What is the tooling about rebuilding packages, there is a new upstream version, security updates, requires identifying, requirng the whole subset to be rebuilt, etc. Eriol: Cargo... Debian package sources into a subfolder,... --- Built-Using? E: .. we just rebuild packages containing executables, "leaf packages" so-to-speak. W: What do the Go people too? Reinhart: the .. X-Cargo-Built-Using... binNMU... full-dependency rebuild... well, then in what order? Forceful re-upload? Well, we don't actually need to do ... Surprising that Rust can (Guillem: uploading "rebuilds" for binaries containing just sources does not seem needed, as rebuilding these seems more like a QA tool than something the binary with source package would need, except if it generates sources during the build I guess.) (which is what happens for protobuf that has generated headers...) (but that would be the exception? or is this really general? :) -- indeed, that's a cornercase W: Haskell people ... built themselves... and it seems to work B: Haskell has a different problem, has to start from the bottom with the compiler... W: B: I am not aware of a universal... for that.. because we don't usually do static linking in traditional languages, so we did not have the problem. W: Debian grew up square pegs, round holes... don't know if we can convince upstream to stop doing it... ; red hat actually rebuilds everything... A lot of it come to 20 years ago when we had limited resources... (Guillem: doing mass rebuilds for languages that support dynamic linking has the problem of potentially hiding binary incompatible changes that could break stuff during, say, partial upgrades.) E: submit merge requests? most response positively and quickly to it. [Sorry, I stop taking notes here] == 14:41: Daniele's self-introduction == W: asks E: People give up packaging because of the issue we have... we need more people, R: similar pictures... people working on core features and security etc. are really hard to come by. E: