On Fri, Jul 13, 2018 at 12:47:50AM -0400, Michael Shell wrote: > On Thu, 12 Jul 2018 08:41:23 +0100 > Ken Moffat <zarniwh...@ntlworld.com> wrote: > > > And the generic command is probably 'git revert 7744ccdbc16f' but > > since I'm not currently bisecting, I'm not sure what state that > > would leave things in. > > > Ken, > > I should have realized that since Hazel was working with the full git tree, > that he could easily revert any commit within git. Duh! > > Hmmmm ... I think what I was thinking was that I didn't trust the results > of the bisection within git (because the identified problem code does not > even seem be active within Hazel's config, and Hazel said he was new to > the bisection process). So, I'm not so sure the commit that is believed > to be the offender really is the guilty party. I was thinking that Hazel > would take the 4.15 source tree (from the official release tarball) and > then manually backout the suspect commit - if that works/boots, then it > is virtually certain we found the problem area (as we didn't depend on > git). >
At the risk of teaching people to suck eggs ... If someone has the git tree (either Greg's stable tree for a particular minor version, or Linus's tree for .0) the suspected commit can be viewed with git show 7744ccdbc16f (in stable trees, backported commits will have a different hash). Assuming that command does show the suspected commit, git show 7744ccdbc16f >/tmp/suspect1 then view /tmp/suspect1 to confirm it, and cat /tmp/suspect1 | patch -p1 -R --dry-run (other invocations are available, but I like pipes) to see if it will revert cleanly. If it does, revert it, rebuild the kernel, see if it fixes the problem. > And, if we find the problem commit, the next step might be to manually > change things in the source until we home in on the offending *line*, > if possible. So, we'd be manually tweaking the source at some point > anyway. > > > With regard to reversing a patch (without any use of git), is it for > certain that the -R option of patch can be used to reverse *any* > patch file? > > https://www.drupal.org/patch/reverse > No. For context diffs in the kernel, there have been several instances where a hunk (of an update, but the principle is the same) gets applied to similar code elsewhere in the file. Those cases were with git, but I'm sure patch will do the same. But things like that are uncommon. Backing up the file before reversing (modern patch will often do this, creating a .orig version - I think it depends on the amount of fuzz) and then diffing the two and comparing to the patch, and perhaps looking at more details in the before and after files, should be able to catch this. Also, if too much has changed since the patch was created then it cannot be reversed. But I'm sure you knew that. In those cases (e.g. a function got changed, or extra code added in the middle of what is being changed) it needs to be fixed up manually. Unfortunately, that is fairly common when trying to apply our own, or distro, patches in BLFS or beyond-BLFS. > If it is not universally possible to create a reverse patch using only > the information in a patch file, then I'd say that that is an oversight > in the design of diff. > > > There is a lot more info on the topic of reversing patches here: > > https://stackoverflow.com/questions/3902388/permanently-reversing-a-patch-file > > > The interdiff utility and the patchutils package are new to me: > > http://cyberelk.net/tim/software/patchutils/ > > ( simple standard install: ./configure --prefix=/usr > configure looks for perl and xmlto ) > > Interdiff can create an "inverse" patch file via: > > interdiff file.patch /dev/null > reversed.patch > > The resulting reverse patch looks good to me, but when I tried a dry > run: > > patch --dry-run -p1 -i > ../tip-x86-mm-x86-mm-Add-Secure-Memory-Encryption-SME-support_reverse.patch > > I got: > > checking file arch/x86/Kconfig > Reversed (or previously applied) patch detected! Assume -R? [n] > > I don't understand why it would think the patch had been already applied > as the patch is supposed to *delete* code that is indeed in my Kconfig file. > I think the problem might be because the specific kernel tree I tried it on > has the context lines at 1436 rather than the 1415 specified by the patch. > Dunno, but in beyond-BLFS, or trying to apply a BLFS patch to a newer version, I often get that. Sometimes I can see differences which make me go "yes, changed code", other times it all looks unaltered but still rejects. In either case, manually apply the .rej items with any necessary changes, then remove the .orig and .rej, rediff, and test to see if it builds (and if it does, test to see if it works). In theory, just moving a block of code by a few lines should only increse the fuzz. But recent versions of patch seem to be more sensitive. > I've attached a copy of the interdiff created > > tip-x86-mm-x86-mm-Add-Secure-Memory-Encryption-SME-support_reverse.patch > > in case anyone wants to look at/try it. > > Anyway, for the record, in the stackoverflow post, Lie Ryan's script > is not quite right. It reverses the --- and the +++ alright, but > later on it reverses the - and + at the start of the lines which also > ends up affecting the --- and +++ lines and so we end up getting -++ > and +--. If he went through all that trouble to create that script, > didn't he take the time to inspect the results of it? Sigh. > > > Cheers, > > Mike If somebody has the original patch which they want to revert, I don't understand why they would try to manipulate it like that. But this is one of those cases where I can't immediately see why the Kconfig change is treated as a revert. ĸen -- Keyboard not found, Press F1 to continue -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
