iptables-1.8.9-r0 fails to apply patch

[HalfAHat]

On master, iptables fails to be patched during build. Looks similar to issue 98.

ERROR: iptables-1.8.9-r0 do_patch: Applying patch '600-shared-libext.patch' on target directory '/home/user/openembedded-core/build/tmp-musl/work/cortexa15t2hf-neon-oe-linux-musleabi/iptables/1.8.9-r0/iptables-1.8.9'
CmdError('quilt --quiltrc /home/user/openembedded-core/build/tmp-musl/work/cortexa15t2hf-neon-oe-linux-musleabi/iptables/1.8.9-r0/recipe-sysroot-native/etc/quiltrc push', 0, 'stdout: Applying patch 600-shared-libext.patch
patching file extensions/GNUmakefile.in
Hunk #2 succeeded at 113 (offset 1 line).
Hunk #3 succeeded at 153 (offset 9 lines).
patching file iptables/Makefile.am
Hunk #1 FAILED at 7.
Hunk #2 FAILED at 28.
Hunk #3 FAILED at 42.
3 out of 3 hunks FAILED -- rejects in file iptables/Makefile.am
Patch 600-shared-libext.patch does not apply (enforce with -f)

stderr: ')
ERROR: Logfile of failure stored in: /home/user/openembedded-core/build/tmp-musl/work/cortexa15t2hf-neon-oe-linux-musleabi/iptables/1.8.9-r0/temp/log.do_patch.3912
ERROR: Task (/home/user/openembedded-core/meta/recipes-extended/iptables/iptables_1.8.9.bb:do_patch) failed with exit code '1'

[kraj]

@HalfAHat are you using master branch

[HalfAHat]

Yes. I am following the directions in README.md for initializing and building. I also had to use the workaround described in issue 131 for the Busybox recipe.

Looking at the file attempted to be patched iptables/Makefile.am, it appears that most of variable names have been changed causing the patch to not be applied which is what I consider to be the suspect. Snippet of lines 7-30 of build/tmp-musl/work/cortexa15t2hf-neon-oe-linux-musleabi/iptables/1.8.9-r0/iptables-1.8.9/iptables/Makefile.am:

BUILT_SOURCES =

common_sources = iptables-xml.c xtables-multi.h xshared.c xshared.h
common_ldadd   = ../extensions/libext.a ../libxtables/libxtables.la -lm
common_cflags  = ${AM_CFLAGS}
if ENABLE_STATIC
common_cflags += -DALL_INCLUSIVE
endif

xtables_legacy_multi_SOURCES  = ${common_sources} xtables-legacy-multi.c \
                iptables-restore.c iptables-save.c
xtables_legacy_multi_CFLAGS   = ${common_cflags}
xtables_legacy_multi_LDADD    = ${common_ldadd}
if ENABLE_IPV4
xtables_legacy_multi_SOURCES += iptables-standalone.c iptables.c iptables-multi.h
xtables_legacy_multi_CFLAGS  += -DENABLE_IPV4
xtables_legacy_multi_LDADD   += ../libiptc/libip4tc.la ../extensions/libext4.a
endif
if ENABLE_IPV6
xtables_legacy_multi_SOURCES += ip6tables-standalone.c ip6tables.c ip6tables-multi.h
xtables_legacy_multi_CFLAGS  += -DENABLE_IPV6
xtables_legacy_multi_LDADD   += ../libiptc/libip6tc.la ../extensions/libext6.a
endif

[kraj]

ok, do you intend to refresh the patches to apply to current versions ? if you do feel free to send a pull request while you are at it. It does need forward porting these patches as master keeps moving with newer versions.

[HalfAHat]

I can make an attempt to port the effected patches as it seems there are two others 0001 and 601 are also failing. I'm fairly new to Yocto, so let me know if this question doesn't make sense or isn't possible. Would it make sense to tie the OpenWRT source to a tagged release branch such as v22.03.2 to get the same versions of packages every time until someone forwards the recipes to a new version?