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
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
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
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
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
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
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
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
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
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.
> >
> >
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
11 matches
Mail list logo