Message ID | 20240522070238.3282121-1-dario.binacchi@amarulasolutions.com |
---|---|
Headers | show |
Series |
|
Related | show |
On 22/05/2024 09:02, Dario Binacchi wrote: > The series will allow applying package patches with a fuzz factor of 0 > instead of 2 (the patch command default value). > By setting the maximum fuzz factor to 0, we avoid that patches which > cannot be applied are incorrectly reported as valid, with positive > side-effects on version bumps. > > To avoid regressions, it was necessary to fix all those patches that > were applicable with a fuzz factor of 1 or 2 before implementing this > change. The series was tested on commit 47078cc11862 ("package/zxing-cpp: > add options for enabling readers and/or writers") with a script that > executed the make legal-info command for all defconfigs contained in > Buildroot. Then, for all the affected packages, the compilation was > executed. Series applied to master, thanks! Since this was about a month old, chances are that some new fuzzy patches have been introduced through version bumps. But the autobuilders will report that. Regards, Arnout > > Dario Binacchi (18): > board/orangepi/orangepi-zero: make the patches to be applied with fuzz > 0 > board/pine64/rock64: make the patches to be applied with fuzz 0 > boot/syslinux: update the patches to be applied with fuzz 0 > package/alsa-lib: update the patch to be applied with fuzz 0 > package/bzip2: update the patches to be applied with fuzz 0 > package/elfutils: update the patches to be applied with fuzz 0 > package/ffmpeg: update the patches to be applied with fuzz 0 > package/giflib: update the patches to be applied with fuzz 0 > package/libabseil-cpp: update the patch to be applied with fuzz 0 > package/libglib2: update the patches to be applied with fuzz 0 > package/libnl: update the patch to be applied with fuzz 0 > package/libopenssl: update the patches to be applied with fuzz 0 > package/openocd: update the patch to be applied with fuzz 0 > package/patchelf: update the patch to be applied with fuzz 0 > package/qemu: update the patches to be applied with fuzz 0 > package/qt5/qt5base: update the patches to be applied with fuzz 0 > package/vboot-utils: update the patches to be applied with fuzz 0 > support/scripts/apply-patches.sh: set the maximum fuzz factor to 0 > > ...RM-dts-orange-pi-zero-enable-spi-nor.patch | 41 ++++++++-------- > ...ARM-dts-orange-pi-zero-enable-spidev.patch | 23 +++++---- > ...328-needs-itb-image-to-boot-properly.patch | 18 +++---- > .../0015-efi-main.c-include-efisetjmp.h.patch | 10 ++-- > ...01-Don-t-use-fork-on-noMMU-platforms.patch | 19 ++++---- > package/bzip2/0001-build-objects-twice.patch | 14 +++--- > package/bzip2/0002-improve-build-system.patch | 12 +++-- > ...e-Werror-conditional-to-BUILD_WERROR.patch | 12 +++-- > .../0003-libavutil-Fix-mips-build.patch | 16 ++++--- > ...dd-targets-to-manage-static-building.patch | 18 +++---- > ...veral-defects-found-by-Coverity-scan.patch | 20 ++++---- > ...0001-force-position-independent-code.patch | 14 +++--- > ...girdir-to-gio-2.0.pc-and-glib-2.0.pc.patch | 16 ++++--- > ...workaround-to-the-libc-compat.h-copy.patch | 17 ++++--- > .../0003-Revert-Fix-static-builds.patch | 16 ++++--- > ...01-configure-enable-build-on-uclinux.patch | 12 +++-- > ...ke-the-rpath-relative-under-a-specif.patch | 48 ++++++++++--------- > ...on-t-build-fp-bench-test-if-fenv.h-i.patch | 9 ++-- > .../qt5base/0006-Fix-build-on-riscv32.patch | 18 +++---- > ...05-include-sys-sysmacros.h-for-major.patch | 12 +++-- > support/scripts/apply-patches.sh | 2 +- > 21 files changed, 204 insertions(+), 163 deletions(-) > To unsubscribe from this group and stop receiving emails from it, send an email to linux-amarula+unsubscribe@amarulasolutions.com.
Dario, All, On 2024-05-22 09:02 +0200, Dario Binacchi spake thusly: > The series will allow applying package patches with a fuzz factor of 0 > instead of 2 (the patch command default value). > By setting the maximum fuzz factor to 0, we avoid that patches which > cannot be applied are incorrectly reported as valid, with positive > side-effects on version bumps. > > To avoid regressions, it was necessary to fix all those patches that > were applicable with a fuzz factor of 1 or 2 before implementing this > change. The series was tested on commit 47078cc11862 ("package/zxing-cpp: > add options for enabling readers and/or writers") with a script that > executed the make legal-info command for all defconfigs contained in > Buildroot. Then, for all the affected packages, the compilation was > executed. Thanks a lot for all those efforts! 👍 As Arnout said, it is not unexpected that we missed some, and that new patches added since then would not be fuzz-zero-ready. So, I came up with a little bit of shell trickedry to start and test all our patches (or at least the vast majority of them): $ cat foo.lst # Ignore boot/ and linux/ as they are too special... find package/ -type f -name '*.mk' -printf '%h\n' \ |sort -u \ |while read dir; do [ -e "${dir}/Config.in" ] || continue ( find "${dir}" -type f -name '*.patch' -print -quit |grep -q . ) || continue pkg="$( basename "${dir}" )" [ -e "${dir}/${pkg}.mk" ] || continue sed -r -e '/^\$\(eval \$\((host-)?[^-]+-package\)\)$/!d; s//\1'"${pkg}"'-patch/' "${dir}/${pkg}.mk" done \ |grep -v -E 'am335x-pru-package|asterisk|aufs-util|aumix|cgic' $ make defconfig $ ./utils/config --set-str BR2_BACKUP_SITE "" $ make $(. ./foo.lst) I stopped adding exceptions when I reached cgic... Exceptions: - Patch fuzz: - asterisk - Others: - am335x-pru-package: hash error, github-generated - aufs-util: needs a kernel, patches unknwon - aumix: 403 forbidden, patches OK, tested with s.b.o. - bsdiff: 403 forbidden, patches OK, tested with s.b.o. - cgic: hash error, upstream is dead (parking site) So, I found more download issues than I found patch fuzz issues... I'm not sure if that's a good or a bad thing? ;-] Then linux/ and boot/ will have to be checked "manually"... Regards, Yann E. MORIN.