The developer's reference says [1]:

  A repackaged .orig.tar.{gz,bz2,xz} [...] *should not* contain any file
  that does not come from the upstream author(s), or whose contents has
  been changed by you.

My recent attempt to upload grub2 2.02-3 was rejected due to, which I admit I've been putting off
dealing with for a while; but the relevant tag
(license-problem-non-free-RFC) was added to the ftpmaster auto-reject
list a while back.  I considered overriding it temporarily, but I don't
think I have a very good reason for doing so.  I also cannot simply
remove the relevant file in this case (a CRC implementation), as doing
that would break too many existing parts of GRUB.

Fortunately, libgcrypt upstream implemented unencumbered replacement CRC
code a while back, and over the weekend I worked on backporting this to
the version of libgcrypt imported into GRUB [2].  I'm not sure when I
should expect this to be actually reviewed upstream and committed to
master, as review has been pretty slow of late, but I think it's a safe
and reasonable patch given that it's a pretty clean backport.

I considered just applying this as a patch in debian/patches/, but of
course that's still distributing the encumbered file in the
.orig.tar.xz, and Lintian just issues license-problem-non-free-RFC about
the patch file instead.  (Again, I could override this, but it seemed
questionable to do so.)  So my proposal is to commit this patch to my
"upstream" git branch, prepare grub2_2.02+dfsg1.orig.tar.xz from that
branch, and document this in debian/copyright and debian/README.source.
However, I know it's a bit unconventional to change files in a +dfsg
tarball rather than merely deleting them, and I can't meet the
recommendation of the developer's reference above.

Does this seem like a reasonable way forward, or should I instead just
apply the backport as an ordinary patch and override
license-problem-non-free-RFC for the patch file?



Colin Watson                                       []

Reply via email to