Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758240AbcJYLgI (ORCPT ); Tue, 25 Oct 2016 07:36:08 -0400 Received: from mail-oi0-f68.google.com ([209.85.218.68]:35105 "EHLO mail-oi0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754592AbcJYLgF (ORCPT ); Tue, 25 Oct 2016 07:36:05 -0400 MIME-Version: 1.0 In-Reply-To: <20161025024959.GL42084@redhat.com> References: <20161024182503.GH42084@redhat.com> <20161024212754.GI42084@redhat.com> <20161024231846.GK42084@redhat.com> <20161025024959.GL42084@redhat.com> From: Josh Boyer Date: Tue, 25 Oct 2016 07:36:00 -0400 X-Google-Sender-Auth: 5l2Uowdza8-P_GQHBDq8XAS8G1U Message-ID: Subject: Re: Linux-4.X-rcY patches can't be applied with git? To: Jarod Wilson Cc: Linus Torvalds , Linux Kernel Mailing List , Greg Kroah-Hartman Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2477 Lines: 52 On Mon, Oct 24, 2016 at 10:49 PM, Jarod Wilson wrote: > On Mon, Oct 24, 2016 at 05:06:42PM -0700, Linus Torvalds wrote: >> On Mon, Oct 24, 2016 at 4:18 PM, Jarod Wilson wrote: >> > >> > But in that case, what if your patch generation script used a filter to >> > exclude those binary files? No harm to that target audience, and it would >> > actually make them behave better for distro builds. Though that might be >> > counter to the goal of making them disappear entirely. :) >> >> Heh, I'd rather people get the warning that "oops, something is >> incomplete". They can still work with the end result, but at least >> they got some indication that hey, that patch didn't work wonderfully >> well... >> >> To be honest, I really would like to not do the tar-balls and patches at all. >> >> But maybe rather than saying "it's only for legacy 'patch' users", I >> could just say that it's getting phased out, and say "you have to use >> 'git apply' to apply them". >> >> Then I could just enable "--binary" and "-M", and see what happens. > > I like this idea! > >> I suspect that these days, git is so ubiquitous that it's ok. >> >> And then in a few years, maybe I can just stop doing patches entirely, >> having proved the point that everybody already has git ;) > > Honestly, the only people that don't have access to git to pull down > kernel sources? People who haven't yet got a kernel up and running, who > will probably get there via a distro kernel. ;) Possibly. And to your earlier idea of generating our own diffs, we do that for the subset of git snapshot builds we do in Rawhide between the -rcX releases. The problem with doing that all the time for everything is that today the -rcX patches are signed by Linus. Doing it ourselves means they aren't. Fedora/other distros could have the maintainers sign their generated diffs but it loses some of the verification chain. > Side note in favor of tarballs: I know Fedora likes upstream to have > tarballs, with checksums provided, so that packages can be verified to > contain a legitimate upstream source tarball, rather than a random tarball > created by the packager that could have some extraneous bits (possibly > malicious) added to them. One can certainly examine and validate a > generated tarball too, but it's a fair bit more work than just "does the > checksum match?" and not as easily automated. Right, this and the signing issue I pointed to above. josh