| Message ID | 20160909163708.31980-1-james.knight@rockwellcollins.com |
|---|---|
| State | Changes Requested |
| Headers | show |
Hello, On Fri, 9 Sep 2016 12:37:08 -0400, James Knight wrote: > The provided switches from the RPM5 implementation to rpm.org's stream. > > Signed-off-by: James Knight <james.knight@rockwellcollins.com> Could you give some details on why the rpm.org version is better than the rpm5.org version? The motivation to move from a 5.x version to a 4.x version doesn't look immediately obvious, so some more details would be good to have. RPM seems like a weird project, it's widely used, but it's very hard to understand what is the real upstream for it. This fact was even discussed on LWN recently: https://lwn.net/Articles/196523/. Thanks, Thomas
On 11-09-16 15:54, Thomas Petazzoni wrote: > Hello, > > On Fri, 9 Sep 2016 12:37:08 -0400, James Knight wrote: >> The provided switches from the RPM5 implementation to rpm.org's stream. >> >> Signed-off-by: James Knight <james.knight@rockwellcollins.com> > > Could you give some details on why the rpm.org version is better than > the rpm5.org version? The motivation to move from a 5.x version to > a 4.x version doesn't look immediately obvious, so some more > details would be good to have. v4 of the patch (about a year old) still had The provided "bump" (suggested by Baruch Siach) switches from the rpm5 implementation to rpm.org's more active stream. It would be good to keep this information, and even add a link to [0] [0] http://lists.buildroot.org/pipermail/buildroot/2015-August/137580.html I just checked on openhub, and indeed, rpm.org seems to get about 10 times more commits than rpm5.org. Actually, there is a 4.13 release now, so James, perhaps you should use that one? > RPM seems like a weird project, it's widely used, but it's very hard to > understand what is the real upstream for it. This fact was even It looks pretty obvious to me: rpm5.org is a fork of rpm.org. > discussed on LWN recently: https://lwn.net/Articles/196523/. Er, Thomas, you're by far not old enough to be allowed to call a 10 year old article "recent" :-) Regards, Arnout > > Thanks, > > Thomas >
Hello, On Sun, 11 Sep 2016 23:10:29 +0200, Arnout Vandecappelle wrote: > v4 of the patch (about a year old) still had > > The provided "bump" (suggested by Baruch Siach) switches from the rpm5 > implementation to rpm.org's more active stream. > > It would be good to keep this information, and even add a link to [0] > > [0] http://lists.buildroot.org/pipermail/buildroot/2015-August/137580.html > > I just checked on openhub, and indeed, rpm.org seems to get about 10 times more > commits than rpm5.org. Thanks for the additional info. > > RPM seems like a weird project, it's widely used, but it's very hard to > > understand what is the real upstream for it. This fact was even > > It looks pretty obvious to me: rpm5.org is a fork of rpm.org. > > > discussed on LWN recently: https://lwn.net/Articles/196523/. > > Er, Thomas, you're by far not old enough to be allowed to call a 10 year old > article "recent" :-) Gah. The one I read recently is https://blog.fuzzing-project.org/52-Multiple-vulnerabilities-in-RPM-and-a-rant.html, which was referenced by LWN in https://lwn.net/Articles/698453/. Indeed, the other one is 10 year old. Interestingly https://lwn.net/Articles/698453/ also points to the 10 year old article saying that not much has improved in the RPM maintenance over a 10 year period. Thomas
On Sun, Sep 11, 2016 at 9:54 AM, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote: > Could you give some details on why the rpm.org version is better than > the rpm5.org version? I'll resubmit with a more proper commit message. On Sun, Sep 11, 2016 at 5:10 PM, Arnout Vandecappelle <arnout@mind.be> wrote: > It would be good to keep this information, and even add a link to [0] > > [0] http://lists.buildroot.org/pipermail/buildroot/2015-August/137580.html Will do. On Sun, Sep 11, 2016 at 5:10 PM, Arnout Vandecappelle <arnout@mind.be> wrote: > Actually, there is a 4.13 release now, so James, perhaps you should use that one? Unless it's somewhere else, rpm.org's claim of release 4.13 was never completed [1]. The only 4.13 release made was a release candidate [2] (although I believe the Fedora team uses the RC; will probably additional distribution patches). --- The request to change to rpm.org's variant for Buildroot is based off of several reasons. As already mentioned by Baruch Siach in the past (reiterated by Arnout), rpm.org's stream is more active. This is driven by the fact that rpm.org variant is used in most RPM-based distributions. This brings the benefit of having the ability to stack on stable patches from a series of distributions which use it (ex: [3]). Will there ever be an official 4.13 or later release, I would assume not; but, I don't think rpm.org is going anywhere until they replace it with something like Flatpak. For a lot of the work I've been working on, I uses RPMs to stack software packages for OS's I generated with Buildroot. To help make it easier to build/package RPMs for a target, I try to ensure a generate toolchain provides a compatibility RPM tool suite for developers to use. After trying both rpm.org and RPM5's variants, I find rpm.org's variant easier to build and maintain. With the current version of RPM5 we have in Buildroot, it does some things I do not like. For example, it builds its internal version of BerkeleyDB instead of using Buildroot. I tried adjusting that (as well as other features) but had a series of issues using Buildroot's current version of BerkeleyDB. Naturally, I tried taking the time in upgrading to RPM5's most recent version but there were a series of issues trying to get things to work as well. While I can't recall all the code-related issues, one major annoyance was that RPM5's most recent releases are distributed via srpm ("src.rpm") files. It got complicated trying to get Buildroot to download a source-RPM file to extract, especially on systems which didn't have an existing RPM tool suite. I also plan to re-submit patches in the future to enable RPM host tool packages. This is to help generate compatible RPM packages and manage database generating during the build phase and post-build modifications. While I cannot remember the specific issues I've experienced, I recall having some host-related issues with building and distributing an RPM5-generated tool suite. Really, I don't mind if Buildroot supports having either RPM variant. I don't mind re-submitting patches which move the existing Buildroot rpm package under the name rpm5 and provide a new rpm4 (or use the existing Buildroot rpm package) for rpm.org's variant (if anyone uses/is-dependent-on RPM5). From my own experience, I believe rpm.org variant is an overall improved experience under Buildroot than RPM5. Comments welcome. I'll re-submit the patch (hopefully, later this week) and include the above point on rpm.org's stream being the primary factor for the switch. [1]: http://rpm.org/releases/rpm-4.13.x/ [2]: http://rpm.org/releases/testing/ [3]: http://pkgs.fedoraproject.org/cgit/rpms/rpm.git/tree/
Hello, On Mon, 12 Sep 2016 12:06:18 -0400, James Knight wrote: > Unless it's somewhere else, rpm.org's claim of release 4.13 was never > completed [1]. The only 4.13 release made was a release candidate [2] > (although I believe the Fedora team uses the RC; will probably > additional distribution patches). > > --- > > The request to change to rpm.org's variant for Buildroot is based off > of several reasons. As already mentioned by Baruch Siach in the past > (reiterated by Arnout), rpm.org's stream is more active. This is > driven by the fact that rpm.org variant is used in most RPM-based > distributions. This brings the benefit of having the ability to stack > on stable patches from a series of distributions which use it (ex: > [3]). Will there ever be an official 4.13 or later release, I would > assume not; but, I don't think rpm.org is going anywhere until they > replace it with something like Flatpak. > > For a lot of the work I've been working on, I uses RPMs to stack > software packages for OS's I generated with Buildroot. To help make it > easier to build/package RPMs for a target, I try to ensure a generate > toolchain provides a compatibility RPM tool suite for developers to > use. After trying both rpm.org and RPM5's variants, I find rpm.org's > variant easier to build and maintain. With the current version of RPM5 > we have in Buildroot, it does some things I do not like. For example, > it builds its internal version of BerkeleyDB instead of using > Buildroot. I tried adjusting that (as well as other features) but had > a series of issues using Buildroot's current version of BerkeleyDB. > Naturally, I tried taking the time in upgrading to RPM5's most recent > version but there were a series of issues trying to get things to work > as well. While I can't recall all the code-related issues, one major > annoyance was that RPM5's most recent releases are distributed via > srpm ("src.rpm") files. It got complicated trying to get Buildroot to > download a source-RPM file to extract, especially on systems which > didn't have an existing RPM tool suite. > > I also plan to re-submit patches in the future to enable RPM host tool > packages. This is to help generate compatible RPM packages and manage > database generating during the build phase and post-build > modifications. While I cannot remember the specific issues I've > experienced, I recall having some host-related issues with building > and distributing an RPM5-generated tool suite. > > Really, I don't mind if Buildroot supports having either RPM variant. > I don't mind re-submitting patches which move the existing Buildroot > rpm package under the name rpm5 and provide a new rpm4 (or use the > existing Buildroot rpm package) for rpm.org's variant (if anyone > uses/is-dependent-on RPM5). From my own experience, I believe rpm.org > variant is an overall improved experience under Buildroot than RPM5. Thanks for this explanation. I don't think packaging both rpm4 and rpm5 makes sense, so let's switch the rpm package to this more active/useful upstream project, as you propose. Can you include the summary you made in the commit log (avoiding first person speech however) ? Thanks! Thomas
Thomas, On Mon, Sep 12, 2016 at 3:12 PM, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote: > Can you include the summary you made in the commit log (avoiding first > person speech however) ? Will do.
On 12-09-16 18:06, James Knight wrote: > On Sun, Sep 11, 2016 at 9:54 AM, Thomas Petazzoni > <thomas.petazzoni@free-electrons.com> wrote: >> Could you give some details on why the rpm.org version is better than >> the rpm5.org version? > > I'll resubmit with a more proper commit message. > > On Sun, Sep 11, 2016 at 5:10 PM, Arnout Vandecappelle <arnout@mind.be> wrote: >> It would be good to keep this information, and even add a link to [0] >> >> [0] http://lists.buildroot.org/pipermail/buildroot/2015-August/137580.html > > Will do. > > On Sun, Sep 11, 2016 at 5:10 PM, Arnout Vandecappelle <arnout@mind.be> wrote: >> Actually, there is a 4.13 release now, so James, perhaps you should use that one? > > Unless it's somewhere else, rpm.org's claim of release 4.13 was never > completed [1]. The only 4.13 release made was a release candidate [2] > (although I believe the Fedora team uses the RC; will probably > additional distribution patches). I'm sorry, I just saw [1], didn't notice that the directory was empty. Regards, Arnout > [1]: http://rpm.org/releases/rpm-4.13.x/ > [2]: http://rpm.org/releases/testing/ > [3]: http://pkgs.fedoraproject.org/cgit/rpms/rpm.git/tree/ >
On 09-09-16 18:37, James Knight wrote: > The provided switches from the RPM5 implementation to rpm.org's stream. [snip] > diff --git a/package/rpm/0001-configure.ac-use-link-instead-of-compile-for-gcc-fla.patch b/package/rpm/0001-configure.ac-use-link-instead-of-compile-for-gcc-fla.patch > new file mode 100644 > index 0000000..e3c5da9 > --- /dev/null > +++ b/package/rpm/0001-configure.ac-use-link-instead-of-compile-for-gcc-fla.patch > @@ -0,0 +1,35 @@ > +From 840152e36365026631e9fb649eef7f830b074797 Mon Sep 17 00:00:00 2001 > +From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> > +Date: Sat, 10 Oct 2015 23:17:44 +0200 > +Subject: [PATCH 1/2] configure.ac: use link instead of compile for gcc flags > + test > + > +The logic that tests whether gcc supports or not certain flags uses > +AC_COMPILE_IFELSE(). However, when checking for stack smashing > +protection support, an AC_LINK_IFELSE() test is needed, since the > +build might work but not the link stage if certain libraries are > +missing for proper stack smashing protection support. > + > +Therefore, this commit switches to use AC_LINK_IFELSE(). > + > +Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> It's weird that you get this patch from Thomas while he isn't mentioned in the commit message. I thought it was because we had rpm4 before, but it turns out our initial commit for rpm was already rpm5. So it would be interesting to mention in the commit message where this comes from. More importantly, however: you should add your own Sob. Oh, and there's an active upstream at https://github.com/rpm-software-management/rpm Could you submit it there (if still relevant)? Same for the other patch. > +--- > + configure.ac | 2 +- > + 1 file changed, 1 insertion(+), 1 deletion(-) > + > +diff --git a/configure.ac b/configure.ac > +index bb368a9..6ffd472 100644 > +--- a/configure.ac > ++++ b/configure.ac > +@@ -43,7 +43,7 @@ if test "$GCC" = yes; then > + echo > + for flag in $cflags_to_try; do > + CFLAGS="$CFLAGS $flag -Werror" > +- AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[]], [[return 0;]])],[ > ++ AC_LINK_IFELSE([AC_LANG_PROGRAM([[]], [[return 0;]])],[ > + echo " $flag" > + RPMCFLAGS="$RPMCFLAGS $flag" > + ],[]) > +-- > +2.6.1 > + [snip] > diff --git a/package/rpm/Config.in b/package/rpm/Config.in > index 2be646a..e80a69a 100644 > --- a/package/rpm/Config.in > +++ b/package/rpm/Config.in > @@ -1,28 +1,21 @@ > -comment "rpm needs a toolchain w/ threads" > - depends on !BR2_TOOLCHAIN_HAS_THREADS > - depends on BR2_USE_MMU # fork() > +comment "rpm needs a uClibc or glibc toolchain w/ threads" > + depends on !BR2_TOOLCHAIN_HAS_THREADS || BR2_TOOLCHAIN_USES_MUSL Could you mention in the commit message what fails on musl? Makes fixing it later easier. > depends on BR2_PACKAGE_BUSYBOX_SHOW_OTHERS > - > -comment "rpm needs a toolchain w/ gcc >= 5" > - depends on !BR2_TOOLCHAIN_GCC_AT_LEAST_5 && BR2_sh > + depends on BR2_USE_MMU > > config BR2_PACKAGE_RPM > bool "rpm" > - # triggers internal compiler error > - depends on BR2_TOOLCHAIN_GCC_AT_LEAST_5 || !BR2_sh > + depends on !BR2_TOOLCHAIN_USES_MUSL # __fxstat64, _D_EXACT_NAMELEN > + depends on BR2_PACKAGE_BUSYBOX_SHOW_OTHERS > depends on BR2_TOOLCHAIN_HAS_THREADS # beecrypt or libnss > depends on BR2_USE_MMU # fork() > - depends on BR2_PACKAGE_BUSYBOX_SHOW_OTHERS > - select BR2_PACKAGE_BEECRYPT > + select BR2_PACKAGE_BEECRYPT if !BR2_PACKAGE_LIBNSS > + select BR2_PACKAGE_BERKELEYDB > + select BR2_PACKAGE_FILE > select BR2_PACKAGE_GETTEXT if BR2_NEEDS_GETTEXT_IF_LOCALE > - select BR2_PACKAGE_NEON > - select BR2_PACKAGE_NEON_SSL > - select BR2_PACKAGE_NEON_XML > - select BR2_PACKAGE_NEON_ZLIB > - select BR2_PACKAGE_OPENSSL > select BR2_PACKAGE_POPT > select BR2_PACKAGE_ZLIB > help > - The RPM package management system. > + The RPM Package Manager (RPM). > > - http://rpm5.org > + http://www.rpm.org/ > diff --git a/package/rpm/rpm.hash b/package/rpm/rpm.hash > index 0665746..e579fa4 100644 > --- a/package/rpm/rpm.hash > +++ b/package/rpm/rpm.hash > @@ -1,2 +1,2 @@ > -# Locally calculated > -sha256 34a959c0ed670cadcdc52c6025e822fac6f5d1015e3b75123f53ebe53b923e98 rpm-5.2.0.tar.gz > +# From http://rpm.org/wiki/Releases/4.12.0.1 > +sha1 d416bdb249b246b00b2d5d34c66e7f5a68a62524 rpm-4.12.0.1.tar.bz2 > diff --git a/package/rpm/rpm.mk b/package/rpm/rpm.mk > index 7f346b2..a022ae9 100644 > --- a/package/rpm/rpm.mk > +++ b/package/rpm/rpm.mk > @@ -4,61 +4,67 @@ > # > ################################################################################ > > -RPM_VERSION_MAJOR = 5.2 > -RPM_VERSION = $(RPM_VERSION_MAJOR).0 > -RPM_SITE = http://rpm5.org/files/rpm/rpm-$(RPM_VERSION_MAJOR) > -RPM_DEPENDENCIES = host-pkgconf zlib beecrypt neon popt openssl > -RPM_LICENSE = LGPLv2.1 > -RPM_LICENSE_FILES = COPYING.LIB > +RPM_VERSION_MAJOR = 4.12 > +RPM_VERSION = $(RPM_VERSION_MAJOR).0.1 > +RPM_SOURCE = rpm-$(RPM_VERSION).tar.bz2 > +RPM_SITE = http://rpm.org/releases/rpm-$(RPM_VERSION_MAJOR).x > +RPM_DEPENDENCIES = host-pkgconf berkeleydb file popt zlib > +RPM_LICENSE = GPLv2 Confirmed that it's v2 only. The library can actually be distributed under LGPLv2 (only), but I don't think we install that separately so it doesn't matter. > +RPM_LICENSE_FILES = COPYING > > -RPM_CONF_ENV = \ > - CFLAGS="$(TARGET_CFLAGS) -I$(STAGING_DIR)/usr/include/beecrypt -I$(STAGING_DIR)/usr/include/neon -DHAVE_MUTEX_THREAD_ONLY" \ > - ac_cv_va_copy=yes > +# 0001-configure.ac-use-link-instead-of-compile-for-gcc-fla.patch > +RPM_AUTORECONF = YES > > -RPM_CONF_OPTS = \ > - --disable-build-versionscript \ > +RPM_CONF_OPTS += \ Why += ? > + --disable-largefile \ Why disable? Probably needs a comment in commit message or in .mk file. > --disable-rpath \ > - --without-selinux \ > - --without-python \ > - --without-perl \ > - --with-openssl=external \ > - --with-zlib=external \ > - --with-libbeecrypt=$(STAGING_DIR) \ > - --with-popt=external > + --enable-python=no \ Doesn't --without-python or --disable-python work? > + --with-external-db \ > + --with-gnu-ld \ > + --without-cap \ > + --without-hackingdocs \ > + --without-lua > > -ifeq ($(BR2_NEEDS_GETTEXT_IF_LOCALE),y) > -RPM_DEPENDENCIES += gettext > +ifeq ($(BR2_PACKAGE_ACL),y) > +RPM_DEPENDENCIES += acl > +RPM_CONF_OPTS += --with-acl > +else > +RPM_CONF_OPTS += --without-acl > endif > > -ifeq ($(BR2_PACKAGE_PCRE),y) > -RPM_DEPENDENCIES += pcre > -RPM_CONF_OPTS += --with-pcre=external > +ifeq ($(BR2_PACKAGE_BEECRYPT),y) Small nit: since Config.in selects beecrypt if !libnss, it makes more sense to make it similar here, i.e. ifeq ($(BR2_PACKAGE_LIBNSS),y). > +RPM_DEPENDENCIES += beecrypt > +RPM_CONF_OPTS += --with-beecrypt > +RPM_CFLAGS += -I$(STAGING_DIR)/usr/include/beecrypt > else > -RPM_CONF_OPTS += --with-pcre=none > +RPM_DEPENDENCIES += libnss > +RPM_CONF_OPTS += --without-beecrypt > +RPM_CFLAGS += -I$(STAGING_DIR)/usr/include/nss -I$(STAGING_DIR)/usr/include/nspr > endif > > -ifeq ($(BR2_PACKAGE_FILE),y) > -RPM_DEPENDENCIES += file > -RPM_CONF_OPTS += --with-file=external > +ifeq ($(BR2_NEEDS_GETTEXT_IF_LOCALE),y) > +RPM_DEPENDENCIES += gettext > +RPM_CONF_OPTS += --with-libintl-prefix=$(STAGING_DIR)/usr > else > -RPM_CONF_OPTS += --with-file=none > +RPM_CONF_OPTS += --without-libintl-prefix > endif > > -# xz payload support needs a toolchain w/ C++ > -ifeq ($(BR2_PACKAGE_XZ)$(BR2_INSTALL_LIBSTDCPP),yy) > -RPM_DEPENDENCIES += xz > -RPM_CONF_OPTS += --with-xz=external > +ifeq ($(BR2_PACKAGE_LIBARCHIVE),y) > +RPM_DEPENDENCIES += libarchive > +RPM_CONF_OPTS += --with-archive > else > -RPM_CONF_OPTS += --with-xz=none > +RPM_CONF_OPTS += --without-archive > endif > > -ifeq ($(BR2_PACKAGE_BZIP2),y) > -RPM_CONF_OPTS += --with-bzip2 > -RPM_DEPENDENCIES += bzip2 > +ifeq ($(BR2_PACKAGE_LIBSELINUX),y) > +RPM_DEPENDENCIES += libselinux > +RPM_CONF_OPTS += --with-selinux > +else > +RPM_CONF_OPTS += --without-selinux > endif > > -RPM_MAKE = $(MAKE1) > - > -RPM_INSTALL_TARGET_OPTS = DESTDIR=$(TARGET_DIR) program_transform_name= install > +RPM_CONF_ENV += \ > + ac_cv_prog_cc_c99='-std=gnu99' \ Doesn't configure detect this? Add a comment why not. Regards, Arnout > + CFLAGS="$(TARGET_CFLAGS) $(RPM_CFLAGS)" > > $(eval $(autotools-package)) >
Arnout, On Mon, Sep 12, 2016 at 5:33 PM, Arnout Vandecappelle <arnout@mind.be> wrote: > It's weird that you get this patch from Thomas while he isn't mentioned in the > commit message. I thought it was because we had rpm4 before, but it turns out > our initial commit for rpm was already rpm5. So it would be interesting to > mention in the commit message where this comes from. I can reference the old request where Thomas provided these patches. [1] > > More importantly, however: you should add your own Sob. Good to know, thanks! > Oh, and there's an active upstream at > https://github.com/rpm-software-management/rpm > Could you submit it there (if still relevant)? I'll investigate this. I won't be able to try this until next month or so, so I hope having these patches for now will suffice/causes no complaints. >> + depends on !BR2_TOOLCHAIN_HAS_THREADS || BR2_TOOLCHAIN_USES_MUSL > > Could you mention in the commit message what fails on musl? Makes fixing it > later easier. I tried to put that information in the actual package portion: depends on !BR2_TOOLCHAIN_USES_MUSL # __fxstat64, _D_EXACT_NAMELEN Does that suffice? Or is it better to put it in the comment section? Or is a longer comment desire? Either way, I'll clean that up. >> depends on BR2_TOOLCHAIN_HAS_THREADS # beecrypt > > or libnss Noted. >> +RPM_CONF_OPTS += \ > > Why += ? A mistake, will fix. >> + --disable-largefile \ > > Why disable? Probably needs a comment in commit message or in .mk file. Actually, I cannot recall. I'll investigate and add an appropriate correction or comment. >> + --enable-python=no \ > > Doesn't --without-python or --disable-python work? Most likely does; will cleanup. >> +ifeq ($(BR2_PACKAGE_BEECRYPT),y) > > Small nit: since Config.in selects beecrypt if !libnss, it makes more sense to > make it similar here, i.e. ifeq ($(BR2_PACKAGE_LIBNSS),y). Sure; I'll clean that up. >> +RPM_CONF_ENV += \ >> + ac_cv_prog_cc_c99='-std=gnu99' \ > > Doesn't configure detect this? Add a comment why not. It doesn't. Doesn't excuse the fact that I didn't add a comment why; I'll address this as well. --- Thanks for all the comments. [1]: https://patchwork.ozlabs.org/patch/528733/
On 13-09-16 00:22, James Knight wrote: > Arnout, > > On Mon, Sep 12, 2016 at 5:33 PM, Arnout Vandecappelle <arnout@mind.be> wrote: [snip] >> > Oh, and there's an active upstream at >> > https://github.com/rpm-software-management/rpm >> > Could you submit it there (if still relevant)? > I'll investigate this. I won't be able to try this until next month or > so, so I hope having these patches for now will suffice/causes no > complaints. No worries. >>> >> + depends on !BR2_TOOLCHAIN_HAS_THREADS || BR2_TOOLCHAIN_USES_MUSL >> > >> > Could you mention in the commit message what fails on musl? Makes fixing it >> > later easier. > I tried to put that information in the actual package portion: > > depends on !BR2_TOOLCHAIN_USES_MUSL # __fxstat64, _D_EXACT_NAMELEN > > Does that suffice? Or is it better to put it in the comment section? > Or is a longer comment desire? Either way, I'll clean that up. Yep, that's good enough for me. Regards, Arnout
On Mon, Sep 12, 2016 at 6:22 PM, James Knight <james.knight@rockwellcollins.com> wrote: > > >> + --disable-largefile \ > > > > Why disable? Probably needs a comment in commit message or in .mk file. > > Actually, I cannot recall. I'll investigate and add an appropriate > correction or comment. Actually, from the subset of builds I've tried, it seems to work without this option set (I'll do more testing once I cleaned up the entire patch). That being said, I believe I added the option to help explicitly define as many configurations as possible for the package. I recall being told that the more options you can explicitly set, the better. Looking for example in Buildroot, I don't really see (or just can't find) any generic configuration option which indicates the target system supports large files (to explicitly enable/disable large file support). If it's better just to remove the option and let defaults take place, I don't mind. Just looking for an opinion on the best approach. > > >> + --enable-python=no \ > > > > Doesn't --without-python or --disable-python work? > > Most likely does; will cleanup. After examining the configure[.ac] files, it seems that only the `enable-python` option is checked. By default, Python features are not enabled. If the `enable-python` option is inconsistent with options usually applied, I can just remove it and nothing should really change; but this goes back to my previous comment on whether or not we want to explicitly set all/most configuration options or leaving it to implicitly configure the package. On Tue, Sep 13, 2016 at 2:29 AM, Arnout Vandecappelle <arnout@mind.be> wrote: >>> > Oh, and there's an active upstream at >>> > https://github.com/rpm-software-management/rpm >>> > Could you submit it there (if still relevant)? >> I'll investigate this. I won't be able to try this until next month or >> so, so I hope having these patches for now will suffice/causes no >> complaints. > > No worries. On a plus note, they've pulled in Thomas's the first patch upstream [1] (yay); the second one doesn't really apply anymore due to several changes on the HEAD. I wonder if they ever plan to do another release in the future (I'll try pinging some individuals). At least for now, I'll be hoping to cleanup this current patch and submit it again. Maybe, in the future, if no official release will ever be made, I can try an attempt too pull a stable hash from GitHub and do a series of tests to make sure everything is stable enough. Then we can drop these additional patches. [1]: https://github.com/rpm-software-management/rpm/commit/b5f1895aae096836d6e8e155ee289e1b10fcabcb.patch
On 15-09-16 17:50, James Knight wrote: > On Mon, Sep 12, 2016 at 6:22 PM, James Knight > <james.knight@rockwellcollins.com> wrote: >> >>>> + --disable-largefile \ >>> >>> Why disable? Probably needs a comment in commit message or in .mk file. >> >> Actually, I cannot recall. I'll investigate and add an appropriate >> correction or comment. > > Actually, from the subset of builds I've tried, it seems to work > without this option set (I'll do more testing once I cleaned up the > entire patch). > > That being said, I believe I added the option to help explicitly > define as many configurations as possible for the package. I recall > being told that the more options you can explicitly set, the better. Yes that's true, but the surprising thing is that you pass --disable-largefile while Buildroot always enables largefile: TARGET_CPPFLAGS += -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 > Looking for example in Buildroot, I don't really see (or just can't > find) any generic configuration option which indicates the target > system supports large files (to explicitly enable/disable large file > support). If it's better just to remove the option and let defaults > take place, I don't mind. Just looking for an opinion on the best > approach. See CHANGES, 2015.05-rc1: Toolchains: IPv6 and Largefile support now enforced for uClibc. Corresponding Kconfig symbols removed. > >> >>>> + --enable-python=no \ >>> >>> Doesn't --without-python or --disable-python work? >> >> Most likely does; will cleanup. > > After examining the configure[.ac] files, it seems that only the > `enable-python` option is checked. configure.ac has AC_ARG_ENABLE(python, ...) so --disable-python *should* work. But perhaps they've got some other perversion going on there that breaks it. > By default, Python features are not > enabled. If the `enable-python` option is inconsistent with options > usually applied, I can just remove it and nothing should really > change; but this goes back to my previous comment on whether or not we > want to explicitly set all/most configuration options or leaving it to > implicitly configure the package. It should be explicitly set. It's just that we have the convention of using --disable-foo or --without-foo, rather than --enable-foo=no or --with-foo=no. > On Tue, Sep 13, 2016 at 2:29 AM, Arnout Vandecappelle <arnout@mind.be> wrote: >>>>> Oh, and there's an active upstream at >>>>> https://github.com/rpm-software-management/rpm >>>>> Could you submit it there (if still relevant)? >>> I'll investigate this. I won't be able to try this until next month or >>> so, so I hope having these patches for now will suffice/causes no >>> complaints. >> >> No worries. > > On a plus note, they've pulled in Thomas's the first patch upstream > [1] (yay); the second one doesn't really apply anymore due to several > changes on the HEAD. I wonder if they ever plan to do another release > in the future (I'll try pinging some individuals). At least for now, > I'll be hoping to cleanup this current patch and submit it again. > > Maybe, in the future, if no official release will ever be made, I can > try an attempt too pull a stable hash from GitHub and do a series of > tests to make sure everything is stable enough. Then we can drop these > additional patches. Fedora seems to use the 4.13.0-rc1, so I guess it should be doable. But of course, that one doesn't allow to drop the patches... Regards, Arnout > > [1]: https://github.com/rpm-software-management/rpm/commit/b5f1895aae096836d6e8e155ee289e1b10fcabcb.patch >
diff --git a/package/rpm/0001-configure.ac-use-link-instead-of-compile-for-gcc-fla.patch b/package/rpm/0001-configure.ac-use-link-instead-of-compile-for-gcc-fla.patch new file mode 100644 index 0000000..e3c5da9 --- /dev/null +++ b/package/rpm/0001-configure.ac-use-link-instead-of-compile-for-gcc-fla.patch @@ -0,0 +1,35 @@ +From 840152e36365026631e9fb649eef7f830b074797 Mon Sep 17 00:00:00 2001 +From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> +Date: Sat, 10 Oct 2015 23:17:44 +0200 +Subject: [PATCH 1/2] configure.ac: use link instead of compile for gcc flags + test + +The logic that tests whether gcc supports or not certain flags uses +AC_COMPILE_IFELSE(). However, when checking for stack smashing +protection support, an AC_LINK_IFELSE() test is needed, since the +build might work but not the link stage if certain libraries are +missing for proper stack smashing protection support. + +Therefore, this commit switches to use AC_LINK_IFELSE(). + +Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> +--- + configure.ac | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/configure.ac b/configure.ac +index bb368a9..6ffd472 100644 +--- a/configure.ac ++++ b/configure.ac +@@ -43,7 +43,7 @@ if test "$GCC" = yes; then + echo + for flag in $cflags_to_try; do + CFLAGS="$CFLAGS $flag -Werror" +- AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[]], [[return 0;]])],[ ++ AC_LINK_IFELSE([AC_LANG_PROGRAM([[]], [[return 0;]])],[ + echo " $flag" + RPMCFLAGS="$RPMCFLAGS $flag" + ],[]) +-- +2.6.1 + diff --git a/package/rpm/0002-depends-fix.patch b/package/rpm/0002-depends-fix.patch deleted file mode 100644 index 4a92775..0000000 --- a/package/rpm/0002-depends-fix.patch +++ /dev/null @@ -1,19 +0,0 @@ -Bugfix included upstream - -diff -u --new-file --recursive rpm-5.2.0_vanilla/lib/depends.c rpm-5.2.0_depends-fix/lib/depends.c ---- rpm-5.2.0_vanilla/lib/depends.c 2009-05-23 01:23:46.000000000 +0000 -+++ rpm-5.2.0_depends-fix/lib/depends.c 2009-09-22 06:33:37.950783501 +0000 -@@ -2371,11 +2371,11 @@ - - memset(selected, 0, sizeof(*selected) * ts->orderCount); - -- if ((requires = rpmteDS(p, RPMTAG_REQUIRENAME)) != NULL) { -- - /* Avoid narcisstic relations. */ - selected[rpmtsiOc(pi)] = 1; - -+ if ((requires = rpmteDS(p, RPMTAG_REQUIRENAME)) != NULL) { -+ - /* T2. Next "q <- p" relation. */ - - /* First, do pre-requisites. */ diff --git a/package/rpm/0002-fts-add-quirk-for-__fxstat64-on-uclibc.patch b/package/rpm/0002-fts-add-quirk-for-__fxstat64-on-uclibc.patch new file mode 100644 index 0000000..0ac151f --- /dev/null +++ b/package/rpm/0002-fts-add-quirk-for-__fxstat64-on-uclibc.patch @@ -0,0 +1,28 @@ +From 3e810733e73ef7c2de9eb3f67d44b3d6dce14a97 Mon Sep 17 00:00:00 2001 +From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> +Date: Sun, 11 Oct 2015 12:13:34 +0200 +Subject: [PATCH 2/2] fts: add quirk for __fxstat64 on uclibc + +Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> +--- + misc/fts.c | 4 ++++ + 1 file changed, 4 insertions(+) + +diff --git a/misc/fts.c b/misc/fts.c +index 9fbefe3..57c4106 100644 +--- a/misc/fts.c ++++ b/misc/fts.c +@@ -61,6 +61,10 @@ static char sccsid[] = "@(#)fts.c 8.6 (Berkeley) 8/14/94"; + # define _STAT_VER 0 + # define __fxstat64(_stat_ver, _fd, _sbp) fstat64((_fd), (_sbp)) + #endif ++#include <features.h> ++#if defined(__UCLIBC__) ++# define __fxstat64(_stat_ver, _fd, _sbp) fstat64((_fd), (_sbp)) ++#endif + #include "system.h" + #include <stdlib.h> + #include <string.h> +-- +2.6.1 + diff --git a/package/rpm/0003-exclude-some-tools.patch b/package/rpm/0003-exclude-some-tools.patch deleted file mode 100644 index 2cbc7cb..0000000 --- a/package/rpm/0003-exclude-some-tools.patch +++ /dev/null @@ -1,30 +0,0 @@ -diff -ru rpm-5.2.0_vanilla/tools/Makefile.am rpm-5.2.0_exclude-some-tools/tools/Makefile.am ---- rpm-5.2.0_vanilla/tools/Makefile.am 2009-06-03 01:24:42.000000000 +0000 -+++ rpm-5.2.0_exclude-some-tools/tools/Makefile.am 2009-12-20 07:47:13.000000000 +0000 -@@ -45,9 +45,7 @@ - bin_PROGRAMS = rpm2cpio - - pkgbindir = @USRLIBRPM@/bin --pkgbin_PROGRAMS = \ -- rpmcache rpmdigest grep mtree rpmrepo rpmspecdump wget \ -- rpmcmp rpmdeps @WITH_KEYUTILS_RPMKEY@ @WITH_LIBELF_DEBUGEDIT@ -+pkgbin_PROGRAMS = - dist_man_MANS = rpmgrep.1 - - debugedit_SOURCES = debugedit.c hashtab.c -diff -ru rpm-5.2.0_vanilla/tools/Makefile.in rpm-5.2.0_exclude-some-tools/tools/Makefile.in ---- rpm-5.2.0_vanilla/tools/Makefile.in 2009-07-07 21:14:06.000000000 +0000 -+++ rpm-5.2.0_exclude-some-tools/tools/Makefile.in 2009-12-20 07:47:37.000000000 +0000 -@@ -39,11 +39,7 @@ - target_triplet = @target@ - EXTRA_PROGRAMS = rpmkey$(EXEEXT) debugedit$(EXEEXT) - bin_PROGRAMS = rpm2cpio$(EXEEXT) --pkgbin_PROGRAMS = rpmcache$(EXEEXT) rpmdigest$(EXEEXT) grep$(EXEEXT) \ -- mtree$(EXEEXT) rpmrepo$(EXEEXT) rpmspecdump$(EXEEXT) \ -- wget$(EXEEXT) rpmcmp$(EXEEXT) rpmdeps$(EXEEXT) \ -- @WITH_KEYUTILS_RPMKEY@ @WITH_LIBELF_DEBUGEDIT@ $(am__EXEEXT_1) \ -- $(am__EXEEXT_2) -+pkgbin_PROGRAMS = - @WITH_XAR_TRUE@am__append_1 = txar - @WITH_DB_INTERNAL_TRUE@@WITH_DB_TOOLS_INTEGRATED_TRUE@am__append_2 = db_tool - @WITH_DB_INTERNAL_TRUE@@WITH_DB_RPC_TRUE@@WITH_DB_TOOLS_INTEGRATED_TRUE@am__append_3 = \ diff --git a/package/rpm/0004-ignore-shared-mutexes.patch b/package/rpm/0004-ignore-shared-mutexes.patch deleted file mode 100644 index f19d6b6..0000000 --- a/package/rpm/0004-ignore-shared-mutexes.patch +++ /dev/null @@ -1,12 +0,0 @@ -diff -ru rpm-5.2.0_vanilla/db/env/env_open.c rpm-5.2.0_test/db/env/env_open.c ---- rpm-5.2.0_vanilla/db/env/env_open.c 2008-05-28 01:23:27.000000000 +0000 -+++ rpm-5.2.0_test/db/env/env_open.c 2009-12-24 14:54:55.000000000 +0000 -@@ -124,7 +124,7 @@ - } - } - --#ifdef HAVE_MUTEX_THREAD_ONLY -+#ifdef NK_HAVE_MUTEX_THREAD_ONLY - /* - * Currently we support one kind of mutex that is intra-process only, - * POSIX 1003.1 pthreads, because a variety of systems don't support diff --git a/package/rpm/0005-no-parentdirs.patch b/package/rpm/0005-no-parentdirs.patch deleted file mode 100644 index d05c99a..0000000 --- a/package/rpm/0005-no-parentdirs.patch +++ /dev/null @@ -1,14 +0,0 @@ -Reduce parentdirs we use, parentdirs are used for ordering -Included upstream -diff -u --new-file --recursive rpm-5.1.9_vanilla/lib/depends.c rpm-5.1.9_no-parentdirs/lib/depends.c ---- rpm-5.1.9_vanilla/lib/depends.c 2009-04-12 19:46:17.000000000 +0000 -+++ rpm-5.1.9_no-parentdirs/lib/depends.c 2009-06-13 15:21:43.504999639 +0000 -@@ -2257,7 +2257,7 @@ - #define isAuto(_x) ((_x) & _autobits) - - /*@unchecked@*/ --static int slashDepth = 100; /* #slashes pemitted in parentdir deps. */ -+static int slashDepth = 2; /* #slashes pemitted in parentdir deps. */ - - static int countSlashes(const char * dn) - /*@*/ diff --git a/package/rpm/0006-ordering-fix.patch b/package/rpm/0006-ordering-fix.patch deleted file mode 100644 index a618e1f..0000000 --- a/package/rpm/0006-ordering-fix.patch +++ /dev/null @@ -1,45 +0,0 @@ -Included upstream ---- x/lib/depends.c 2009/05/15 13:40:58 1.445 -+++ y/lib/depends.c 2009/08/22 22:12:02 1.446 -@@ -2216,9 +2216,6 @@ - { - rpmte q, qprev; - -- /* Mark the package as queued. */ -- rpmteTSI(p)->tsi_queued = 1; -- - if ((*rp) == NULL) { /* 1st element */ - /*@-dependenttrans@*/ /* FIX: double indirection */ - (*rp) = (*qp) = p; -@@ -2238,6 +2235,12 @@ - /* XXX Insure removed after added. */ - if (rpmteType(p) == TR_REMOVED && rpmteType(p) != rpmteType(q)) - continue; -+ -+ /* XXX Follow all previous generations in the queue. */ -+ if (rpmteTSI(p)->tsi_queued > rpmteTSI(q)->tsi_queued) -+ continue; -+ -+ /* XXX Within a generation, queue behind more "important". */ - if (rpmteTSI(q)->tsi_qcnt <= rpmteTSI(p)->tsi_qcnt) - break; - } -@@ -2521,6 +2524,9 @@ - - if (rpmteTSI(p)->tsi_count != 0) - continue; -+ -+ /* Mark the package as queued. */ -+ rpmteTSI(p)->tsi_queued = orderingCount + 1; - rpmteTSI(p)->tsi_suc = NULL; - addQ(p, &q, &r, prefcolor); - qlen++; -@@ -2584,6 +2590,8 @@ - (void) rpmteSetParent(p, q); - (void) rpmteSetDegree(q, rpmteDegree(q)+1); - -+ /* Mark the package as queued. */ -+ rpmteTSI(p)->tsi_queued = orderingCount + 1; - /* XXX TODO: add control bit. */ - rpmteTSI(p)->tsi_suc = NULL; - /*@-nullstate@*/ /* XXX FIX: rpmteTSI(q)->tsi_suc can be NULL. */ diff --git a/package/rpm/0007-parentdir-vs-requires.patch b/package/rpm/0007-parentdir-vs-requires.patch deleted file mode 100644 index 309ab25..0000000 --- a/package/rpm/0007-parentdir-vs-requires.patch +++ /dev/null @@ -1,37 +0,0 @@ -Avoid looking up files or directories that this package provides -Included upstream -diff -u --new-file --recursive rpm-5.2.0_vanilla/lib/depends.c rpm-5.2.0_parentdir-vs-requires/lib/depends.c ---- rpm-5.2.0_vanilla/lib/depends.c 2009-05-23 01:23:46.000000000 +0000 -+++ rpm-5.2.0_parentdir-vs-requires/lib/depends.c 2009-09-22 17:00:24.880956271 +0000 -@@ -2095,6 +2095,7 @@ - rpmtsi qi; rpmte q; - tsortInfo tsi; - nsType NSType = rpmdsNSType(requires); -+ const char * N = rpmdsN(requires); - fnpyKey key; - int teType = rpmteType(p); - alKey pkgKey; -@@ -2128,6 +2129,23 @@ - break; - } - -+ /* Avoid looking up files/directories that are "owned" by _THIS_ package. */ -+ if (*N == '/') { -+ rpmfi fi = rpmteFI(p, RPMTAG_BASENAMES); -+ int bingo = 0; -+ -+ fi = rpmfiInit(fi, 0); -+ while (rpmfiNext(fi) >= 0) { -+ const char * fn = rpmfiFN(fi); -+ if (strcmp(N, fn)) -+ continue; -+ bingo = 1; -+ break; -+ } -+ if (bingo) -+ return 0; -+ } -+ - pkgKey = RPMAL_NOMATCH; - key = rpmalSatisfiesDepend(al, requires, &pkgKey); - diff --git a/package/rpm/0008-short-circuit-c99.patch b/package/rpm/0008-short-circuit-c99.patch deleted file mode 100644 index 5d7b53a..0000000 --- a/package/rpm/0008-short-circuit-c99.patch +++ /dev/null @@ -1,235 +0,0 @@ -Buildroot specific -diff -ru rpm-5.1.9_vanilla/xz/configure rpm-5.1.9_short-circuit-c99/xz/configure ---- rpm-5.1.9_vanilla/xz/configure 2009-04-18 16:47:23.000000000 +0000 -+++ rpm-5.1.9_short-circuit-c99/xz/configure 2009-08-04 08:25:59.000000000 +0000 -@@ -4970,214 +4970,7 @@ - am__fastdepCC_FALSE= - fi - -- -- { $as_echo "$as_me:$LINENO: checking for $CC option to accept ISO C99" >&5 --$as_echo_n "checking for $CC option to accept ISO C99... " >&6; } --if test "${ac_cv_prog_cc_c99+set}" = set; then -- $as_echo_n "(cached) " >&6 --else -- ac_cv_prog_cc_c99=no --ac_save_CC=$CC --cat >conftest.$ac_ext <<_ACEOF --/* confdefs.h. */ --_ACEOF --cat confdefs.h >>conftest.$ac_ext --cat >>conftest.$ac_ext <<_ACEOF --/* end confdefs.h. */ --#include <stdarg.h> --#include <stdbool.h> --#include <stdlib.h> --#include <wchar.h> --#include <stdio.h> -- --// Check varargs macros. These examples are taken from C99 6.10.3.5. --#define debug(...) fprintf (stderr, __VA_ARGS__) --#define showlist(...) puts (#__VA_ARGS__) --#define report(test,...) ((test) ? puts (#test) : printf (__VA_ARGS__)) --static void --test_varargs_macros (void) --{ -- int x = 1234; -- int y = 5678; -- debug ("Flag"); -- debug ("X = %d\n", x); -- showlist (The first, second, and third items.); -- report (x>y, "x is %d but y is %d", x, y); --} -- --// Check long long types. --#define BIG64 18446744073709551615ull --#define BIG32 4294967295ul --#define BIG_OK (BIG64 / BIG32 == 4294967297ull && BIG64 % BIG32 == 0) --#if !BIG_OK -- your preprocessor is broken; --#endif --#if BIG_OK --#else -- your preprocessor is broken; --#endif --static long long int bignum = -9223372036854775807LL; --static unsigned long long int ubignum = BIG64; -- --struct incomplete_array --{ -- int datasize; -- double data[]; --}; -- --struct named_init { -- int number; -- const wchar_t *name; -- double average; --}; -- --typedef const char *ccp; -- --static inline int --test_restrict (ccp restrict text) --{ -- // See if C++-style comments work. -- // Iterate through items via the restricted pointer. -- // Also check for declarations in for loops. -- for (unsigned int i = 0; *(text+i) != '\0'; ++i) -- continue; -- return 0; --} -- --// Check varargs and va_copy. --static void --test_varargs (const char *format, ...) --{ -- va_list args; -- va_start (args, format); -- va_list args_copy; -- va_copy (args_copy, args); -- -- const char *str; -- int number; -- float fnumber; -- -- while (*format) -- { -- switch (*format++) -- { -- case 's': // string -- str = va_arg (args_copy, const char *); -- break; -- case 'd': // int -- number = va_arg (args_copy, int); -- break; -- case 'f': // float -- fnumber = va_arg (args_copy, double); -- break; -- default: -- break; -- } -- } -- va_end (args_copy); -- va_end (args); --} -- --int --main () --{ -- -- // Check bool. -- _Bool success = false; -- -- // Check restrict. -- if (test_restrict ("String literal") == 0) -- success = true; -- char *restrict newvar = "Another string"; -- -- // Check varargs. -- test_varargs ("s, d' f .", "string", 65, 34.234); -- test_varargs_macros (); -- -- // Check flexible array members. -- struct incomplete_array *ia = -- malloc (sizeof (struct incomplete_array) + (sizeof (double) * 10)); -- ia->datasize = 10; -- for (int i = 0; i < ia->datasize; ++i) -- ia->data[i] = i * 1.234; -- -- // Check named initializers. -- struct named_init ni = { -- .number = 34, -- .name = L"Test wide string", -- .average = 543.34343, -- }; -- -- ni.number = 58; -- -- int dynamic_array[ni.number]; -- dynamic_array[ni.number - 1] = 543; -- -- // work around unused variable warnings -- return (!success || bignum == 0LL || ubignum == 0uLL || newvar[0] == 'x' -- || dynamic_array[ni.number - 1] != 543); -- -- ; -- return 0; --} --_ACEOF --for ac_arg in '' -std=gnu99 -std=c99 -c99 -AC99 -xc99=all -qlanglvl=extc99 --do -- CC="$ac_save_CC $ac_arg" -- rm -f conftest.$ac_objext --if { (ac_try="$ac_compile" --case "(($ac_try" in -- *\"* | *\`* | *\\*) ac_try_echo=\$ac_try;; -- *) ac_try_echo=$ac_try;; --esac --eval ac_try_echo="\"\$as_me:$LINENO: $ac_try_echo\"" --$as_echo "$ac_try_echo") >&5 -- (eval "$ac_compile") 2>conftest.er1 -- ac_status=$? -- grep -v '^ *+' conftest.er1 >conftest.err -- rm -f conftest.er1 -- cat conftest.err >&5 -- $as_echo "$as_me:$LINENO: \$? = $ac_status" >&5 -- (exit $ac_status); } && { -- test -z "$ac_c_werror_flag" || -- test ! -s conftest.err -- } && test -s conftest.$ac_objext; then -- ac_cv_prog_cc_c99=$ac_arg --else -- $as_echo "$as_me: failed program was:" >&5 --sed 's/^/| /' conftest.$ac_ext >&5 -- -- --fi -- --rm -f core conftest.err conftest.$ac_objext -- test "x$ac_cv_prog_cc_c99" != "xno" && break --done --rm -f conftest.$ac_ext --CC=$ac_save_CC -- --fi --# AC_CACHE_VAL --case "x$ac_cv_prog_cc_c99" in -- x) -- { $as_echo "$as_me:$LINENO: result: none needed" >&5 --$as_echo "none needed" >&6; } ;; -- xno) -- { $as_echo "$as_me:$LINENO: result: unsupported" >&5 --$as_echo "unsupported" >&6; } ;; -- *) -- CC="$CC $ac_cv_prog_cc_c99" -- { $as_echo "$as_me:$LINENO: result: $ac_cv_prog_cc_c99" >&5 --$as_echo "$ac_cv_prog_cc_c99" >&6; } ;; --esac -- -- -- --if test x$ac_cv_prog_cc_c99 = xno ; then -- { { $as_echo "$as_me:$LINENO: error: No C99 compiler was found." >&5 --$as_echo "$as_me: error: No C99 compiler was found." >&2;} -- { (exit 1); exit 1; }; } --fi -+CC="$CC -std=c99" - - if test "x$CC" != xcc; then - { $as_echo "$as_me:$LINENO: checking whether $CC and cc understand -c and -o together" >&5 -diff -ru rpm-5.1.9_vanilla/xz/configure.ac rpm-5.1.9_short-circuit-c99/xz/configure.ac ---- rpm-5.1.9_vanilla/xz/configure.ac 2009-02-16 17:07:46.000000000 +0000 -+++ rpm-5.1.9_short-circuit-c99/xz/configure.ac 2009-08-04 08:25:28.000000000 +0000 -@@ -402,10 +402,7 @@ - AM_INIT_AUTOMAKE([1.10 foreign tar-v7 filename-length-max=99]) - AC_PROG_LN_S - --AC_PROG_CC_C99 --if test x$ac_cv_prog_cc_c99 = xno ; then -- AC_MSG_ERROR([No C99 compiler was found.]) --fi -+CC="$CC -std=c99" - - AM_PROG_CC_C_O - AM_PROG_AS diff --git a/package/rpm/Config.in b/package/rpm/Config.in index 2be646a..e80a69a 100644 --- a/package/rpm/Config.in +++ b/package/rpm/Config.in @@ -1,28 +1,21 @@ -comment "rpm needs a toolchain w/ threads" - depends on !BR2_TOOLCHAIN_HAS_THREADS - depends on BR2_USE_MMU # fork() +comment "rpm needs a uClibc or glibc toolchain w/ threads" + depends on !BR2_TOOLCHAIN_HAS_THREADS || BR2_TOOLCHAIN_USES_MUSL depends on BR2_PACKAGE_BUSYBOX_SHOW_OTHERS - -comment "rpm needs a toolchain w/ gcc >= 5" - depends on !BR2_TOOLCHAIN_GCC_AT_LEAST_5 && BR2_sh + depends on BR2_USE_MMU config BR2_PACKAGE_RPM bool "rpm" - # triggers internal compiler error - depends on BR2_TOOLCHAIN_GCC_AT_LEAST_5 || !BR2_sh + depends on !BR2_TOOLCHAIN_USES_MUSL # __fxstat64, _D_EXACT_NAMELEN + depends on BR2_PACKAGE_BUSYBOX_SHOW_OTHERS depends on BR2_TOOLCHAIN_HAS_THREADS # beecrypt depends on BR2_USE_MMU # fork() - depends on BR2_PACKAGE_BUSYBOX_SHOW_OTHERS - select BR2_PACKAGE_BEECRYPT + select BR2_PACKAGE_BEECRYPT if !BR2_PACKAGE_LIBNSS + select BR2_PACKAGE_BERKELEYDB + select BR2_PACKAGE_FILE select BR2_PACKAGE_GETTEXT if BR2_NEEDS_GETTEXT_IF_LOCALE - select BR2_PACKAGE_NEON - select BR2_PACKAGE_NEON_SSL - select BR2_PACKAGE_NEON_XML - select BR2_PACKAGE_NEON_ZLIB - select BR2_PACKAGE_OPENSSL select BR2_PACKAGE_POPT select BR2_PACKAGE_ZLIB help - The RPM package management system. + The RPM Package Manager (RPM). - http://rpm5.org + http://www.rpm.org/ diff --git a/package/rpm/rpm.hash b/package/rpm/rpm.hash index 0665746..e579fa4 100644 --- a/package/rpm/rpm.hash +++ b/package/rpm/rpm.hash @@ -1,2 +1,2 @@ -# Locally calculated -sha256 34a959c0ed670cadcdc52c6025e822fac6f5d1015e3b75123f53ebe53b923e98 rpm-5.2.0.tar.gz +# From http://rpm.org/wiki/Releases/4.12.0.1 +sha1 d416bdb249b246b00b2d5d34c66e7f5a68a62524 rpm-4.12.0.1.tar.bz2 diff --git a/package/rpm/rpm.mk b/package/rpm/rpm.mk index 7f346b2..a022ae9 100644 --- a/package/rpm/rpm.mk +++ b/package/rpm/rpm.mk @@ -4,61 +4,67 @@ # ################################################################################ -RPM_VERSION_MAJOR = 5.2 -RPM_VERSION = $(RPM_VERSION_MAJOR).0 -RPM_SITE = http://rpm5.org/files/rpm/rpm-$(RPM_VERSION_MAJOR) -RPM_DEPENDENCIES = host-pkgconf zlib beecrypt neon popt openssl -RPM_LICENSE = LGPLv2.1 -RPM_LICENSE_FILES = COPYING.LIB +RPM_VERSION_MAJOR = 4.12 +RPM_VERSION = $(RPM_VERSION_MAJOR).0.1 +RPM_SOURCE = rpm-$(RPM_VERSION).tar.bz2 +RPM_SITE = http://rpm.org/releases/rpm-$(RPM_VERSION_MAJOR).x +RPM_DEPENDENCIES = host-pkgconf berkeleydb file popt zlib +RPM_LICENSE = GPLv2 +RPM_LICENSE_FILES = COPYING -RPM_CONF_ENV = \ - CFLAGS="$(TARGET_CFLAGS) -I$(STAGING_DIR)/usr/include/beecrypt -I$(STAGING_DIR)/usr/include/neon -DHAVE_MUTEX_THREAD_ONLY" \ - ac_cv_va_copy=yes +# 0001-configure.ac-use-link-instead-of-compile-for-gcc-fla.patch +RPM_AUTORECONF = YES -RPM_CONF_OPTS = \ - --disable-build-versionscript \ +RPM_CONF_OPTS += \ + --disable-largefile \ --disable-rpath \ - --without-selinux \ - --without-python \ - --without-perl \ - --with-openssl=external \ - --with-zlib=external \ - --with-libbeecrypt=$(STAGING_DIR) \ - --with-popt=external + --enable-python=no \ + --with-external-db \ + --with-gnu-ld \ + --without-cap \ + --without-hackingdocs \ + --without-lua -ifeq ($(BR2_NEEDS_GETTEXT_IF_LOCALE),y) -RPM_DEPENDENCIES += gettext +ifeq ($(BR2_PACKAGE_ACL),y) +RPM_DEPENDENCIES += acl +RPM_CONF_OPTS += --with-acl +else +RPM_CONF_OPTS += --without-acl endif -ifeq ($(BR2_PACKAGE_PCRE),y) -RPM_DEPENDENCIES += pcre -RPM_CONF_OPTS += --with-pcre=external +ifeq ($(BR2_PACKAGE_BEECRYPT),y) +RPM_DEPENDENCIES += beecrypt +RPM_CONF_OPTS += --with-beecrypt +RPM_CFLAGS += -I$(STAGING_DIR)/usr/include/beecrypt else -RPM_CONF_OPTS += --with-pcre=none +RPM_DEPENDENCIES += libnss +RPM_CONF_OPTS += --without-beecrypt +RPM_CFLAGS += -I$(STAGING_DIR)/usr/include/nss -I$(STAGING_DIR)/usr/include/nspr endif -ifeq ($(BR2_PACKAGE_FILE),y) -RPM_DEPENDENCIES += file -RPM_CONF_OPTS += --with-file=external +ifeq ($(BR2_NEEDS_GETTEXT_IF_LOCALE),y) +RPM_DEPENDENCIES += gettext +RPM_CONF_OPTS += --with-libintl-prefix=$(STAGING_DIR)/usr else -RPM_CONF_OPTS += --with-file=none +RPM_CONF_OPTS += --without-libintl-prefix endif -# xz payload support needs a toolchain w/ C++ -ifeq ($(BR2_PACKAGE_XZ)$(BR2_INSTALL_LIBSTDCPP),yy) -RPM_DEPENDENCIES += xz -RPM_CONF_OPTS += --with-xz=external +ifeq ($(BR2_PACKAGE_LIBARCHIVE),y) +RPM_DEPENDENCIES += libarchive +RPM_CONF_OPTS += --with-archive else -RPM_CONF_OPTS += --with-xz=none +RPM_CONF_OPTS += --without-archive endif -ifeq ($(BR2_PACKAGE_BZIP2),y) -RPM_CONF_OPTS += --with-bzip2 -RPM_DEPENDENCIES += bzip2 +ifeq ($(BR2_PACKAGE_LIBSELINUX),y) +RPM_DEPENDENCIES += libselinux +RPM_CONF_OPTS += --with-selinux +else +RPM_CONF_OPTS += --without-selinux endif -RPM_MAKE = $(MAKE1) - -RPM_INSTALL_TARGET_OPTS = DESTDIR=$(TARGET_DIR) program_transform_name= install +RPM_CONF_ENV += \ + ac_cv_prog_cc_c99='-std=gnu99' \ + CFLAGS="$(TARGET_CFLAGS) $(RPM_CFLAGS)" $(eval $(autotools-package))
The provided switches from the RPM5 implementation to rpm.org's stream. Signed-off-by: James Knight <james.knight@rockwellcollins.com> --- Changes v4 -> v5: - Adjusting `RPM_CONFIGURATION` variable to `RPM_CFLAGS` for consistency (suggested by Thomas Petazzoni). - Adding support for uClibc and explicitly disabling musl support (based on Thomas Petazzoni's comments and other tests). - Adding `-std=gnu99` flag. - Dropped Lua support as Buildroot's version of Lua is too new for it to work. - Note: Dropped host-support patches from this change set (just a single patch request now; will come back to this later). Changes v3 -> v4: - Adjusting package's hash to use hash value provided from official sources. - Always build package without libcap. The initial patch (noticed by Peter Korsgaard) did not correctly configure the rpm package to use libcap. Adjusting the Makefile to correctly configure to use libcap results in some build issues. I'm hoping to include libcap support when rpm 4.13.0.1 is released; in the meantime, disabling libcap support. Changes v2 -> v3: - Cleanup configuration dependency to beecrypt/libnss; following convention (suggested by Baruch Siach). Changes v1 -> v2: - Package change introduced in change set 2. --- ...c-use-link-instead-of-compile-for-gcc-fla.patch | 35 +++ package/rpm/0002-depends-fix.patch | 19 -- ...02-fts-add-quirk-for-__fxstat64-on-uclibc.patch | 28 +++ package/rpm/0003-exclude-some-tools.patch | 30 --- package/rpm/0004-ignore-shared-mutexes.patch | 12 -- package/rpm/0005-no-parentdirs.patch | 14 -- package/rpm/0006-ordering-fix.patch | 45 ---- package/rpm/0007-parentdir-vs-requires.patch | 37 ---- package/rpm/0008-short-circuit-c99.patch | 235 --------------------- package/rpm/Config.in | 27 +-- package/rpm/rpm.hash | 4 +- package/rpm/rpm.mk | 84 ++++---- 12 files changed, 120 insertions(+), 450 deletions(-) create mode 100644 package/rpm/0001-configure.ac-use-link-instead-of-compile-for-gcc-fla.patch delete mode 100644 package/rpm/0002-depends-fix.patch create mode 100644 package/rpm/0002-fts-add-quirk-for-__fxstat64-on-uclibc.patch delete mode 100644 package/rpm/0003-exclude-some-tools.patch delete mode 100644 package/rpm/0004-ignore-shared-mutexes.patch delete mode 100644 package/rpm/0005-no-parentdirs.patch delete mode 100644 package/rpm/0006-ordering-fix.patch delete mode 100644 package/rpm/0007-parentdir-vs-requires.patch delete mode 100644 package/rpm/0008-short-circuit-c99.patch