[Buildroot] [PATCH 1/2] coreutils: Do not install uptime

[Buildroot] [PATCH 1/2] coreutils: Do not install uptime

[Vicente Olivert Riera]

coreutils' uptime doesn't work and its execution fails with a message
like this one:

  uptime: couldn't get boot time: No such file or directory

busybox and procps-ng provide a working alternative.

This is a common old problem as we can see here:

  https://lists.openwrt.org/pipermail/openwrt-devel/2011-March/010006.html

Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Reviewed-by: Markos.Chandras <Markos.Chandras@imgtec.com>
---
 package/coreutils/coreutils.mk |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/package/coreutils/coreutils.mk b/package/coreutils/coreutils.mk
index 07a1347..7457b79 100644
--- a/package/coreutils/coreutils.mk
+++ b/package/coreutils/coreutils.mk
@@ -61,7 +61,8 @@ COREUTILS_CONF_ENV = ac_cv_c_restrict=no \
 		PERL=missing
 
 COREUTILS_CONF_OPT = --disable-rpath \
-		--enable-install-program=hostname
+		--enable-install-program=hostname \
+		--enable-no-install-program=uptime
 
 define COREUTILS_POST_INSTALL
 	# some things go in root rather than usr
-- 
1.7.1

[Buildroot] [PATCH 2/2] procps-ng: Fix installation and take precedence over busybox

[Vicente Olivert Riera]

Currently procps-ng binaries are installed under $(TARGET_DIR)/usr/usr
instead of $(TARGET_DIR)/usr, which would be the expected. This is
caused because the default value of the --exec-prefix configure option
is /usr, and Buildroot always adds --prefix=/usr to the configure
option. We fix this by setting --exec-prefix to an empty value.

At the same time we make sure the procps-ng binaries have precedence
over the busybox ones.

Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Reviewed-by: Markos.Chandras <Markos.Chandras@imgtec.com>
---
 package/procps-ng/procps-ng.mk |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/package/procps-ng/procps-ng.mk b/package/procps-ng/procps-ng.mk
index c327b4f..cedd667 100644
--- a/package/procps-ng/procps-ng.mk
+++ b/package/procps-ng/procps-ng.mk
@@ -13,9 +13,19 @@ PROCPS_NG_INSTALL_STAGING = YES
 
 PROCPS_NG_DEPENDENCIES = ncurses
 
+# If both procps-ng and busybox are selected, make certain procps-ng
+# wins the fight over who gets to have their utils actually installed.
+ifeq ($(BR2_PACKAGE_BUSYBOX),y)
+PROCPS_NG_DEPENDENCIES += busybox
+endif
+
 ifeq ($(BR2_NEEDS_GETTEXT_IF_LOCALE),y)
 PROCPS_NG_DEPENDENCIES += gettext
 PROCPS_NG_CONF_OPT += LIBS=-lintl
 endif
 
+# We need this to make procps-ng binaries installed in $(TARGET_DIR)/usr
+# instead of $(TARGET_DIR)/usr/usr
+PROCPS_NG_CONF_OPT += --exec-prefix=
+
 $(eval $(autotools-package))
-- 
1.7.1

[Buildroot] [PATCH 2/2] procps-ng: Fix installation and take precedence over busybox

[Thomas Petazzoni]

Dear Vicente Olivert Riera,

On Wed, 10 Sep 2014 15:30:06 +0100, Vicente Olivert Riera wrote:
> Currently procps-ng binaries are installed under $(TARGET_DIR)/usr/usr
> instead of $(TARGET_DIR)/usr, which would be the expected. This is
> caused because the default value of the --exec-prefix configure option
> is /usr, and Buildroot always adds --prefix=/usr to the configure
> option. We fix this by setting --exec-prefix to an empty value.
> 
> At the same time we make sure the procps-ng binaries have precedence
> over the busybox ones.
> 
> Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
> Reviewed-by: Markos.Chandras <Markos.Chandras@imgtec.com>
> ---
>  package/procps-ng/procps-ng.mk |   10 ++++++++++
>  1 files changed, 10 insertions(+), 0 deletions(-)

Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH 2/2] procps-ng: Fix installation and take precedence over busybox

[Peter Korsgaard]

>>>>> "Vicente" == Vicente Olivert Riera <Vincent.Riera@imgtec.com> writes:

 > Currently procps-ng binaries are installed under $(TARGET_DIR)/usr/usr
 > instead of $(TARGET_DIR)/usr, which would be the expected. This is
 > caused because the default value of the --exec-prefix configure option
 > is /usr, and Buildroot always adds --prefix=/usr to the configure
 > option. We fix this by setting --exec-prefix to an empty value.

 > At the same time we make sure the procps-ng binaries have precedence
 > over the busybox ones.

 > Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
 > Reviewed-by: Markos.Chandras <Markos.Chandras@imgtec.com>

Committed, thanks.

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH 1/2] coreutils: Do not install uptime

[Thomas Petazzoni]

Dear Vicente Olivert Riera,

On Wed, 10 Sep 2014 15:30:05 +0100, Vicente Olivert Riera wrote:
> coreutils' uptime doesn't work and its execution fails with a message
> like this one:
> 
>   uptime: couldn't get boot time: No such file or directory
> 
> busybox and procps-ng provide a working alternative.
> 
> This is a common old problem as we can see here:
> 
>   https://lists.openwrt.org/pipermail/openwrt-devel/2011-March/010006.html
> 
> Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
> Reviewed-by: Markos.Chandras <Markos.Chandras@imgtec.com>
> ---
>  package/coreutils/coreutils.mk |    3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
> 
> diff --git a/package/coreutils/coreutils.mk b/package/coreutils/coreutils.mk
> index 07a1347..7457b79 100644
> --- a/package/coreutils/coreutils.mk
> +++ b/package/coreutils/coreutils.mk
> @@ -61,7 +61,8 @@ COREUTILS_CONF_ENV = ac_cv_c_restrict=no \
>  		PERL=missing
>  
>  COREUTILS_CONF_OPT = --disable-rpath \
> -		--enable-install-program=hostname
> +		--enable-install-program=hostname \
> +		--enable-no-install-program=uptime

I think this is not the proper fix. A more appropriate fix is to
actually get uptime to work, which is a oneliner. See my patch posted
at http://patchwork.ozlabs.org/patch/387971/.

I'll mark your patch as Rejected in patchwork. Of course, if you
disagree, feel free to turn back your patch to the "New" state with an
explanation.

Thanks a lot for noticing this issue in the first place!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH 1/2] coreutils: Do not install uptime

[Vicente Olivert Riera]

On 09/10/2014 09:45 PM, Thomas Petazzoni wrote:
> Dear Vicente Olivert Riera,
>
> On Wed, 10 Sep 2014 15:30:05 +0100, Vicente Olivert Riera wrote:
>> coreutils' uptime doesn't work and its execution fails with a message
>> like this one:
>>
>>    uptime: couldn't get boot time: No such file or directory
>>
>> busybox and procps-ng provide a working alternative.
>>
>> This is a common old problem as we can see here:
>>
>>    https://lists.openwrt.org/pipermail/openwrt-devel/2011-March/010006.html
>>
>> Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
>> Reviewed-by: Markos.Chandras <Markos.Chandras@imgtec.com>
>> ---
>>   package/coreutils/coreutils.mk |    3 ++-
>>   1 files changed, 2 insertions(+), 1 deletions(-)
>>
>> diff --git a/package/coreutils/coreutils.mk b/package/coreutils/coreutils.mk
>> index 07a1347..7457b79 100644
>> --- a/package/coreutils/coreutils.mk
>> +++ b/package/coreutils/coreutils.mk
>> @@ -61,7 +61,8 @@ COREUTILS_CONF_ENV = ac_cv_c_restrict=no \
>>   		PERL=missing
>>
>>   COREUTILS_CONF_OPT = --disable-rpath \
>> -		--enable-install-program=hostname
>> +		--enable-install-program=hostname \
>> +		--enable-no-install-program=uptime
>
> I think this is not the proper fix. A more appropriate fix is to
> actually get uptime to work, which is a oneliner. See my patch posted
> at http://patchwork.ozlabs.org/patch/387971/.

I have tested it and it works fine.

> I'll mark your patch as Rejected in patchwork. Of course, if you
> disagree, feel free to turn back your patch to the "New" state with an
> explanation.

I don't disagree. I also think it's better to have a working coreutils' 
uptime instead of disabling it.

> Thanks a lot for noticing this issue in the first place!

You are welcome.

> Thomas

-- 
Vincent