Bug#969609: rust-zstd: unbuildable, uninstallable, depends on non-existent rust-zstd-safe
Hi, rust-zstd-sys 2.0.1 has been ACCEPTED, rust-zstd-safe 5.0.2 is in NEW. rust-zstd should follow. -- Sdrager, Blair Noctis OpenPGP_signature Description: OpenPGP digital signature
Bug#969609: rust-zstd: unbuildable, uninstallable, depends on non-existent rust-zstd-safe
The rust-zstd package has both a dependency and a build-dependency on librust-zstd-safe-2.0.3+experimental-dev, which does not exist anywhere in Debian. Presumably it would be built by a rust-zstd-safe package, but no such package exists, including in the Debian NEW queue. Specifically looking through the mailing list archives. rust-zstd-sys, rust-zstd-safe and rust-zstd were all uploaded to NEW in mid January 2020. In late Febuary 2020 the ftpmasters processed the uploads, zstd was accepted but zstd-sys and zstd-safe were rejected. zstd-sys and zstd-safe were re-uploaded to new in march 2020 and rejected again in may 2020. zstd-sys was once-again uploaded to NEW in october 2020 and this time was accepted. At around the same time a source-only upload of zstd was also made, but zstd-safe was not touched. The route to fixing rust-zstd, thus involves fixing the ftpmaster's objection to the previous upload, checking the package for any other such issues and if-so fixing them and then re-uploading it. The reject mail can be found at https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2020-May/012388.html
Bug#969609: [Pkg-rust-maintainers] Bug#969615: Bug#969609: rust-zstd: unbuildable, uninstallable, depends on non-existent rust-zstd-safe
Hello, Le 11/09/2020 à 21:11, Steve Langasek a écrit : Ximin, So no, I will not stop filing bugs against RC-buggy packages that the Rust maintainers are clearly not taking care of. If you don't want bug reports, you have the option to stop uploading packages that are RC buggy from the moment they're accepted into the archive. I am not interested by a long debate but I would like to thank for reporting these bugs (same for Lucas's). They have been very valuable to me as it is hard to identify which packages regressed or not. I have some private CI to verify that the rust-based binaries can still build but I cannot do that on all rust- packages. The rust-freeze from FTPmasters doesn't help to keep the tree in a clean state. I have been spending a few hours today to fix RC which were clearly impacting end user programs. So, again, thanks! Cheers, Sylvestre
Bug#969609: [Pkg-rust-maintainers] Bug#969609: Bug#969609: rust-zstd: unbuildable, uninstallable, depends on non-existent rust-zstd-safe
Steve Langasek: > Ximin, > > On Tue, Sep 08, 2020 at 09:23:49PM +0100, Ximin Luo wrote: >> You keep filing these same bugs. I have told you this many times before >> already: this is just how rust packaging works, Britney's migration policy >> already prevents these packages from reaching Debian Testing, so there is >> no problem, no users are affected. > >> You filing these bug reports accomplishes nothing, except delay & annoy >> other Rust packagers who forget to close these pointless bugs, thereby >> unnecessarily blocking any fixed packages from actually reaching Debian >> Testing. Oftentimes the fix is also not to update the package itself, but >> to upload another package. Due to the idiosyncracies of the BTS, not >> everyone knows how to close these bugs correctly (notfound -1 $version) >> and it will result in further delays. > >> Please stop filing these bug reports, they only create extra unnecessary >> work for other people, and make Debian worse for users, by slowing down >> the stream of fixes. Britney already prevents Testing migration. > > It is not credible to me that this is "just how rust packaging works". The > bugs I am filing are against packages that have been uninstallable in > unstable for more than 4 months. The missing dependencies are not in the > NEW queue, and there are no ITP bugs filed for them. There is no reason to > believe, without filing these bugs, that anyone on the rust packaging team > is doing anything about these missing dependencies. > Why is it not credible? I am one of the main members of the team, and created about 80% of the current process. I am telling you it is simply how it works. If you want an in-depth description, see https://github.com/kpcyrd/cargo-debstatus/issues/2. In summary, it is because the Rust dependency system encodes complex dependency relationships in a more efficient way than the Debian dependency system, meaning the typical Rust package expresses more complex dependencies than most other Debian packages. But you can get this type of situation with other languages too, especially those with bootstrap loops. The only difference is in Rust it's much more common. (The NEW queue is another unresolved issue that is blocking Rust packaging - we have a policy disagreement with the FTP team and nobody has had time to resolve it. That is why things might not be on the NEW queue.) At the end of the day, it doesn't matter if people don't do anything about these missing dependencies, because *the britney migration script prevents migration to testing*. For the packages that matter, i.e. that need to be migrated to testing (& eventually stable), members of this team are forced to fix these issues anyway, and we have a documented process for doing this: https://salsa.debian.org/rust-team/debcargo-conf/-/blob/master/RELEASE.rst > And filing bug reports in the Debian BTS is the standard way in Debian to > document bugs in packages. > > And it is unacceptable that Debian maintainers don't know how to operate the > Debian BTS. > Most Debian Rust Team members are not regular Debian maintainers. And the Debian BTS user interface is really unintuitive. So I can't reasonably consider it "unacceptable", we have to be realistic regarding volunteer on-boarding. > So no, I will not stop filing bugs against RC-buggy packages that the Rust > maintainers are clearly not taking care of. If you don't want bug reports, > you have the option to stop uploading packages that are RC buggy from the > moment they're accepted into the archive. > I am explaining to you why the normal Debian process is inadequate and causes more work for everyone in this case. Please trust your fellow maintainers more on matters on which they have more expertise. After all of my explanations, what benefit do you suppose these bugs are giving?? You filing bug reports is not going to magically give people more free time to fix them; when they have the free time these problems are automatically and forcibly solved as part of our regular process. The bugs do not help this one bit. Best Ximin -- GPG: ed25519/56034877E1F87C35 https://github.com/infinity0/pubkeys.git
Bug#969609: [Pkg-rust-maintainers] Bug#969609: rust-zstd: unbuildable, uninstallable, depends on non-existent rust-zstd-safe
Ximin, On Tue, Sep 08, 2020 at 09:23:49PM +0100, Ximin Luo wrote: > You keep filing these same bugs. I have told you this many times before > already: this is just how rust packaging works, Britney's migration policy > already prevents these packages from reaching Debian Testing, so there is > no problem, no users are affected. > You filing these bug reports accomplishes nothing, except delay & annoy > other Rust packagers who forget to close these pointless bugs, thereby > unnecessarily blocking any fixed packages from actually reaching Debian > Testing. Oftentimes the fix is also not to update the package itself, but > to upload another package. Due to the idiosyncracies of the BTS, not > everyone knows how to close these bugs correctly (notfound -1 $version) > and it will result in further delays. > Please stop filing these bug reports, they only create extra unnecessary > work for other people, and make Debian worse for users, by slowing down > the stream of fixes. Britney already prevents Testing migration. It is not credible to me that this is "just how rust packaging works". The bugs I am filing are against packages that have been uninstallable in unstable for more than 4 months. The missing dependencies are not in the NEW queue, and there are no ITP bugs filed for them. There is no reason to believe, without filing these bugs, that anyone on the rust packaging team is doing anything about these missing dependencies. And filing bug reports in the Debian BTS is the standard way in Debian to document bugs in packages. And it is unacceptable that Debian maintainers don't know how to operate the Debian BTS. So no, I will not stop filing bugs against RC-buggy packages that the Rust maintainers are clearly not taking care of. If you don't want bug reports, you have the option to stop uploading packages that are RC buggy from the moment they're accepted into the archive. > Steve Langasek: > > Source: rust-zstd > > Version: 0.5.1-1 > > Severity: grave > > > > The rust-zstd package has both a dependency and a build-dependency on > > librust-zstd-safe-2.0.3+experimental-dev, which does not exist anywhere in > > Debian. Presumably it would be built by a rust-zstd-safe package, but no > > such package exists, including in the Debian NEW queue. > > > > The binaries of rust-zstd that are in Debian were clearly not built on the > > autobuilders, and all other architectures besides amd64 are unable to build > > this package. > > > > > > ___ > > Pkg-rust-maintainers mailing list > > pkg-rust-maintain...@alioth-lists.debian.net > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-rust-maintainers > > > > > -- > GPG: ed25519/56034877E1F87C35 > GPG: rsa4096/1318EFAC5FBBDBCE > https://github.com/infinity0/pubkeys.git -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Bug#969609: [Pkg-rust-maintainers] Bug#969609: rust-zstd: unbuildable, uninstallable, depends on non-existent rust-zstd-safe
Steve, You keep filing these same bugs. I have told you this many times before already: this is just how rust packaging works, Britney's migration policy already prevents these packages from reaching Debian Testing, so there is no problem, no users are affected. You filing these bug reports accomplishes nothing, except delay & annoy other Rust packagers who forget to close these pointless bugs, thereby unnecessarily blocking any fixed packages from actually reaching Debian Testing. Oftentimes the fix is also not to update the package itself, but to upload another package. Due to the idiosyncracies of the BTS, not everyone knows how to close these bugs correctly (notfound -1 $version) and it will result in further delays. Please stop filing these bug reports, they only create extra unnecessary work for other people, and make Debian worse for users, by slowing down the stream of fixes. Britney already prevents Testing migration. Ximin Steve Langasek: > Source: rust-zstd > Version: 0.5.1-1 > Severity: grave > > The rust-zstd package has both a dependency and a build-dependency on > librust-zstd-safe-2.0.3+experimental-dev, which does not exist anywhere in > Debian. Presumably it would be built by a rust-zstd-safe package, but no > such package exists, including in the Debian NEW queue. > > The binaries of rust-zstd that are in Debian were clearly not built on the > autobuilders, and all other architectures besides amd64 are unable to build > this package. > > > ___ > Pkg-rust-maintainers mailing list > pkg-rust-maintain...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-rust-maintainers > -- GPG: ed25519/56034877E1F87C35 GPG: rsa4096/1318EFAC5FBBDBCE https://github.com/infinity0/pubkeys.git
Bug#969609: rust-zstd: unbuildable, uninstallable, depends on non-existent rust-zstd-safe
Source: rust-zstd Version: 0.5.1-1 Severity: grave The rust-zstd package has both a dependency and a build-dependency on librust-zstd-safe-2.0.3+experimental-dev, which does not exist anywhere in Debian. Presumably it would be built by a rust-zstd-safe package, but no such package exists, including in the Debian NEW queue. The binaries of rust-zstd that are in Debian were clearly not built on the autobuilders, and all other architectures besides amd64 are unable to build this package. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
