Re: Repackaging upstream source with file modifications?

2018-02-17 Thread Colin Watson
On Mon, Feb 12, 2018 at 10:28:33AM +, Colin Watson wrote: > 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? Thanks for the feedback, everyone. While I do like

Re: Repackaging upstream source with file modifications?

2018-02-13 Thread Raphael Hertzog
Hi Colin, On Mon, 12 Feb 2018, Colin Watson wrote: > 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

Re: Repackaging upstream source with file modifications?

2018-02-12 Thread Andreas Metzler
Dimitri John Ledkov wrote: > On 12 February 2018 at 10:28, Colin Watson wrote: [...] >> My recent attempt to upload grub2 2.02-3 was rejected due to >> https://bugs.debian.org/745409, which I admit I've been putting off >> dealing with for a while; but the

Re: Repackaging upstream source with file modifications?

2018-02-12 Thread Ole Streicher
Wookey writes: > On 2018-02-12 14:11 +0100, Jonas Smedegaard wrote: >> The tarball should contain only upstream code. Not patched code (then >> you arguably are making a fork). > > But we are encouraged to fork vigorously and often these days > (github...I'm looking at

Re: Repackaging upstream source with file modifications?

2018-02-12 Thread Wookey
On 2018-02-12 14:11 +0100, Jonas Smedegaard wrote: > Quoting Colin Watson (2018-02-12 13:18:04) > > On Mon, Feb 12, 2018 at 12:09:50PM +, Wookey wrote: > > > I'd have done the same as Simon. The main advantage is that it makes > > > the tarball free software, which we generally don't get any

Re: Repackaging upstream source with file modifications?

2018-02-12 Thread Jonas Smedegaard
Quoting Colin Watson (2018-02-12 13:18:04) > On Mon, Feb 12, 2018 at 12:09:50PM +, Wookey wrote: > > On 2018-02-12 11:22 +, Colin Watson wrote: > > > Huh. I hadn't thought of that option, but it seems peculiar and > > > excessively baroque (it basically splits the patch into a remove and

Re: Repackaging upstream source with file modifications?

2018-02-12 Thread Dimitri John Ledkov
On 12 February 2018 at 10:28, Colin Watson wrote: > 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

Re: Repackaging upstream source with file modifications?

2018-02-12 Thread Colin Watson
On Mon, Feb 12, 2018 at 12:09:50PM +, Wookey wrote: > On 2018-02-12 11:22 +, Colin Watson wrote: > > Huh. I hadn't thought of that option, but it seems peculiar and > > excessively baroque (it basically splits the patch into a remove and an > > add, making it less obviously identical to

Re: Repackaging upstream source with file modifications?

2018-02-12 Thread Wookey
On 2018-02-12 11:22 +, Colin Watson wrote: > On Mon, Feb 12, 2018 at 10:42:16AM +, Simon McVittie wrote: > > On Mon, 12 Feb 2018 at 10:28:33 +, Colin Watson wrote: > > > Fortunately, libgcrypt upstream implemented unencumbered replacement > > > CRC code a while back, and over the

Re: Repackaging upstream source with file modifications?

2018-02-12 Thread Colin Watson
On Mon, Feb 12, 2018 at 10:42:16AM +, Simon McVittie wrote: > On Mon, 12 Feb 2018 at 10:28:33 +, Colin Watson wrote: > > 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. > > > >

Re: Repackaging upstream source with file modifications?

2018-02-12 Thread Simon McVittie
On Mon, 12 Feb 2018 at 10:28:33 +, Colin Watson wrote: > 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