diff mbox

[v4,1/4] package/rpm: bump to version 4.12.0.1

Message ID 20151011143414.4bf27c78@free-electrons.com
State Not Applicable
Headers show

Commit Message

Thomas Petazzoni Oct. 11, 2015, 12:34 p.m. UTC 
James,

On Mon,  5 Oct 2015 16:26:56 -0400, James Knight wrote:
> The provided "bump" (suggested by Baruch Siach) switches from the rpm5
> implementation to rpm.org's more active stream.
> 
> Signed-off-by: James Knight <james.knight@rockwellcollins.com>

> -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
> -
> -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
>  
> -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_CONFIGURATION += -I$(STAGING_DIR)/usr/include/beecrypt

This should be named RPM_CFLAGS instead, it's more logical and
consistent with what we do in other packages.

Also, I had some issues building your package with uClibc and musl:

 - the check for -fstack-protector doesn't work properly. I've written
   a patch to fix this (attached). You need to set RPM_AUTORECONF = YES
   to use this patch.

 - uclibc and musl don't provide __fxstat64(). I've written a fix that
   works for uclibc (attached). But it doesn't work as is for musl
   since musl doesn't provide a __MUSL__ symbol, so you need to do a
   proper configure.ac check.

 - when building with musl, _D_EXACT_NAMELEN is missing.

So could you rework this package to make it work with musl/uclibc or
alternatively mark it as not available for these C libraries if you are
not interested in supporting this use case.

In the mean time, I'll mark your patches as "Changes Requested" in
patchwork.

Thanks!

Thomas

Comments

James Knight Oct. 16, 2015, 3:09 p.m. UTC | #1 
Thomas,

On Sun, Oct 11, 2015 at 8:34 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> So could you rework this package to make it work with musl/uclibc

Thanks for checking this; I'll give it a shot. :)

> In the mean time, I'll mark your patches as "Changes Requested" in
> patchwork.

Minor patchwork question, when a patch has been flagged as "Changes
Requested" and I submit a new one, should I flag the old patch as
superseded?
Thomas Petazzoni Oct. 16, 2015, 3:19 p.m. UTC | #2 
Dear James Knight,

On Fri, 16 Oct 2015 11:09:47 -0400, James Knight wrote:

> On Sun, Oct 11, 2015 at 8:34 AM, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
> > So could you rework this package to make it work with musl/uclibc
> 
> Thanks for checking this; I'll give it a shot. :)
> 
> > In the mean time, I'll mark your patches as "Changes Requested" in
> > patchwork.
> 
> Minor patchwork question, when a patch has been flagged as "Changes
> Requested" and I submit a new one, should I flag the old patch as
> superseded?

You can do it if you want, but that's really not necessary. When a
patch is either in the "Changes Requested" state or the "Superseded"
state, we simply no longer see in the list of pending patches. This
means we won't care anymore about such patches, until the submitter
sends an updated version.

We never go back to older patches marked "Changes Requested" to change
them to "Superseded" when the new version comes.

Thomas
diff mbox

Patch

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