linux/poky.git/meta/recipes-devtools/rpm/files/0001-Do-not-add-an-unsatisfiable-dependency-when-building.patch, branch genericarm64

rpm: update 4.18.1 -> 4.19.1

2024-01-27T08:20:02+00:00

Upstream has replaced autoconf with cmake, which necessitates a rewrite of the recipe and available options, and a rebase to cmake of 0001-Do-not-hardcode-lib-rpm-as-the-installation-path-for.patch Correct a mistake in 0001-Do-not-read-config-files-from-HOME.patch : the patch was removing the NULL marker at the end of function arguments, and 0002-Add-support-for-prefixing-etc-from-RPM_ETCCONFIGDIR-.patch was restoring it (in addition to the actual change the patch was making). Now both patches preserve the NULL terminator. (From OE-Core rev: 38549d462b399e3a63335f60a44c8bbced98639a) Signed-off-by: Alexander Kanavin Signed-off-by: Richard Purdie

rpm: Upgrade 4.17.1 -> 4.18rc1

2022-09-20T22:17:53+00:00

rpm is close to release and give our release timings, update to the rc1 of 4.18. Includes fixes for CVE-2021-35937, CVE-2021-35938 and CVE-2021-35939 which can't be easily backported. Add a PACKAGECONFIG option for a new readline dependency and disable it by default since it pulls in GPLv3 and that breaks a number of our test configurations as things stand. Refresh patches and drop the error.h patch as error() no longer used. (From OE-Core rev: 4b31e4f2aea490bd5056c97742b5e25a8dcc8b36) Signed-off-by: Richard Purdie

rpm: upgrade to 4.15.1

2020-05-02T08:08:52+00:00

Drop patches that were merged upstream. 0001-mono-find-provides-requires-do-not-use-monodis-from-.patch modifies a file that was removed upstream. Add a 0001-rpmfc.c-do-not-run-file-classification-in-parallel.patch as unfortunately the new parallel file classification feature from upstream trips over somewhere in libmagic when inspected files are compressed: https://github.com/rpm-software-management/rpm/issues/756 (From OE-Core rev: 67257ca87c6fa8e6050a20ecea50daf834c7e869) Signed-off-by: Alexander Kanavin Signed-off-by: Richard Purdie

rpm: add a 4.x recipe

2017-03-14T14:42:16+00:00

The dnf stack is written and tested against rpm 4.x. So if we want to use dnf for packaging, we should also use rpm 4 - there's simply too much work involved in making rpm 5 work with it due to significant API differences, and supporting that going forward. (From OE-Core rev: 2358e786ec8d1199d90e181eb5d8d00816f669b4) Signed-off-by: Alexander Kanavin Signed-off-by: Richard Purdie