Hi, On Thu, Nov 12, 2020 at 07:08:26PM +0100, wf...@niif.hu wrote: > Moritz Mühlenhoff <j...@inutil.org> writes: > > > On Sat, Nov 07, 2020 at 08:56:38PM +0100, wf...@niif.hu wrote: > > > >> I propose a security upload with the debdiff below. The patch series > >> posted by upstream against 2.0.3 applies cleanly to the buster source, > >> and is hereby included. I'll try to do some testing while you review. > > > > Thanks, this looks. I also compared the upstream 2.0.3 patch set against > > the update Ubuntu released for their 20.4 release (which also ships > > 2.0.3) and which is identical (and without reported regressions so far) > > Cool. One can't possibly test all relevant use cases here. > > > Please upload to security-master if your tests were fine as well > > Done. I managed to provoke some of the new denials with the updated > package, and basic cluster operation remained unperturbed. > > I think the changelog entry will work well enough as the DSA text. > The LTS update used a shorter version, which is fine as well. > > > (and remember to build with -sa since pacemaker is new in > > buster-security (ftp.debian.org and security.debian.org don't share > > tarballs) > > The --source-only-changes switch of sbuild seems to counteract -sa, but > I tried to revert that with changestool. Hope it's fine. If only I > also remembered to remove the buildinfo file... Or is that problem > fixed already?
Just quickly commenting on that: Yes the buildd now append a suffix so that there will be no clash with the potential uploaded _amd64.buildinfo (I have recently seen one buildd which did not yet did so, but I hope this is fixed as well yet). So yes, does not matter anymore if you have an _amd64.buildinfo in the source only. If still we trigger the issue, we will do our package reinject dance one time :) Regards, Salvatore
