[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: wheezy update of openafs



On Tue, Jan 23, 2018 at 06:52:52PM +0100, Emilio Pozuelo Monfort wrote:
> On 23/01/18 17:29, Benjamin Kaduk wrote:
> > Hi all,
> > 
> > As recorded in #886799 (and the merged bugs), the recent linux
> > kernel updates including meltdown remediation also included a kernel
> > ABI change that breaks the openafs DKMS module (and non-DKMS module,
> > for what it's worth).  The fix for openafs is pretty simple; just
> > cherry-pick a couple of upstream patches, but it's not entirely
> > clear that this update should be considered a "security issue", and
> > thus I am unclear on what process at
> > https://wiki.debian.org/LTS/Development really applies.
> > Should I just find a DD to sponsor the upload to wheezy-security and
> > get the new package available, or is there some additional (review?)
> > step as there would for a non-LTS security update or SRU?
> 
> We could do some sort of a regression update. Or just a compatibility update.
> Call it what you want :)
> 
> Can you point to those patches?

I just pushed my current state to the packaging git repo at
https://anonscm.debian.org/cgit/pkg-k5-afs/openafs.git/log/?id=refs/heads/wheezy
, though I was planning to do a little more testing with a clean
build/etc. before requesting upload.

Note that the last several updates to openafs in wheezy were done by
the LTS team directly and not put into git, so I have some cleanup
commits to attempt to synchronize the state in git with the state in
the apt repo.  It seems that with the single-debian-patch scheme
openafs uses in wheezy, the debian-patch that is generated is not
done reproducibly, with files being changed appearing in different
order.  The extracted source package does not differ other than the
debian-changes file, though, which is I think as good as we can get.
(Starting with jessie we switched to using separated patches for
openafs.)

Thanks,

Ben


Reply to: