Daniel Kahn Gillmor wrote: > Hi Robert-- > > thanks for the followup! > > On Wed 2020-10-28 02:56:55 -0400, Robert Edmonds wrote: > > I've never been able to reproduce this bug, but your branch looks good > > to me as far as backporting this commit to 1.9.0. It's commit > > 225534e5ab22d16ab32fa1011733f3c69c7b28ba in the upstream repo which was > > released in 1.9.1. I don't have any objection if you want to propose a > > stable update for unbound with just this fix. Personally I've been > > keeping unbound in buster-backports up to date with testing lately and I > > don't have any buster machines running the version of unbound in buster > > :-) > > Over on https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=4227 > upstream suggested two different things: > > - upgrade to 1.9.2, (which incorporates this and several other bugfixes), or > > - cherry-pick a list of other commits which they think are also > relevant to this specific fix: > > 348cbab016f824a336b65d0091310fe5cd58e762 > 2b47ca080eb91e209fb86cd1dc90a6aff32e2a1f > > and four more, related to spoolbuf: > > 0b77c9d6763686264d44dfd926c8cb4f2f03a43a > 6067ce6d2b82ce2e80055e578fdfd7ba3e67c523 > af6c5dea43fc63452d49b2339e607365b6652987 > a08fe8ca609b651c8d8c8379780aad508d492421
OK, I made a patch incorporating those fixes recommended by upstream and sent them to #962459. Looks like that doesn't work at all. > I'm assuming that the release team would prefer that we go the latter > route (cherry-picked patches), but i haven't tried to get a direct > verdict from them on that. If I recall correctly, back when lenny was oldstable, a major upstream update (1.0.2 → 1.4.6) was allowed in order to correct a security problem that was infeasible to backport. I don't think we could justify pushing the latest upstream version into stable, but I'm not sure picking a random 1.9.x release is the right thing either. Upstream recommends that users run their latest release because every new release contains bug fixes and improvements, of course. So I'm fine with uploading each new upstream release to unstable and then (five days later) to buster-backports, for users that want to run the latest upstream release on buster. I don't think there's a particularly strong justification for Unbound users to run whatever random version was current ~6 months before a Debian stable release other than, well, that's what Debian stable shipped with. > I confess i don't really understand the way that unbound's buster > packaging is working -- i think it's neither git-dpm nor gbp -- so i > don't exactly know how i'd assemble an update for the next buster point > release without overhauling it. (i'd be fine with overhauling it to use > gbp (as i think the unstable version of the packaging is) as long as > you're ok with that, but i also don't know whether that would make the > changes more unpleasant for the release team. > > Any suggestions? Overhauling the packaging in the buster branch would probably make things unpleasant for stable reviewers, so I would not recommend doing that. The way the packaging works in buster is that patches to the code are directly applied to the git repository and the "single-debian-patch" option is used. Like, if you want to make a change, you just make the change, and the changes are stored in git, instead of using git to store patch files that contain the changes. Apparently this is bad because there is tooling that interacts very poorly with this style of packaging (I think it's gbp-import-orig's '--merge-mode=replace' which intentionally destroys all the changes outside the debian/ directory). I think that was the root cause of #923314. -- Robert Edmonds edmo...@debian.org
