Bug#1009888: [Pkg-rust-maintainers] Bug#1009888: rust-h2, existing version is badly broken, new upstream needs new package
On May 1, 2022 7:28 pm, Peter Michael Green wrote: > > On 01/05/2022 14:00, Fabian Grünbichler wrote: >> currently progress is blocked on >> - itoa/serde_json transition (anybody working actively on that?) > > I just uploaded the new itoa to experimental and took a quick look > through the reverse dependencies. > > rust-cssparser - already broken and not in testing. > rust-csv - built/tested fine after patching to use itoa 1, upstream also > has an unreleased change switching to itoa1 with no code changes. > rust-http - fixed version in debcargo-conf (semver breaking, but all > rdeps are broken right now anyway) > rust-hyper - already broken and not in testing. > rust-num-format - already broken and not in testing. > rust-serde-json - fixed version in debcargo-conf (not semver breaking) > rust-serde-urlencoded - fixed upstream (semver breaking, but all rdeps > are broken right now anyway) > rust-time - fixed upstream (not semver breaking) > > I'm not seeing any reason not to go ahead with pushing this to unstable, > anyone have any comments before I go ahead? LGTM - wasn't me who prepared those (itoa / serde_json) though ;) Carlos did, but they seem to not hang out on IRC atm.
Bug#1009888: [Pkg-rust-maintainers] Bug#1009888: rust-h2, existing version is badly broken, new upstream needs new package
On 01/05/2022 14:00, Fabian Grünbichler wrote: currently progress is blocked on - itoa/serde_json transition (anybody working actively on that?) I just uploaded the new itoa to experimental and took a quick look through the reverse dependencies. rust-cssparser - already broken and not in testing. rust-csv - built/tested fine after patching to use itoa 1, upstream also has an unreleased change switching to itoa1 with no code changes. rust-http - fixed version in debcargo-conf (semver breaking, but all rdeps are broken right now anyway) rust-hyper - already broken and not in testing. rust-num-format - already broken and not in testing. rust-serde-json - fixed version in debcargo-conf (not semver breaking) rust-serde-urlencoded - fixed upstream (semver breaking, but all rdeps are broken right now anyway) rust-time - fixed upstream (not semver breaking) I'm not seeing any reason not to go ahead with pushing this to unstable, anyone have any comments before I go ahead?
Bug#1009888: [Pkg-rust-maintainers] Bug#1009888: rust-h2, existing version is badly broken, new upstream needs new package
On April 20, 2022 11:39 am, Fabian Grünbichler wrote: > On April 20, 2022 12:33 am, Peter Michael Green wrote: >> Package: rust-h2 >> Version: 0.1.26-1 >> X-debbugs-cc: d...@jones.dk >> >> I noticed that Jonas had set a number of bugs about broken rust packages as >> blockers of 900928, so I decided to take a look at some of them. I fixed up >> bytemuck, image and related packages. >> >> I then started looking at reqwest which lead me to h2 (which has been broken >> since the tokio 1.x transition but noone ever got around to filing a >> bug) which >> lead me to http which jonas recently NMU'd. >> >> I feel I need to comment on the technical details of the NMU, I should >> preface >> this by saying that I don't think it's unreasonable to 0-day NMU a minimal >> fix for a long term RC issue, even if (as was not the case here but was the >> case for some of the other NMUs noone ever bothered to actually file the >> RC bug). >> >> However, this NMU did considerably more than just add a minimal fix for >> the rc issue. Most painfullly, the "orig" tarball for the new upstream >> version >> appears to have been derived from upstream git rather than from crates.io >> and this breaks our workflow. If you are going to 0-day stuff please keep >> your uploads minimal. If you want to do more invasive NMUs please give >> the maintainers a chance to respond. >> >> Fortunately it seems the answer is to move to an even newer upstream >> version. The only reverse dependencies of rust-http seem to be the >> h2/hyper stack which badly needs an update to move away from tokio >> 0.x. I have already committed the http update to debcargo-conf and may >> upload it at some point. >> >> Unfortunately moving back up the stack I ran into another issue. h2 and >> hyper have grown a new dependency on tracing. While I am I am happy to >> help with fixing existing rust packages, I am reluctant to take >> responsibility >> for a new package unless it's something I personally use. >> >> So this is where I personally tap out on h2/hyper until/unless someone >> packages tracing. > > we use this stack (h2/hyper) downstream, I can take care of it over the > coming weeks. tracing is unfortunately still rather in-flux, so it will > likely see frequent upgrades. okay, just pushed the following to debcargo-conf: - update of hyper - update of httparse - update of http-body - switch of http to iota 1.x currently progress is blocked on - itoa/serde_json transition (anybody working actively on that?) - tracing being uploaded (capitol?) - tower-service being uploaded (NEW, RFS, please upload!) once all of the above is in the archive, the current version of h2 also builds fine ;)
Bug#1009888: [Pkg-rust-maintainers] Bug#1009888: rust-h2, existing version is badly broken, new upstream needs new package
On April 20, 2022 12:33 am, Peter Michael Green wrote: > Package: rust-h2 > Version: 0.1.26-1 > X-debbugs-cc: d...@jones.dk > > I noticed that Jonas had set a number of bugs about broken rust packages as > blockers of 900928, so I decided to take a look at some of them. I fixed up > bytemuck, image and related packages. > > I then started looking at reqwest which lead me to h2 (which has been broken > since the tokio 1.x transition but noone ever got around to filing a > bug) which > lead me to http which jonas recently NMU'd. > > I feel I need to comment on the technical details of the NMU, I should > preface > this by saying that I don't think it's unreasonable to 0-day NMU a minimal > fix for a long term RC issue, even if (as was not the case here but was the > case for some of the other NMUs noone ever bothered to actually file the > RC bug). > > However, this NMU did considerably more than just add a minimal fix for > the rc issue. Most painfullly, the "orig" tarball for the new upstream > version > appears to have been derived from upstream git rather than from crates.io > and this breaks our workflow. If you are going to 0-day stuff please keep > your uploads minimal. If you want to do more invasive NMUs please give > the maintainers a chance to respond. > > Fortunately it seems the answer is to move to an even newer upstream > version. The only reverse dependencies of rust-http seem to be the > h2/hyper stack which badly needs an update to move away from tokio > 0.x. I have already committed the http update to debcargo-conf and may > upload it at some point. > > Unfortunately moving back up the stack I ran into another issue. h2 and > hyper have grown a new dependency on tracing. While I am I am happy to > help with fixing existing rust packages, I am reluctant to take > responsibility > for a new package unless it's something I personally use. > > So this is where I personally tap out on h2/hyper until/unless someone > packages tracing. we use this stack (h2/hyper) downstream, I can take care of it over the coming weeks. tracing is unfortunately still rather in-flux, so it will likely see frequent upgrades.
