[solved] self-created patch not working mmc-utils

Message

DeIM · Post by **DeIM** » Sun Sep 03, 2023 2:12 pm

I'd like to build mmc-utils (not in tree but in overlay) but patch is not actual. So I made diff of modified Makefile:

--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
 CC ?= gcc
 GIT_VERSION := "$(shell git describe --abbrev=6 --always --tags)"
-AM_CFLAGS = -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 \
+AM_CFLAGS = -D_FILE_OFFSET_BITS=64 \
            -DVERSION=\"$(GIT_VERSION)\"
 CFLAGS ?= -g -O2
 objects = \

But when I install with this patch or when:

Code: Select all

patch -p1 < fix_cflags.patch

I get:

Code: Select all

patching file Makefile
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED -- saving rejects to file Makefile.rej

What's wrong and what's the correct way?
Thanks in advance, I have not clue.

alamahant · Post by **alamahant** » Sun Sep 03, 2023 2:28 pm

Plz see
https://wiki.gentoo.org/wiki//etc/portage/patches

Post by **NeddySeagoon** » Sun Sep 03, 2023 2:32 pm

DeIM,

Code: Select all

--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
 CC ?= gcc
 GIT_VERSION := "$(shell git describe --abbrev=6 --always --tags)"
-AM_CFLAGS = -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 \
...

That looks illegal to me. You need 3 lines of context before and after each hunk.
You only have two context lines there.

Post by Hu » Sun Sep 03, 2023 3:40 pm

I think the minimal early context is misleading here:

Code: Select all

$ seq 1 6 > a
$ seq 1 6 | sed -e 's/3/4/' > b
$ diff -u a b
--- a
+++ b
@@ -1,6 +1,6 @@
 1
 2
-3
+4
 4
 5
 6

In my example, which happens to end up with the same line context numbers, I only get two lines of leading context because the changed line is only the third line in the file.

DelM: please link to the original sources so we can review the Makefile that is processed by your ebuild.

CaptainBlood · Post by **CaptainBlood** » Sun Sep 03, 2023 3:57 pm

If I'm not mistaken

Code: Select all

diff -Naur

may have prevented this.
EDIT: Using it regularly alike purposes.

Thks 4 ur attention, interest & support.

stefan11111 · Post by **stefan11111** » Sun Sep 03, 2023 6:30 pm

CaptainBlood wrote:If I'm not mistaken
Code: Select all
diff -Naur
may have prevented this.
EDIT: Using it regularly alike purposes.

Thks 4 ur attention, interest & support.

This bothers me more than it should.
It's diff -Naru. The other one just looks wrong.

CaptainBlood · Post by **CaptainBlood** » Sun Sep 03, 2023 6:47 pm

I'm my own mnemonic, although your is lexical.
I'll try to convert to it.

As for a minimal approach, Hu's

Code: Select all

diff -u

might be enough.

Thks 4 ur attention,interest & support.

Post by Hu » Sun Sep 03, 2023 7:09 pm

Code: Select all

‘-a’
‘--text’
     Treat all files as text and compare them line-by-line, even if they
     do not seem to be text.  *Note Binary::.

‘-N’
‘--new-file’
     If one file is missing, treat it as present but empty.  *Note
     Comparing Directories::.

‘-r’
‘--recursive’
     When comparing directories, recursively compare any subdirectories
     found.  *Note Comparing Directories::.

In my example, the file was already text, it existed, and the targets were not directories. Thus, none of -Nar were needed for my demonstration. -r is usually needed for patches to be applied by Portage, unless you know exactly one file is different and name it explicitly. -N is somewhat less often needed, as Portage patches usually do not create or remove whole files. Per info diff, the text-versus-binary distinction is quite optimistic: it only considers a file as binary if null bytes are found near the start of the file. Therefore, -a is probably rarely necessary for Portage patches. It might be more commonly needed if non-ANSI printable characters could trigger binary mode, but they do not.

DeIM · Post by **DeIM** » Mon Sep 04, 2023 6:32 am

It's this file:
https://git.kernel.org/pub/scm/utils/mm ... n/Makefile

I made diff by:

Code: Select all

diff -u

Post by Hu » Mon Sep 04, 2023 2:55 pm

This is strange. I used the Quote button to view your original post so I could copy the patch text as-is. I saved the linked Makefile. I tried your patch. It failed. I made an equivalent patch by writing a new Makefile with the relevant change, then running diff -u between the saved file and the file I wrote. It created a distinct patch: your patch uses spaces, but mine uses tabs. This is sufficient to explain why your patch fails and mine works. It is not clear to me how you ended up with spaces in your patch. These forums are known to do tab-to-space conversion on viewing, but (1) that would not break your local usage and (2) I compensated for that with the approach of quoting your post to get at the patch.

Please explain exactly how you produced the patch. For me:

Code: Select all

$ curl -o Makefile 'https://git.kernel.org/pub/scm/utils/mmc/mmc-utils.git/plain/Makefile'
$ sed -e 's/-D_FORTIFY_SOURCE=2 //' < Makefile > b.Makefile
$ diff -u Makefile b.Makefile > b.patch

That produces a working patch for me (though the lack of leading may make Portage not accept it). Does it work for you? If yes, please explain how your procedure differs from the commands I showed.

DeIM · Post by **DeIM** » Mon Sep 04, 2023 7:09 pm

Thank you all for help. I don't know exactly how this happened but it's totally my bad - copy from console window seem the probable reason I'm still not sure I really used this stupid way - I should take a break

I tried the same sort of commands as last post and it passed.
I'll try the correct patch file with ebuild and mark thread as solved tomorrow, but it will certainly be OK.
I was quite angry to myself since I was clueless.
Many thanks!

Post by Hu » Mon Sep 04, 2023 7:58 pm

Yes, I expect most or all terminals would also cause that tab-to-space conversion if you copied program output from the terminal. For this reason, you should use the shell to redirect diff -u to a file when you are ready to save it. Only show it to the terminal if you want to quickly visually inspect that the diff looks reasonable.