linux-kernel - Re: Linux 3.2-rc1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+55aFydrFEKUaSV-JPKXqPc63imZVmaVW0n6Ft_YqoWxp7RQQ@mail.gmail.com>
Date:	Mon, 7 Nov 2011 20:26:20 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Al Viro <viro@...iv.linux.org.uk>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Linux 3.2-rc1

On Mon, Nov 7, 2011 at 7:12 PM, Al Viro <viro@...iv.linux.org.uk> wrote:
>
> FWIW, agruen seems to be doing patch(1) development these days; the last
> snapshot has this in NEWS:
>
> * Support for most features of the "diff --git" format: renames and copies,
>  permission changes, symlink diffs.

Oh, good.

> Caveats:
>  + Binary diffs are not supported yet; patch will complain and skip them.
>  + In the "diff --git" format, all the patches are relative to the original
>    state of the files to patch, allowing things like criss-cross renames.
>    GNU patch will currently fail for such patches.

This is all fine. The criss-cross renames are possible, but I don't
generate them: you need to specify the "-B" flag to git to "break"
existing names, and none of my normal kernel patches ever do that. It
can be useful to find cases where people have renamed things on top of
existing files (which does happen occasionally), but on the whole it's
not a big feature.

And the binary patches we've always generated the magical git binary
version of, since there is no traditional format for that at all - and
it has never been a problem in practice. I think the only binary file
we have is the logo, and that one doesn't change.

So it sounds like 'patch' will handle all the cases that are really relevant.

> Hell knows how long until they release it and distros pick the result, of
> course.  Their git tree on git://git.savannah.gnu.org/patch.git is fairly
> quiet; there had been a bunch of local fixes since the last snapshot (this
> April) but not much else...

It sounds like I should continue to do the traditional patches for a
while longer, but it does sound like it's an issue that will fix
itself in the not too distant future.  Goodie.

              Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/