[Buildroot] [PATCH v3] ejabberd: new package

[Buildroot] [PATCH v3] ejabberd: new package

[Johan Oudinet]

Signed-off-by: Johan Oudinet <johan.oudinet@gmail.com>
---
Changes v2 -> v3:
  - Add system V init script.
Changes v1 -> v2:
  - Run ejabberd as ejabberd user instead of root.
---
 package/Config.in                 |  1 +
 package/ejabberd/Config.in        | 13 ++++++
 package/ejabberd/S50ejabberd      | 29 +++++++++++++
 package/ejabberd/check-erlang-lib | 48 ++++++++++++++++++++++
 package/ejabberd/ejabberd.mk      | 86 +++++++++++++++++++++++++++++++++++++++
 5 files changed, 177 insertions(+)
 create mode 100644 package/ejabberd/Config.in
 create mode 100644 package/ejabberd/S50ejabberd
 create mode 100755 package/ejabberd/check-erlang-lib
 create mode 100644 package/ejabberd/ejabberd.mk

diff --git a/package/Config.in b/package/Config.in
index 22ddea8..eb0aaaa 100644
--- a/package/Config.in
+++ b/package/Config.in
@@ -943,6 +943,7 @@ endif
 	source "package/dnsmasq/Config.in"
 	source "package/dropbear/Config.in"
 	source "package/ebtables/Config.in"
+	source "package/ejabberd/Config.in"
 	source "package/ethtool/Config.in"
 	source "package/faifa/Config.in"
 	source "package/fmc/Config.in"
diff --git a/package/ejabberd/Config.in b/package/ejabberd/Config.in
new file mode 100644
index 0000000..3a2336d
--- /dev/null
+++ b/package/ejabberd/Config.in
@@ -0,0 +1,13 @@
+config BR2_PACKAGE_EJABBERD
+       bool "ejabberd"
+       select BR2_PACKAGE_OPENSSL
+       select BR2_PACKAGE_ERLANG
+       select BR2_PACKAGE_LIBYAML
+       select BR2_PACKAGE_LIBICONV if !BR2_ENABLE_LOCALE
+       select BR2_PACKAGE_EXPAT
+       help
+	 Ejabberd is a Jabber/XMPP instant messaging server, written
+	 in Erlang/OTP. Among other features, ejabberd is
+	 cross-platform, fault-tolerant, clusterable and modular.
+
+	 http://www.ejabberd.im
diff --git a/package/ejabberd/S50ejabberd b/package/ejabberd/S50ejabberd
new file mode 100644
index 0000000..a156bc2
--- /dev/null
+++ b/package/ejabberd/S50ejabberd
@@ -0,0 +1,29 @@
+#!/bin/sh
+#
+# Start/stop ejabberd
+#
+
+case "$1" in
+    start)
+	echo "Starting ejabberd..."
+	ejabberdctl start
+	;;
+    stop)
+	echo -n "Stopping ejabberd... "
+	ejabberdctl stop > /dev/null
+	if [ $? -eq 3 ] || ejabberdctl stopped; then
+	    echo "OK"
+	else
+	    echo "failed"
+	fi
+	;;
+    restart|reload)
+	"$0" stop
+	"$0" start
+	;;
+    *)
+	echo "Usage: $0 {start|stop|restart}"
+	exit 1
+esac
+
+exit $?
diff --git a/package/ejabberd/check-erlang-lib b/package/ejabberd/check-erlang-lib
new file mode 100755
index 0000000..1a942bb
--- /dev/null
+++ b/package/ejabberd/check-erlang-lib
@@ -0,0 +1,48 @@
+#!/bin/sh -e
+# Helper to bypass AC_ERLANG_CHECK_LIB
+
+usage() {
+    cat <<EOF
+Usage:
+	$0 library
+Look for Erlang's library in TARGET_DIR/usr/lib/erlang/lib.
+
+If the library is found, it returns the path to the latest version,
+relative to TARGET_DIR. Otherwise, it returns "not found".
+
+If there are several versions, it returns an error because it does not
+know which one Erlang uses.
+
+EOF
+}
+
+die () {
+    echo "$@" >&2
+    exit 1
+}
+
+if [ $# -ne 1 ]; then
+    usage
+    exit 0
+else
+    library="$1"
+fi
+
+target_dir="${TARGET_DIR:-../../output/target}"
+
+[ -d "$target_dir" ] || die "TARGET_DIR is not a directory. Please \
+specify the TARGET_DIR environment variable."
+
+case "$(ls -1d -- "$target_dir/usr/lib/erlang/lib/$library-"* | wc -l)" in
+    0)
+	echo "not found"
+	;;
+    1)
+	echo "$target_dir/usr/lib/erlang/lib/$library-"* \
+	    | sed -e "s,^$target_dir,,"
+	;;
+    *)
+	die "Several versions of $library have been found. Please \
+	remove the unused ones."
+	;;
+esac
diff --git a/package/ejabberd/ejabberd.mk b/package/ejabberd/ejabberd.mk
new file mode 100644
index 0000000..64f93aa
--- /dev/null
+++ b/package/ejabberd/ejabberd.mk
@@ -0,0 +1,86 @@
+################################################################################
+#
+# ejabberd
+#
+################################################################################
+
+EJABBERD_VERSION = 14.05
+EJABBERD_SITE = $(call github,processone,ejabberd,$(EJABBERD_VERSION))
+EJABBERD_LICENSE = GPLv2+
+EJABBERD_LICENSE_FILES = COPYING
+EJABBERD_DEPENDENCIES =	libyaml expat openssl erlang
+
+ifeq ($(BR2_PACKAGE_LIBICONV),y)
+	EJABBERD_DEPENDENCIES += libiconv
+endif
+
+EJABBERD_ERLANG_LIBS := sasl crypto public_key ssl mnesia inets compiler
+
+# Do AC_ERLANG_CHECK_LIB job without erlang.
+define EJABBERD_SET_LIBS_DIR
+	for lib in $(EJABBERD_ERLANG_LIBS); do					\
+	  export								\
+	    erlang_lib_dir_$$lib="`package/ejabberd/check-erlang-lib $$lib`";	\
+	done
+endef
+
+# Set cross-compilation options to the configure called by rebar.
+define EJABBERD_FIX_REBAR_CONFIG_SCRIPT
+	sed -e "s,./configure,./configure \\	\
+	--target=$(GNU_TARGET_NAME) \\		\
+	--host=$(GNU_TARGET_NAME) \\		\
+	--build=$(GNU_HOST_NAME),"		\
+	  -i "$(@D)"/rebar.config.script
+endef
+
+EJABBERD_PRE_CONFIGURE_HOOKS +=			\
+	EJABBERD_SET_LIBS_DIR			\
+	EJABBERD_FIX_REBAR_CONFIG_SCRIPT
+
+# Guess answers for these tests, configure will bail out otherwise
+# saying error: cannot run test program while cross compiling.
+EJABBERD_CONF_ENV =						\
+  ac_cv_erlang_root_dir='$(HOST_DIR)/usr/lib/erlang'		\
+  $(foreach lib, $(EJABBERD_ERLANG_LIBS),			\
+    ac_cv_erlang_lib_dir_$(lib)="$$erlang_lib_dir_$(lib)")
+
+# Set environment variables so the rebar compile command does
+# cross-compile ejabberd dependencies.
+EJABBERD_MAKE_ENV =								\
+  $(TARGET_CONFIGURE_OPTS)							\
+  $(TARGET_CONFIGURE_ARGS)							\
+  LDFLAGS="-L$(HOST_DIR)/usr/$(GNU_TARGET_NAME)/sysroot/usr/lib/erlang/usr/lib"
+
+# Delete HOST_DIR prefix from ERL path in ejabberctl script.
+define EJABBERD_FIX_EJABBERDCTL
+	sed -e "s,ERL=$(HOST_DIR),ERL=,"		\
+	  -e "s,INSTALLUSER=,INSTALLUSER=ejabberd,"	\
+	  -i "$(TARGET_DIR)"/usr/sbin/ejabberdctl
+endef
+
+EJABBERD_POST_INSTALL_TARGET_HOOKS += EJABBERD_FIX_EJABBERDCTL
+
+define EJABBERD_PERMISSIONS
+/etc/ejabberd d 750 0 128 - - - - -
+/etc/ejabberd/ejabberd.yml-new f 640 0 128 - - - - -
+/etc/ejabberd/ejabberd.yml f 640 0 128 - - - - -
+/etc/ejabberd/ejabberdctl.cfg-new f 640 0 128 - - - - -
+/etc/ejabberd/ejabberdctl.cfg f 640 0 128 - - - - -
+/etc/ejabberd/inetrc f 644 0 128 - - - - -
+/usr/sbin/ejabberdctl f 550 0 128 - - - - -
+/usr/lib/ejabberd/priv/bin/captcha.sh f 750 119 0 - - - - -
+/usr/var/lib/ejabberd d 750 119 0 - - - - -
+/usr/var/lock/ejabberdctl d 750 119 0 - - - - -
+/usr/var/log/ejabberd d 750 119 0 - - - - -
+endef
+
+define EJABBERD_USERS
+ejabberd 119 ejabberd 128 * /var/run/ejabberd - - ejabberd daemon
+endef
+
+define EJABBERD_INSTALL_INIT_SYSV
+	$(INSTALL) -D -m 0755 package/ejabberd/S50ejabberd \
+		$(TARGET_DIR)/etc/init.d/S50ejabberd
+endef
+
+$(eval $(autotools-package))
-- 
1.9.1

[Buildroot] [PATCH v3] ejabberd: new package

[Yann E. MORIN]

Johan, All,

Thanks for this respin! :-)

On 2014-07-18 14:33 +0200, Johan Oudinet spake thusly:
> Signed-off-by: Johan Oudinet <johan.oudinet@gmail.com>
[--SNIP--]
> diff --git a/package/ejabberd/Config.in b/package/ejabberd/Config.in
> new file mode 100644
> index 0000000..3a2336d
> --- /dev/null
> +++ b/package/ejabberd/Config.in
> @@ -0,0 +1,13 @@
> +config BR2_PACKAGE_EJABBERD
> +       bool "ejabberd"
> +       select BR2_PACKAGE_OPENSSL
> +       select BR2_PACKAGE_ERLANG

erlang depends on BR2_USE_MMU, so you need to duplicate the dependency
here, too:

    depends on BR2_USE_MMU  # erlang

> +       select BR2_PACKAGE_LIBYAML
> +       select BR2_PACKAGE_LIBICONV if !BR2_ENABLE_LOCALE
> +       select BR2_PACKAGE_EXPAT
> +       help

All the above entries should be indented using a single TAB, not spaces.

> +	 Ejabberd is a Jabber/XMPP instant messaging server, written
> +	 in Erlang/OTP. Among other features, ejabberd is
> +	 cross-platform, fault-tolerant, clusterable and modular.
> +
> +	 http://www.ejabberd.im

Indentation of the help text is OK (one TAB + two spaces.)

> diff --git a/package/ejabberd/S50ejabberd b/package/ejabberd/S50ejabberd
> new file mode 100644
> index 0000000..a156bc2
> --- /dev/null
> +++ b/package/ejabberd/S50ejabberd

Indentatiopn in this script is inconsistent: sometimes, TABs are used,
sometime spaces. Please be consistent. I prefer spaces, but I won't mind
TABs, as long as it is consistent. ;-)

> +#!/bin/sh
> +#
> +# Start/stop ejabberd
> +#
> +
> +case "$1" in
> +    start)
> +	echo "Starting ejabberd..."
> +	ejabberdctl start
> +	;;
> +    stop)
> +	echo -n "Stopping ejabberd... "
> +	ejabberdctl stop > /dev/null
> +	if [ $? -eq 3 ] || ejabberdctl stopped; then
> +	    echo "OK"
> +	else
> +	    echo "failed"
> +	fi
> +	;;
> +    restart|reload)
> +	"$0" stop
> +	"$0" start
> +	;;
> +    *)
> +	echo "Usage: $0 {start|stop|restart}"
> +	exit 1
> +esac
> +
> +exit $?

This last exit is not needed. That's anyway the default behaviour of a
shell script, to exit with the exit-code of the last command executed.

> diff --git a/package/ejabberd/check-erlang-lib b/package/ejabberd/check-erlang-lib
> new file mode 100755
> index 0000000..1a942bb
> --- /dev/null
> +++ b/package/ejabberd/check-erlang-lib
> @@ -0,0 +1,48 @@
> +#!/bin/sh -e
> +# Helper to bypass AC_ERLANG_CHECK_LIB

I guess you should provide some explanations for this script. I'm not an
erlang guy, so it looks strange to me.

Either you provide the explanations in the commit log, or directly as a
comment in this script (I'd prefer the latter.)

[--SNIP--]
> diff --git a/package/ejabberd/ejabberd.mk b/package/ejabberd/ejabberd.mk
> new file mode 100644
> index 0000000..64f93aa
> --- /dev/null
> +++ b/package/ejabberd/ejabberd.mk
> @@ -0,0 +1,86 @@
> +################################################################################
> +#
> +# ejabberd
> +#
> +################################################################################
> +
> +EJABBERD_VERSION = 14.05
> +EJABBERD_SITE = $(call github,processone,ejabberd,$(EJABBERD_VERSION))
> +EJABBERD_LICENSE = GPLv2+
> +EJABBERD_LICENSE_FILES = COPYING
> +EJABBERD_DEPENDENCIES =	libyaml expat openssl erlang
> +
> +ifeq ($(BR2_PACKAGE_LIBICONV),y)
> +	EJABBERD_DEPENDENCIES += libiconv

We normally do not indent the DEPENDENCIES line inside conditionals.

> +endif

Since it also optionally depends on PAM, you should add linux-pam as a
conditional dependency, so we ensure linux-pam, if selected, is built
before ejabberd:

    ifeq ($(BR2_PACKAGE_LINUX_PAM),y)
    EJABBERD_DEPENDENCIES += linux-pam
    endif

> +EJABBERD_ERLANG_LIBS := sasl crypto public_key ssl mnesia inets compiler
> +
> +# Do AC_ERLANG_CHECK_LIB job without erlang.
> +define EJABBERD_SET_LIBS_DIR
> +	for lib in $(EJABBERD_ERLANG_LIBS); do					\
> +	  export								\
> +	    erlang_lib_dir_$$lib="`package/ejabberd/check-erlang-lib $$lib`";	\
> +	done

Unles I'm missing something (which tends to happen quite often these
days, blame the high temperatures we are experiencing), these exports
will get lost right after the for loop, due to how make calls the rules:
it spawns a shell for each line to be executed, so the environment set
on one line is lost on the subsequent lines, even in the same rule.

However, due to our trickery with the hooks, I'd have to verify this
asumption, when applied to hooks.

You might get something with:

    EJABBERD_CONF_ENV = $(foreach lib,$(EJABBERD_ERLANG_LIBS),erlang_lib_dir_$(lib)=$(shell package/ejabberd/check-erlang-lib $(lib)))

Yes, this line is long, and I doubt we'd be able to split it properly
into working conditions... :-/

Might need some tweaking, mond you! ;-)

> +endef
> +
> +# Set cross-compilation options to the configure called by rebar.
> +define EJABBERD_FIX_REBAR_CONFIG_SCRIPT
> +	sed -e "s,./configure,./configure \\	\
> +	--target=$(GNU_TARGET_NAME) \\		\
> +	--host=$(GNU_TARGET_NAME) \\		\
> +	--build=$(GNU_HOST_NAME),"		\
> +	  -i "$(@D)"/rebar.config.script
> +endef
> +
> +EJABBERD_PRE_CONFIGURE_HOOKS +=			\
> +	EJABBERD_SET_LIBS_DIR			\
> +	EJABBERD_FIX_REBAR_CONFIG_SCRIPT
> +
> +# Guess answers for these tests, configure will bail out otherwise
> +# saying error: cannot run test program while cross compiling.
> +EJABBERD_CONF_ENV =						\
> +  ac_cv_erlang_root_dir='$(HOST_DIR)/usr/lib/erlang'		\
> +  $(foreach lib, $(EJABBERD_ERLANG_LIBS),			\
> +    ac_cv_erlang_lib_dir_$(lib)="$$erlang_lib_dir_$(lib)")

Uneeded, with the trick above.

> +# Set environment variables so the rebar compile command does
> +# cross-compile ejabberd dependencies.
> +EJABBERD_MAKE_ENV =								\
> +  $(TARGET_CONFIGURE_OPTS)							\
> +  $(TARGET_CONFIGURE_ARGS)							\
> +  LDFLAGS="-L$(HOST_DIR)/usr/$(GNU_TARGET_NAME)/sysroot/usr/lib/erlang/usr/lib"
> +
> +# Delete HOST_DIR prefix from ERL path in ejabberctl script.
> +define EJABBERD_FIX_EJABBERDCTL
> +	sed -e "s,ERL=$(HOST_DIR),ERL=,"		\
> +	  -e "s,INSTALLUSER=,INSTALLUSER=ejabberd,"	\
> +	  -i "$(TARGET_DIR)"/usr/sbin/ejabberdctl

Use $(SED) ;

    $(SED) 's,ERL=$(HOST_DIR),ERL=,; s,INSTALLUSER=,INSTALLUSER=ejabberd,' \
           $(TARGET_DIR)/usr/sbin/ejabberdctl

> +endef
> +
> +EJABBERD_POST_INSTALL_TARGET_HOOKS += EJABBERD_FIX_EJABBERDCTL
> +
> +define EJABBERD_PERMISSIONS
> +/etc/ejabberd d 750 0 128 - - - - -
> +/etc/ejabberd/ejabberd.yml-new f 640 0 128 - - - - -
> +/etc/ejabberd/ejabberd.yml f 640 0 128 - - - - -
> +/etc/ejabberd/ejabberdctl.cfg-new f 640 0 128 - - - - -
> +/etc/ejabberd/ejabberdctl.cfg f 640 0 128 - - - - -
> +/etc/ejabberd/inetrc f 644 0 128 - - - - -
> +/usr/sbin/ejabberdctl f 550 0 128 - - - - -
> +/usr/lib/ejabberd/priv/bin/captcha.sh f 750 119 0 - - - - -
> +/usr/var/lib/ejabberd d 750 119 0 - - - - -
> +/usr/var/lock/ejabberdctl d 750 119 0 - - - - -
> +/usr/var/log/ejabberd d 750 119 0 - - - - -
> +endef
> +
> +define EJABBERD_USERS
> +ejabberd 119 ejabberd 128 * /var/run/ejabberd - - ejabberd daemon

Do you really need those exact uid and gid? I'd prefer we let the user
infra find free uid/gid, to avoid collisions.

Regards,
Yann E. MORIN.

> +endef
> +
> +define EJABBERD_INSTALL_INIT_SYSV
> +	$(INSTALL) -D -m 0755 package/ejabberd/S50ejabberd \
> +		$(TARGET_DIR)/etc/init.d/S50ejabberd
> +endef
> +
> +$(eval $(autotools-package))
> -- 
> 1.9.1
> 
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH v3] ejabberd: new package

[Johan Oudinet]

Thanks Yann for the comments.
I'm on holidays for the next 2 weeks, but I will take care of them as
soon as I'm back.

In the meantime, I'm interested in how to set file permissions without
knowing which uid/gid ejabberd user has?
Can I use user/group names instead of IDs in EJABBERD_PERMISSIONS syntax?

On Fri, Jul 18, 2014 at 11:35 PM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> Johan, All,
>
> Thanks for this respin! :-)
>
> On 2014-07-18 14:33 +0200, Johan Oudinet spake thusly:
>> Signed-off-by: Johan Oudinet <johan.oudinet@gmail.com>
> [--SNIP--]
>> diff --git a/package/ejabberd/Config.in b/package/ejabberd/Config.in
>> new file mode 100644
>> index 0000000..3a2336d
>> --- /dev/null
>> +++ b/package/ejabberd/Config.in
>> @@ -0,0 +1,13 @@
>> +config BR2_PACKAGE_EJABBERD
>> +       bool "ejabberd"
>> +       select BR2_PACKAGE_OPENSSL
>> +       select BR2_PACKAGE_ERLANG
>
> erlang depends on BR2_USE_MMU, so you need to duplicate the dependency
> here, too:
>
>     depends on BR2_USE_MMU  # erlang
>
>> +       select BR2_PACKAGE_LIBYAML
>> +       select BR2_PACKAGE_LIBICONV if !BR2_ENABLE_LOCALE
>> +       select BR2_PACKAGE_EXPAT
>> +       help
>
> All the above entries should be indented using a single TAB, not spaces.
>
>> +      Ejabberd is a Jabber/XMPP instant messaging server, written
>> +      in Erlang/OTP. Among other features, ejabberd is
>> +      cross-platform, fault-tolerant, clusterable and modular.
>> +
>> +      http://www.ejabberd.im
>
> Indentation of the help text is OK (one TAB + two spaces.)
>
>> diff --git a/package/ejabberd/S50ejabberd b/package/ejabberd/S50ejabberd
>> new file mode 100644
>> index 0000000..a156bc2
>> --- /dev/null
>> +++ b/package/ejabberd/S50ejabberd
>
> Indentatiopn in this script is inconsistent: sometimes, TABs are used,
> sometime spaces. Please be consistent. I prefer spaces, but I won't mind
> TABs, as long as it is consistent. ;-)
>
>> +#!/bin/sh
>> +#
>> +# Start/stop ejabberd
>> +#
>> +
>> +case "$1" in
>> +    start)
>> +     echo "Starting ejabberd..."
>> +     ejabberdctl start
>> +     ;;
>> +    stop)
>> +     echo -n "Stopping ejabberd... "
>> +     ejabberdctl stop > /dev/null
>> +     if [ $? -eq 3 ] || ejabberdctl stopped; then
>> +         echo "OK"
>> +     else
>> +         echo "failed"
>> +     fi
>> +     ;;
>> +    restart|reload)
>> +     "$0" stop
>> +     "$0" start
>> +     ;;
>> +    *)
>> +     echo "Usage: $0 {start|stop|restart}"
>> +     exit 1
>> +esac
>> +
>> +exit $?
>
> This last exit is not needed. That's anyway the default behaviour of a
> shell script, to exit with the exit-code of the last command executed.
>
>> diff --git a/package/ejabberd/check-erlang-lib b/package/ejabberd/check-erlang-lib
>> new file mode 100755
>> index 0000000..1a942bb
>> --- /dev/null
>> +++ b/package/ejabberd/check-erlang-lib
>> @@ -0,0 +1,48 @@
>> +#!/bin/sh -e
>> +# Helper to bypass AC_ERLANG_CHECK_LIB
>
> I guess you should provide some explanations for this script. I'm not an
> erlang guy, so it looks strange to me.
>
> Either you provide the explanations in the commit log, or directly as a
> comment in this script (I'd prefer the latter.)
>
> [--SNIP--]
>> diff --git a/package/ejabberd/ejabberd.mk b/package/ejabberd/ejabberd.mk
>> new file mode 100644
>> index 0000000..64f93aa
>> --- /dev/null
>> +++ b/package/ejabberd/ejabberd.mk
>> @@ -0,0 +1,86 @@
>> +################################################################################
>> +#
>> +# ejabberd
>> +#
>> +################################################################################
>> +
>> +EJABBERD_VERSION = 14.05
>> +EJABBERD_SITE = $(call github,processone,ejabberd,$(EJABBERD_VERSION))
>> +EJABBERD_LICENSE = GPLv2+
>> +EJABBERD_LICENSE_FILES = COPYING
>> +EJABBERD_DEPENDENCIES =      libyaml expat openssl erlang
>> +
>> +ifeq ($(BR2_PACKAGE_LIBICONV),y)
>> +     EJABBERD_DEPENDENCIES += libiconv
>
> We normally do not indent the DEPENDENCIES line inside conditionals.
>
>> +endif
>
> Since it also optionally depends on PAM, you should add linux-pam as a
> conditional dependency, so we ensure linux-pam, if selected, is built
> before ejabberd:
>
>     ifeq ($(BR2_PACKAGE_LINUX_PAM),y)
>     EJABBERD_DEPENDENCIES += linux-pam
>     endif
>
>> +EJABBERD_ERLANG_LIBS := sasl crypto public_key ssl mnesia inets compiler
>> +
>> +# Do AC_ERLANG_CHECK_LIB job without erlang.
>> +define EJABBERD_SET_LIBS_DIR
>> +     for lib in $(EJABBERD_ERLANG_LIBS); do                                  \
>> +       export                                                                \
>> +         erlang_lib_dir_$$lib="`package/ejabberd/check-erlang-lib $$lib`";   \
>> +     done
>
> Unles I'm missing something (which tends to happen quite often these
> days, blame the high temperatures we are experiencing), these exports
> will get lost right after the for loop, due to how make calls the rules:
> it spawns a shell for each line to be executed, so the environment set
> on one line is lost on the subsequent lines, even in the same rule.
>
> However, due to our trickery with the hooks, I'd have to verify this
> asumption, when applied to hooks.
>
> You might get something with:
>
>     EJABBERD_CONF_ENV = $(foreach lib,$(EJABBERD_ERLANG_LIBS),erlang_lib_dir_$(lib)=$(shell package/ejabberd/check-erlang-lib $(lib)))
>
> Yes, this line is long, and I doubt we'd be able to split it properly
> into working conditions... :-/
>
> Might need some tweaking, mond you! ;-)
>
>> +endef
>> +
>> +# Set cross-compilation options to the configure called by rebar.
>> +define EJABBERD_FIX_REBAR_CONFIG_SCRIPT
>> +     sed -e "s,./configure,./configure \\    \
>> +     --target=$(GNU_TARGET_NAME) \\          \
>> +     --host=$(GNU_TARGET_NAME) \\            \
>> +     --build=$(GNU_HOST_NAME),"              \
>> +       -i "$(@D)"/rebar.config.script
>> +endef
>> +
>> +EJABBERD_PRE_CONFIGURE_HOOKS +=                      \
>> +     EJABBERD_SET_LIBS_DIR                   \
>> +     EJABBERD_FIX_REBAR_CONFIG_SCRIPT
>> +
>> +# Guess answers for these tests, configure will bail out otherwise
>> +# saying error: cannot run test program while cross compiling.
>> +EJABBERD_CONF_ENV =                                          \
>> +  ac_cv_erlang_root_dir='$(HOST_DIR)/usr/lib/erlang'         \
>> +  $(foreach lib, $(EJABBERD_ERLANG_LIBS),                    \
>> +    ac_cv_erlang_lib_dir_$(lib)="$$erlang_lib_dir_$(lib)")
>
> Uneeded, with the trick above.
>
>> +# Set environment variables so the rebar compile command does
>> +# cross-compile ejabberd dependencies.
>> +EJABBERD_MAKE_ENV =                                                          \
>> +  $(TARGET_CONFIGURE_OPTS)                                                   \
>> +  $(TARGET_CONFIGURE_ARGS)                                                   \
>> +  LDFLAGS="-L$(HOST_DIR)/usr/$(GNU_TARGET_NAME)/sysroot/usr/lib/erlang/usr/lib"
>> +
>> +# Delete HOST_DIR prefix from ERL path in ejabberctl script.
>> +define EJABBERD_FIX_EJABBERDCTL
>> +     sed -e "s,ERL=$(HOST_DIR),ERL=,"                \
>> +       -e "s,INSTALLUSER=,INSTALLUSER=ejabberd,"     \
>> +       -i "$(TARGET_DIR)"/usr/sbin/ejabberdctl
>
> Use $(SED) ;
>
>     $(SED) 's,ERL=$(HOST_DIR),ERL=,; s,INSTALLUSER=,INSTALLUSER=ejabberd,' \
>            $(TARGET_DIR)/usr/sbin/ejabberdctl
>
>> +endef
>> +
>> +EJABBERD_POST_INSTALL_TARGET_HOOKS += EJABBERD_FIX_EJABBERDCTL
>> +
>> +define EJABBERD_PERMISSIONS
>> +/etc/ejabberd d 750 0 128 - - - - -
>> +/etc/ejabberd/ejabberd.yml-new f 640 0 128 - - - - -
>> +/etc/ejabberd/ejabberd.yml f 640 0 128 - - - - -
>> +/etc/ejabberd/ejabberdctl.cfg-new f 640 0 128 - - - - -
>> +/etc/ejabberd/ejabberdctl.cfg f 640 0 128 - - - - -
>> +/etc/ejabberd/inetrc f 644 0 128 - - - - -
>> +/usr/sbin/ejabberdctl f 550 0 128 - - - - -
>> +/usr/lib/ejabberd/priv/bin/captcha.sh f 750 119 0 - - - - -
>> +/usr/var/lib/ejabberd d 750 119 0 - - - - -
>> +/usr/var/lock/ejabberdctl d 750 119 0 - - - - -
>> +/usr/var/log/ejabberd d 750 119 0 - - - - -
>> +endef
>> +
>> +define EJABBERD_USERS
>> +ejabberd 119 ejabberd 128 * /var/run/ejabberd - - ejabberd daemon
>
> Do you really need those exact uid and gid? I'd prefer we let the user
> infra find free uid/gid, to avoid collisions.
>
> Regards,
> Yann E. MORIN.
>
>> +endef
>> +
>> +define EJABBERD_INSTALL_INIT_SYSV
>> +     $(INSTALL) -D -m 0755 package/ejabberd/S50ejabberd \
>> +             $(TARGET_DIR)/etc/init.d/S50ejabberd
>> +endef
>> +
>> +$(eval $(autotools-package))
>> --
>> 1.9.1
>>
>> _______________________________________________
>> buildroot mailing list
>> buildroot at busybox.net
>> http://lists.busybox.net/mailman/listinfo/buildroot
>
> --
> .-----------------.--------------------.------------------.--------------------.
> |  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
> | +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
> | +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
> | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
> '------------------------------^-------^------------------^--------------------'



-- 
Johan
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

[Buildroot] [PATCH v3] ejabberd: new package

[Yann E. MORIN]

Johan, All,

On 2014-07-19 01:58 +0200, Johan Oudinet spake thusly:
> Thanks Yann for the comments.
> I'm on holidays for the next 2 weeks, but I will take care of them as
> soon as I'm back.

Enjoy your holidays! :-)

> In the meantime, I'm interested in how to set file permissions without
> knowing which uid/gid ejabberd user has?
> Can I use user/group names instead of IDs in EJABBERD_PERMISSIONS syntax?

Just -1 as uid or gid. See:
    http://buildroot.net/downloads/manual/manual.html#makeuser-syntax

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH v3] ejabberd: new package

[Thomas Petazzoni]

Dear Johan Oudinet,

Thanks for your contribution!

I'll only make comments than Yann hasn't made yet.

On Fri, 18 Jul 2014 14:33:57 +0200, Johan Oudinet wrote:

> diff --git a/package/ejabberd/ejabberd.mk b/package/ejabberd/ejabberd.mk
> new file mode 100644
> index 0000000..64f93aa
> --- /dev/null
> +++ b/package/ejabberd/ejabberd.mk
> @@ -0,0 +1,86 @@
> +################################################################################
> +#
> +# ejabberd
> +#
> +################################################################################
> +
> +EJABBERD_VERSION = 14.05
> +EJABBERD_SITE = $(call github,processone,ejabberd,$(EJABBERD_VERSION))
> +EJABBERD_LICENSE = GPLv2+
> +EJABBERD_LICENSE_FILES = COPYING
> +EJABBERD_DEPENDENCIES =	libyaml expat openssl erlang

Unneeded tab after the = sign, just put one space.

> +
> +ifeq ($(BR2_PACKAGE_LIBICONV),y)
> +	EJABBERD_DEPENDENCIES += libiconv
> +endif
> +
> +EJABBERD_ERLANG_LIBS := sasl crypto public_key ssl mnesia inets compiler

Replace := by =.

> +
> +# Do AC_ERLANG_CHECK_LIB job without erlang.
> +define EJABBERD_SET_LIBS_DIR
> +	for lib in $(EJABBERD_ERLANG_LIBS); do					\
> +	  export								\
> +	    erlang_lib_dir_$$lib="`package/ejabberd/check-erlang-lib $$lib`";	\
> +	done
> +endef

Do we really need this script? What does it do exactly? Since we
control the erlang installation in Buildroot, can't we simply hardcode
the values here?

> +
> +# Set cross-compilation options to the configure called by rebar.
> +define EJABBERD_FIX_REBAR_CONFIG_SCRIPT
> +	sed -e "s,./configure,./configure \\	\
> +	--target=$(GNU_TARGET_NAME) \\		\
> +	--host=$(GNU_TARGET_NAME) \\		\
> +	--build=$(GNU_HOST_NAME),"		\
> +	  -i "$(@D)"/rebar.config.script
> +endef

I don't really follow what's happening here. Since we're using the
autotools-package infrastructure, aren't we already calling
the ./configure script with the appropriate options?

> +
> +EJABBERD_PRE_CONFIGURE_HOOKS +=			\
> +	EJABBERD_SET_LIBS_DIR			\
> +	EJABBERD_FIX_REBAR_CONFIG_SCRIPT
> +
> +# Guess answers for these tests, configure will bail out otherwise
> +# saying error: cannot run test program while cross compiling.
> +EJABBERD_CONF_ENV =						\
> +  ac_cv_erlang_root_dir='$(HOST_DIR)/usr/lib/erlang'		\
> +  $(foreach lib, $(EJABBERD_ERLANG_LIBS),			\
> +    ac_cv_erlang_lib_dir_$(lib)="$$erlang_lib_dir_$(lib)")
> +
> +# Set environment variables so the rebar compile command does
> +# cross-compile ejabberd dependencies.
> +EJABBERD_MAKE_ENV =								\
> +  $(TARGET_CONFIGURE_OPTS)							\
> +  $(TARGET_CONFIGURE_ARGS)							\
> +  LDFLAGS="-L$(HOST_DIR)/usr/$(GNU_TARGET_NAME)/sysroot/usr/lib/erlang/usr/lib"
> +
> +# Delete HOST_DIR prefix from ERL path in ejabberctl script.
> +define EJABBERD_FIX_EJABBERDCTL
> +	sed -e "s,ERL=$(HOST_DIR),ERL=,"		\
> +	  -e "s,INSTALLUSER=,INSTALLUSER=ejabberd,"	\
> +	  -i "$(TARGET_DIR)"/usr/sbin/ejabberdctl
> +endef
> +
> +EJABBERD_POST_INSTALL_TARGET_HOOKS += EJABBERD_FIX_EJABBERDCTL
> +
> +define EJABBERD_PERMISSIONS
> +/etc/ejabberd d 750 0 128 - - - - -
> +/etc/ejabberd/ejabberd.yml-new f 640 0 128 - - - - -
> +/etc/ejabberd/ejabberd.yml f 640 0 128 - - - - -
> +/etc/ejabberd/ejabberdctl.cfg-new f 640 0 128 - - - - -
> +/etc/ejabberd/ejabberdctl.cfg f 640 0 128 - - - - -
> +/etc/ejabberd/inetrc f 644 0 128 - - - - -
> +/usr/sbin/ejabberdctl f 550 0 128 - - - - -
> +/usr/lib/ejabberd/priv/bin/captcha.sh f 750 119 0 - - - - -
> +/usr/var/lib/ejabberd d 750 119 0 - - - - -
> +/usr/var/lock/ejabberdctl d 750 119 0 - - - - -
> +/usr/var/log/ejabberd d 750 119 0 - - - - -
> +endef

<pkg>_PERMISSIONS should only be used for files that need special
permissions, the other files should be left with their default
permissions, owned by root (which is done automatically by Buildroot).

Also, /usr/var/lib, /usr/val/lock and /usr/var/log look incorrect.

Thanks,

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

[Buildroot] [PATCH v3] ejabberd: new package

[Johan Oudinet]

Hi Thomas, Yann, and all,

Thanks for your comments. I took care of all of them but two:
check-erlang-lib script and <pkg>_PERMISSIONS.
See below for my comments/questions with regards to these two issues.

On Sun, Jul 20, 2014 at 11:33 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> On Fri, 18 Jul 2014 14:33:57 +0200, Johan Oudinet wrote:
>
>> +
>> +# Do AC_ERLANG_CHECK_LIB job without erlang.
>> +define EJABBERD_SET_LIBS_DIR
>> +     for lib in $(EJABBERD_ERLANG_LIBS); do                                  \
>> +       export                                                                \
>> +         erlang_lib_dir_$$lib="`package/ejabberd/check-erlang-lib $$lib`";   \
>> +     done
>> +endef
>
> Do we really need this script? What does it do exactly? Since we
> control the erlang installation in Buildroot, can't we simply hardcode
> the values here?

Unfortunately, we can't hardcode these values because ejabberd's
makefile fetches its dependencies from master branches of git
repositories. So, we don't know which versions have be fetched.
In my opinion, this is a bad idea as it forces developers of such
libraries to make sure their master branch is compatible with every
ejabberd releases that depends on it.
This is a known issue : https://github.com/processone/ejabberd/issues/233
In the meantime, I think we need this script to know which version has
been downloaded by ejabberd's Makefile.

>
>> +
>> +# Set cross-compilation options to the configure called by rebar.
>> +define EJABBERD_FIX_REBAR_CONFIG_SCRIPT
>> +     sed -e "s,./configure,./configure \\    \
>> +     --target=$(GNU_TARGET_NAME) \\          \
>> +     --host=$(GNU_TARGET_NAME) \\            \
>> +     --build=$(GNU_HOST_NAME),"              \
>> +       -i "$(@D)"/rebar.config.script
>> +endef
>
> I don't really follow what's happening here. Since we're using the
> autotools-package infrastructure, aren't we already calling
> the ./configure script with the appropriate options?

The problem comes from ejabberd's makefile. It configures its
dependencies while we run make, instead of doing it when we run
./configure.
So, what happens is the following:
- ./configure -> configure ejabberd (this one is called with the
appropriate options thanks to buildroot)
- make -> download ejabberd's dependencies in sub-folders, run
./configure inside each of these sub-folders, then make.
Thus, the configure script of each ejabberd's dependency is not called
with the appropriate options. Again, the problem is due to ejabberd
build system that mixes build and configure steps.

>> +define EJABBERD_PERMISSIONS
>> +/etc/ejabberd d 750 0 128 - - - - -
>> +/etc/ejabberd/ejabberd.yml-new f 640 0 128 - - - - -
>> +/etc/ejabberd/ejabberd.yml f 640 0 128 - - - - -
>> +/etc/ejabberd/ejabberdctl.cfg-new f 640 0 128 - - - - -
>> +/etc/ejabberd/ejabberdctl.cfg f 640 0 128 - - - - -
>> +/etc/ejabberd/inetrc f 644 0 128 - - - - -
>> +/usr/sbin/ejabberdctl f 550 0 128 - - - - -
>> +/usr/lib/ejabberd/priv/bin/captcha.sh f 750 119 0 - - - - -
>> +/usr/var/lib/ejabberd d 750 119 0 - - - - -
>> +/usr/var/lock/ejabberdctl d 750 119 0 - - - - -
>> +/usr/var/log/ejabberd d 750 119 0 - - - - -
>> +endef
>
> <pkg>_PERMISSIONS should only be used for files that need special
> permissions, the other files should be left with their default
> permissions, owned by root (which is done automatically by Buildroot).

ejabberd is run as the ejabberd user. Thus this user needs to own (or
be in the group of) several files and directories.

>
> Also, /usr/var/lib, /usr/val/lock and /usr/var/log look incorrect.

I've copied the permissions set by the install rule in ejabberd's
makefile. Honestly, I don't know why ejabberd needs such permissions,
but if I let root to be the owner of these files, it does not work.
Do you know a better way of setting ownership? I don't like to have to
set a specific UID and GID for the ejabberd user simply because the
syntax of <pkg>_PERMISSIONS requires an ID instead of a name.

Thanks.

Best,
-- 
Johan

[Buildroot] [PATCH v3] ejabberd: new package

[Yann E. MORIN]

Johan, All,

On 2014-08-06 12:30 +0200, Johan Oudinet spake thusly:
> On Sun, Jul 20, 2014 at 11:33 AM, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
> > On Fri, 18 Jul 2014 14:33:57 +0200, Johan Oudinet wrote:
> >
> >> +
> >> +# Do AC_ERLANG_CHECK_LIB job without erlang.
> >> +define EJABBERD_SET_LIBS_DIR
> >> +     for lib in $(EJABBERD_ERLANG_LIBS); do                                  \
> >> +       export                                                                \
> >> +         erlang_lib_dir_$$lib="`package/ejabberd/check-erlang-lib $$lib`";   \
> >> +     done
> >> +endef
> >
> > Do we really need this script? What does it do exactly? Since we
> > control the erlang installation in Buildroot, can't we simply hardcode
> > the values here?
> 
> Unfortunately, we can't hardcode these values because ejabberd's
> makefile fetches its dependencies from master branches of git
> repositories. So, we don't know which versions have be fetched.
> In my opinion, this is a bad idea as it forces developers of such
> libraries to make sure their master branch is compatible with every
> ejabberd releases that depends on it.
> This is a known issue : https://github.com/processone/ejabberd/issues/233
> In the meantime, I think we need this script to know which version has
> been downloaded by ejabberd's Makefile.
> 
> >
> >> +
> >> +# Set cross-compilation options to the configure called by rebar.
> >> +define EJABBERD_FIX_REBAR_CONFIG_SCRIPT
> >> +     sed -e "s,./configure,./configure \\    \
> >> +     --target=$(GNU_TARGET_NAME) \\          \
> >> +     --host=$(GNU_TARGET_NAME) \\            \
> >> +     --build=$(GNU_HOST_NAME),"              \
> >> +       -i "$(@D)"/rebar.config.script
> >> +endef
> >
> > I don't really follow what's happening here. Since we're using the
> > autotools-package infrastructure, aren't we already calling
> > the ./configure script with the appropriate options?
> 
> The problem comes from ejabberd's makefile. It configures its
> dependencies while we run make, instead of doing it when we run
> ./configure.
> So, what happens is the following:
> - ./configure -> configure ejabberd (this one is called with the
> appropriate options thanks to buildroot)
> - make -> download ejabberd's dependencies in sub-folders,

Argh... :-(

We do not want that to happen. All download operations should be caried
on during the download phase, aka PKG-source. It should basically be
possible to run "make source" then disconnect from the network, and
then run "make" to build.

> run
> ./configure inside each of these sub-folders, then make.
> Thus, the configure script of each ejabberd's dependency is not called
> with the appropriate options. Again, the problem is due to ejabberd
> build system that mixes build and configure steps.

Grr... Stupid build system... :-(

I'll see what we can do for that.

> >> +define EJABBERD_PERMISSIONS
> >> +/etc/ejabberd d 750 0 128 - - - - -
> >> +/etc/ejabberd/ejabberd.yml-new f 640 0 128 - - - - -
> >> +/etc/ejabberd/ejabberd.yml f 640 0 128 - - - - -
> >> +/etc/ejabberd/ejabberdctl.cfg-new f 640 0 128 - - - - -
> >> +/etc/ejabberd/ejabberdctl.cfg f 640 0 128 - - - - -
> >> +/etc/ejabberd/inetrc f 644 0 128 - - - - -
> >> +/usr/sbin/ejabberdctl f 550 0 128 - - - - -
> >> +/usr/lib/ejabberd/priv/bin/captcha.sh f 750 119 0 - - - - -
> >> +/usr/var/lib/ejabberd d 750 119 0 - - - - -
> >> +/usr/var/lock/ejabberdctl d 750 119 0 - - - - -
> >> +/usr/var/log/ejabberd d 750 119 0 - - - - -
> >> +endef
> >
> > <pkg>_PERMISSIONS should only be used for files that need special
> > permissions, the other files should be left with their default
> > permissions, owned by root (which is done automatically by Buildroot).
> 
> ejabberd is run as the ejabberd user. Thus this user needs to own (or
> be in the group of) several files and directories.
> 
> >
> > Also, /usr/var/lib, /usr/val/lock and /usr/var/log look incorrect.
> 
> I've copied the permissions set by the install rule in ejabberd's
> makefile. Honestly, I don't know why ejabberd needs such permissions,
> but if I let root to be the owner of these files, it does not work.
> Do you know a better way of setting ownership? I don't like to have to
> set a specific UID and GID for the ejabberd user simply because the
> syntax of <pkg>_PERMISSIONS requires an ID instead of a name.

Agreed, I would not want ejabberd to run as root either. I'll see what
we can do for those premissions...

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH v3] ejabberd: new package

[Yann E. MORIN]

Johan, All,

On 2014-07-18 14:33 +0200, Johan Oudinet spake thusly:
> Signed-off-by: Johan Oudinet <johan.oudinet@gmail.com>
> ---
> Changes v2 -> v3:
>   - Add system V init script.
> Changes v1 -> v2:
>   - Run ejabberd as ejabberd user instead of root.

I tried building ejabberd in a minmal config, with:

    BR2_x86_i686=y
    BR2_TOOLCHAIN_EXTERNAL=y
    BR2_INIT_NONE=y
    # BR2_PACKAGE_BUSYBOX is not set
    BR2_PACKAGE_EJABBERD=y
    # BR2_TARGET_ROOTFS_TAR is not set

And it fails at build time, with a lengthy error message, that I do not
completely grasp:

    /home/ymorin/dev/buildroot/O/host/usr/lib/erlang/bin/escript rebar
get-deps && :> deps/.got
    ==> rel (get-deps)
    Uncaught error in rebar_core: {'EXIT',
                                   {badarg,
                                    [{re,replace,
                                      [[40,41,32,123,32,32,108,111,99,97,108,32,
                                        82,69,84,61,34,36,123,63,125,34,59,10,32,
        [--SNIP a lot of numbers--]
                                        115,116,111,114,121,32,45,97,59,10,32,112,
                                        114,111,109,112,116,95,102,105,114,115,
                                        116,61,48,10,125],
                                       [92,36,40,"doPrompt",40,92,115,124,36,41,
                                        124,123,"doPrompt",125,41],
                                       [[],"\\2"],
                                       [global,{return,list}]],
                                      [{file,"re.erl"},{line,355}]},
                                     {rebar_port_compiler,merge_each_var,2,
                                      [{file,"src/rebar_port_compiler.erl"},
                                       {line,380}]},
                                     {rebar_port_compiler,setup_env,2,
                                      [{file,"src/rebar_port_compiler.erl"},
                                       {line,167}]},
                                     {rebar_core,'-setup_envs/2-fun-0-',2,
                                      [{file,"src/rebar_core.erl"},{line,436}]},
                                     {lists,foldl,3,
                                      [{file,"lists.erl"},{line,1261}]},
                                     {rebar_core,process_dir1,6,
                                      [{file,"src/rebar_core.erl"},{line,190}]},
                                     {rebar_core,process_commands,2,
                                      [{file,"src/rebar_core.erl"},{line,61}]},
                                     {rebar,main,1,
                                      [{file,"src/rebar.erl"},{line,58}]}]}}
    make[2]: *** [deps/.got] Error 1

Regards,
Yann E. MORIN.

> ---
>  package/Config.in                 |  1 +
>  package/ejabberd/Config.in        | 13 ++++++
>  package/ejabberd/S50ejabberd      | 29 +++++++++++++
>  package/ejabberd/check-erlang-lib | 48 ++++++++++++++++++++++
>  package/ejabberd/ejabberd.mk      | 86 +++++++++++++++++++++++++++++++++++++++
>  5 files changed, 177 insertions(+)
>  create mode 100644 package/ejabberd/Config.in
>  create mode 100644 package/ejabberd/S50ejabberd
>  create mode 100755 package/ejabberd/check-erlang-lib
>  create mode 100644 package/ejabberd/ejabberd.mk
> 
> diff --git a/package/Config.in b/package/Config.in
> index 22ddea8..eb0aaaa 100644
> --- a/package/Config.in
> +++ b/package/Config.in
> @@ -943,6 +943,7 @@ endif
>  	source "package/dnsmasq/Config.in"
>  	source "package/dropbear/Config.in"
>  	source "package/ebtables/Config.in"
> +	source "package/ejabberd/Config.in"
>  	source "package/ethtool/Config.in"
>  	source "package/faifa/Config.in"
>  	source "package/fmc/Config.in"
> diff --git a/package/ejabberd/Config.in b/package/ejabberd/Config.in
> new file mode 100644
> index 0000000..3a2336d
> --- /dev/null
> +++ b/package/ejabberd/Config.in
> @@ -0,0 +1,13 @@
> +config BR2_PACKAGE_EJABBERD
> +       bool "ejabberd"
> +       select BR2_PACKAGE_OPENSSL
> +       select BR2_PACKAGE_ERLANG
> +       select BR2_PACKAGE_LIBYAML
> +       select BR2_PACKAGE_LIBICONV if !BR2_ENABLE_LOCALE
> +       select BR2_PACKAGE_EXPAT
> +       help
> +	 Ejabberd is a Jabber/XMPP instant messaging server, written
> +	 in Erlang/OTP. Among other features, ejabberd is
> +	 cross-platform, fault-tolerant, clusterable and modular.
> +
> +	 http://www.ejabberd.im
> diff --git a/package/ejabberd/S50ejabberd b/package/ejabberd/S50ejabberd
> new file mode 100644
> index 0000000..a156bc2
> --- /dev/null
> +++ b/package/ejabberd/S50ejabberd
> @@ -0,0 +1,29 @@
> +#!/bin/sh
> +#
> +# Start/stop ejabberd
> +#
> +
> +case "$1" in
> +    start)
> +	echo "Starting ejabberd..."
> +	ejabberdctl start
> +	;;
> +    stop)
> +	echo -n "Stopping ejabberd... "
> +	ejabberdctl stop > /dev/null
> +	if [ $? -eq 3 ] || ejabberdctl stopped; then
> +	    echo "OK"
> +	else
> +	    echo "failed"
> +	fi
> +	;;
> +    restart|reload)
> +	"$0" stop
> +	"$0" start
> +	;;
> +    *)
> +	echo "Usage: $0 {start|stop|restart}"
> +	exit 1
> +esac
> +
> +exit $?
> diff --git a/package/ejabberd/check-erlang-lib b/package/ejabberd/check-erlang-lib
> new file mode 100755
> index 0000000..1a942bb
> --- /dev/null
> +++ b/package/ejabberd/check-erlang-lib
> @@ -0,0 +1,48 @@
> +#!/bin/sh -e
> +# Helper to bypass AC_ERLANG_CHECK_LIB
> +
> +usage() {
> +    cat <<EOF
> +Usage:
> +	$0 library
> +Look for Erlang's library in TARGET_DIR/usr/lib/erlang/lib.
> +
> +If the library is found, it returns the path to the latest version,
> +relative to TARGET_DIR. Otherwise, it returns "not found".
> +
> +If there are several versions, it returns an error because it does not
> +know which one Erlang uses.
> +
> +EOF
> +}
> +
> +die () {
> +    echo "$@" >&2
> +    exit 1
> +}
> +
> +if [ $# -ne 1 ]; then
> +    usage
> +    exit 0
> +else
> +    library="$1"
> +fi
> +
> +target_dir="${TARGET_DIR:-../../output/target}"
> +
> +[ -d "$target_dir" ] || die "TARGET_DIR is not a directory. Please \
> +specify the TARGET_DIR environment variable."
> +
> +case "$(ls -1d -- "$target_dir/usr/lib/erlang/lib/$library-"* | wc -l)" in
> +    0)
> +	echo "not found"
> +	;;
> +    1)
> +	echo "$target_dir/usr/lib/erlang/lib/$library-"* \
> +	    | sed -e "s,^$target_dir,,"
> +	;;
> +    *)
> +	die "Several versions of $library have been found. Please \
> +	remove the unused ones."
> +	;;
> +esac
> diff --git a/package/ejabberd/ejabberd.mk b/package/ejabberd/ejabberd.mk
> new file mode 100644
> index 0000000..64f93aa
> --- /dev/null
> +++ b/package/ejabberd/ejabberd.mk
> @@ -0,0 +1,86 @@
> +################################################################################
> +#
> +# ejabberd
> +#
> +################################################################################
> +
> +EJABBERD_VERSION = 14.05
> +EJABBERD_SITE = $(call github,processone,ejabberd,$(EJABBERD_VERSION))
> +EJABBERD_LICENSE = GPLv2+
> +EJABBERD_LICENSE_FILES = COPYING
> +EJABBERD_DEPENDENCIES =	libyaml expat openssl erlang
> +
> +ifeq ($(BR2_PACKAGE_LIBICONV),y)
> +	EJABBERD_DEPENDENCIES += libiconv
> +endif
> +
> +EJABBERD_ERLANG_LIBS := sasl crypto public_key ssl mnesia inets compiler
> +
> +# Do AC_ERLANG_CHECK_LIB job without erlang.
> +define EJABBERD_SET_LIBS_DIR
> +	for lib in $(EJABBERD_ERLANG_LIBS); do					\
> +	  export								\
> +	    erlang_lib_dir_$$lib="`package/ejabberd/check-erlang-lib $$lib`";	\
> +	done
> +endef
> +
> +# Set cross-compilation options to the configure called by rebar.
> +define EJABBERD_FIX_REBAR_CONFIG_SCRIPT
> +	sed -e "s,./configure,./configure \\	\
> +	--target=$(GNU_TARGET_NAME) \\		\
> +	--host=$(GNU_TARGET_NAME) \\		\
> +	--build=$(GNU_HOST_NAME),"		\
> +	  -i "$(@D)"/rebar.config.script
> +endef
> +
> +EJABBERD_PRE_CONFIGURE_HOOKS +=			\
> +	EJABBERD_SET_LIBS_DIR			\
> +	EJABBERD_FIX_REBAR_CONFIG_SCRIPT
> +
> +# Guess answers for these tests, configure will bail out otherwise
> +# saying error: cannot run test program while cross compiling.
> +EJABBERD_CONF_ENV =						\
> +  ac_cv_erlang_root_dir='$(HOST_DIR)/usr/lib/erlang'		\
> +  $(foreach lib, $(EJABBERD_ERLANG_LIBS),			\
> +    ac_cv_erlang_lib_dir_$(lib)="$$erlang_lib_dir_$(lib)")
> +
> +# Set environment variables so the rebar compile command does
> +# cross-compile ejabberd dependencies.
> +EJABBERD_MAKE_ENV =								\
> +  $(TARGET_CONFIGURE_OPTS)							\
> +  $(TARGET_CONFIGURE_ARGS)							\
> +  LDFLAGS="-L$(HOST_DIR)/usr/$(GNU_TARGET_NAME)/sysroot/usr/lib/erlang/usr/lib"
> +
> +# Delete HOST_DIR prefix from ERL path in ejabberctl script.
> +define EJABBERD_FIX_EJABBERDCTL
> +	sed -e "s,ERL=$(HOST_DIR),ERL=,"		\
> +	  -e "s,INSTALLUSER=,INSTALLUSER=ejabberd,"	\
> +	  -i "$(TARGET_DIR)"/usr/sbin/ejabberdctl
> +endef
> +
> +EJABBERD_POST_INSTALL_TARGET_HOOKS += EJABBERD_FIX_EJABBERDCTL
> +
> +define EJABBERD_PERMISSIONS
> +/etc/ejabberd d 750 0 128 - - - - -
> +/etc/ejabberd/ejabberd.yml-new f 640 0 128 - - - - -
> +/etc/ejabberd/ejabberd.yml f 640 0 128 - - - - -
> +/etc/ejabberd/ejabberdctl.cfg-new f 640 0 128 - - - - -
> +/etc/ejabberd/ejabberdctl.cfg f 640 0 128 - - - - -
> +/etc/ejabberd/inetrc f 644 0 128 - - - - -
> +/usr/sbin/ejabberdctl f 550 0 128 - - - - -
> +/usr/lib/ejabberd/priv/bin/captcha.sh f 750 119 0 - - - - -
> +/usr/var/lib/ejabberd d 750 119 0 - - - - -
> +/usr/var/lock/ejabberdctl d 750 119 0 - - - - -
> +/usr/var/log/ejabberd d 750 119 0 - - - - -
> +endef
> +
> +define EJABBERD_USERS
> +ejabberd 119 ejabberd 128 * /var/run/ejabberd - - ejabberd daemon
> +endef
> +
> +define EJABBERD_INSTALL_INIT_SYSV
> +	$(INSTALL) -D -m 0755 package/ejabberd/S50ejabberd \
> +		$(TARGET_DIR)/etc/init.d/S50ejabberd
> +endef
> +
> +$(eval $(autotools-package))
> -- 
> 1.9.1
> 
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH v3] ejabberd: new package

[Johan Oudinet]

Yann, all,

On Wed, Aug 6, 2014 at 10:23 PM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> I tried building ejabberd in a minmal config, with:
>
>     BR2_x86_i686=y
>     BR2_TOOLCHAIN_EXTERNAL=y
>     BR2_INIT_NONE=y
>     # BR2_PACKAGE_BUSYBOX is not set
>     BR2_PACKAGE_EJABBERD=y
>     # BR2_TARGET_ROOTFS_TAR is not set
>
> And it fails at build time, with a lengthy error message, that I do not
> completely grasp:
>
>     /home/ymorin/dev/buildroot/O/host/usr/lib/erlang/bin/escript rebar
> get-deps && :> deps/.got
>     ==> rel (get-deps)
>     Uncaught error in rebar_core: {'EXIT',
>                                    {badarg,

Very strange. It looks like the rebar script didn't accept the
get-deps argument.
Could you try with the same defconfig as mine to see if the problem
comes from there.
$ cat defconfig
BR2_arm=y
BR2_arm1176jzf_s=y
BR2_KERNEL_HEADERS_VERSION=y
BR2_DEFAULT_KERNEL_VERSION="3.12.20"
BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_12=y
BR2_TOOLCHAIN_BUILDROOT_LARGEFILE=y
BR2_TOOLCHAIN_BUILDROOT_LOCALE=y
BR2_TOOLCHAIN_BUILDROOT_CXX=y
BR2_TARGET_GENERIC_GETTY_PORT="ttyAMA0"
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_CUSTOM_GIT=y
BR2_LINUX_KERNEL_CUSTOM_REPO_URL="git://github.com/raspberrypi/linux.git"
BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION="a25152fdfbfd3b4330da16fc3aeb6b1ef8843805"
BR2_LINUX_KERNEL_DEFCONFIG="bcmrpi_quick"
BR2_LINUX_KERNEL_ZIMAGE=y
BR2_PACKAGE_RPI_FIRMWARE=y
BR2_PACKAGE_EJABBERD=y

In the meantime, I'll try with yours.
-- 
Johan

[Buildroot] [PATCH v3] ejabberd: new package

[Johan Oudinet]

Yann, All,

On Mon, Aug 11, 2014 at 11:36 AM, Johan Oudinet <johan.oudinet@gmail.com> wrote:
> In the meantime, I'll try with yours.

I've just tried with your minimal defconfig and the compilation
finished without an error :-/
I did a make clean after modifying the defconfig. Should I do something else?

-- 
Johan

[Buildroot] [PATCH v3] ejabberd: new package

[Yann E. MORIN]

Johan, All,

On 2014-08-11 12:07 +0200, Johan Oudinet spake thusly:
> On Mon, Aug 11, 2014 at 11:36 AM, Johan Oudinet <johan.oudinet@gmail.com> wrote:
> > In the meantime, I'll try with yours.
> 
> I've just tried with your minimal defconfig and the compilation
> finished without an error :-/
> I did a make clean after modifying the defconfig. Should I do something else?

Yes, please: could you de-install any erlang on your host system, and be
sure that the one in use is undeed the one built by Buildroot.

I do not have erlang installed on my machine, for the records.

Also, I'm building your configuration right now, I'll let you know how
that goes...

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH v3] ejabberd: new package

[Yann E. MORIN]

Johan, All,

On 2014-08-11 11:36 +0200, Johan Oudinet spake thusly:
> On Wed, Aug 6, 2014 at 10:23 PM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> > I tried building ejabberd in a minmal config, with:
> >
> >     BR2_x86_i686=y
> >     BR2_TOOLCHAIN_EXTERNAL=y
> >     BR2_INIT_NONE=y
> >     # BR2_PACKAGE_BUSYBOX is not set
> >     BR2_PACKAGE_EJABBERD=y
> >     # BR2_TARGET_ROOTFS_TAR is not set
> >
> > And it fails at build time, with a lengthy error message, that I do not
> > completely grasp:
> >
> >     /home/ymorin/dev/buildroot/O/host/usr/lib/erlang/bin/escript rebar
> > get-deps && :> deps/.got
> >     ==> rel (get-deps)
> >     Uncaught error in rebar_core: {'EXIT',
> >                                    {badarg,
> 
> Very strange. It looks like the rebar script didn't accept the
> get-deps argument.
> Could you try with the same defconfig as mine to see if the problem
> comes from there.
> $ cat defconfig
> BR2_arm=y
> BR2_arm1176jzf_s=y
> BR2_KERNEL_HEADERS_VERSION=y
> BR2_DEFAULT_KERNEL_VERSION="3.12.20"
> BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_12=y
> BR2_TOOLCHAIN_BUILDROOT_LARGEFILE=y
> BR2_TOOLCHAIN_BUILDROOT_LOCALE=y
> BR2_TOOLCHAIN_BUILDROOT_CXX=y
> BR2_TARGET_GENERIC_GETTY_PORT="ttyAMA0"
> BR2_LINUX_KERNEL=y
> BR2_LINUX_KERNEL_CUSTOM_GIT=y
> BR2_LINUX_KERNEL_CUSTOM_REPO_URL="git://github.com/raspberrypi/linux.git"
> BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION="a25152fdfbfd3b4330da16fc3aeb6b1ef8843805"
> BR2_LINUX_KERNEL_DEFCONFIG="bcmrpi_quick"
> BR2_LINUX_KERNEL_ZIMAGE=y
> BR2_PACKAGE_RPI_FIRMWARE=y
> BR2_PACKAGE_EJABBERD=y

I tried this defconfig (except I use an external toolchain to avoid
rebuilding it again and again) and I got the exact same error I had
previously (I did not check the numbers where the same, though.)

My build machine is an x86_64, running an up-to-date Ubuntu 14.04.
I'll check in a 32-bit chroot to see if the error is the same.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH v3] ejabberd: new package

[Yann E. MORIN]

Johan, All,

On 2014-08-11 12:33 +0200, Yann E. MORIN spake thusly:
> On 2014-08-11 11:36 +0200, Johan Oudinet spake thusly:
> > On Wed, Aug 6, 2014 at 10:23 PM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
[--SNIP--]
> > > And it fails at build time, with a lengthy error message, that I do not
> > > completely grasp:
> > >
> > >     /home/ymorin/dev/buildroot/O/host/usr/lib/erlang/bin/escript rebar
> > > get-deps && :> deps/.got
> > >     ==> rel (get-deps)
> > >     Uncaught error in rebar_core: {'EXIT',
> > >                                    {badarg,
> > 
> > Very strange. It looks like the rebar script didn't accept the
> > get-deps argument.
> > Could you try with the same defconfig as mine to see if the problem
> > comes from there.
[--SNIP--]
> I'll check in a 32-bit chroot to see if the error is the same.

OK, here's what it has to say when run in a 32-bit sueeze chroot:

    ---8<---
    /home/ymorin/dev/buildroot/O/host/usr/lib/erlang/bin/escript rebar get-deps && :> deps/.got
    Uncaught error in rebar_core: {'EXIT',
                                   {undef,
                                    [{crypto,start,[],[]},
                                     {rebar,run_aux,2,
                                      [{file,"src/rebar.erl"},{line,143}]},
                                     {rebar,main,1,
                                      [{file,"src/rebar.erl"},{line,58}]},
                                     {escript,run,2,
                                      [{file,"escript.erl"},{line,752}]},
                                     {escript,start,1,
                                      [{file,"escript.erl"},{line,276}]},
                                     {init,start_it,1,[]},
                                     {init,start_em,1,[]}]}}
    make[2]: *** [deps/.got] Error 1
    ---8<---

So, no better luck... :-(

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH v3] ejabberd: new package

[Frank Hunleth]

Hi Yann and all,

On Mon, Aug 11, 2014 at 6:50 AM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> Johan, All,
>
> On 2014-08-11 12:33 +0200, Yann E. MORIN spake thusly:
>> On 2014-08-11 11:36 +0200, Johan Oudinet spake thusly:
>> > On Wed, Aug 6, 2014 at 10:23 PM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> [--SNIP--]
>> > > And it fails at build time, with a lengthy error message, that I do not
>> > > completely grasp:
>> > >
>> > >     /home/ymorin/dev/buildroot/O/host/usr/lib/erlang/bin/escript rebar
>> > > get-deps && :> deps/.got
>> > >     ==> rel (get-deps)
>> > >     Uncaught error in rebar_core: {'EXIT',
>> > >                                    {badarg,
>> >
>> > Very strange. It looks like the rebar script didn't accept the
>> > get-deps argument.
>> > Could you try with the same defconfig as mine to see if the problem
>> > comes from there.
> [--SNIP--]
>> I'll check in a 32-bit chroot to see if the error is the same.
>
> OK, here's what it has to say when run in a 32-bit sueeze chroot:
>
>     ---8<---
>     /home/ymorin/dev/buildroot/O/host/usr/lib/erlang/bin/escript rebar get-deps && :> deps/.got
>     Uncaught error in rebar_core: {'EXIT',
>                                    {undef,
>                                     [{crypto,start,[],[]},
>                                      {rebar,run_aux,2,
>                                       [{file,"src/rebar.erl"},{line,143}]},
>                                      {rebar,main,1,
>                                       [{file,"src/rebar.erl"},{line,58}]},
>                                      {escript,run,2,
>                                       [{file,"escript.erl"},{line,752}]},
>                                      {escript,start,1,
>                                       [{file,"escript.erl"},{line,276}]},
>                                      {init,start_it,1,[]},
>                                      {init,start_em,1,[]}]}}
>     make[2]: *** [deps/.got] Error 1
>     ---8<---

I think that you can get this error if host erlang is compiled without
openssl. Maybe you don't have the openssl headers installed on your
system and Johan does?

Frank

[Buildroot] [PATCH v3] ejabberd: new package

[Yann E. MORIN]

Frank, All,

On 2014-08-13 14:48 -0400, Frank Hunleth spake thusly:
> On Mon, Aug 11, 2014 at 6:50 AM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> > Johan, All,
> >
> > On 2014-08-11 12:33 +0200, Yann E. MORIN spake thusly:
> >> On 2014-08-11 11:36 +0200, Johan Oudinet spake thusly:
> >> > On Wed, Aug 6, 2014 at 10:23 PM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> > [--SNIP--]
> >> > > And it fails at build time, with a lengthy error message, that I do not
> >> > > completely grasp:
> >> > >
> >> > >     /home/ymorin/dev/buildroot/O/host/usr/lib/erlang/bin/escript rebar
> >> > > get-deps && :> deps/.got
> >> > >     ==> rel (get-deps)
> >> > >     Uncaught error in rebar_core: {'EXIT',
> >> > >                                    {badarg,
> >> >
> >> > Very strange. It looks like the rebar script didn't accept the
> >> > get-deps argument.
> >> > Could you try with the same defconfig as mine to see if the problem
> >> > comes from there.
> > [--SNIP--]
> >> I'll check in a 32-bit chroot to see if the error is the same.
> >
> > OK, here's what it has to say when run in a 32-bit sueeze chroot:
> >
> >     ---8<---
> >     /home/ymorin/dev/buildroot/O/host/usr/lib/erlang/bin/escript rebar get-deps && :> deps/.got
> >     Uncaught error in rebar_core: {'EXIT',
> >                                    {undef,
> >                                     [{crypto,start,[],[]},
> >                                      {rebar,run_aux,2,
> >                                       [{file,"src/rebar.erl"},{line,143}]},
> >                                      {rebar,main,1,
> >                                       [{file,"src/rebar.erl"},{line,58}]},
> >                                      {escript,run,2,
> >                                       [{file,"escript.erl"},{line,752}]},
> >                                      {escript,start,1,
> >                                       [{file,"escript.erl"},{line,276}]},
> >                                      {init,start_it,1,[]},
> >                                      {init,start_em,1,[]}]}}
> >     make[2]: *** [deps/.got] Error 1
> >     ---8<---
> 
> I think that you can get this error if host erlang is compiled without
> openssl. Maybe you don't have the openssl headers installed on your
> system and Johan does?

Ah, good idea.

I currently have them installed, but I think I installed them recently.
Let me retry a build, once with them installed, once with them
uninstalled.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH v3] ejabberd: new package

[Yann E. MORIN]

Frank, All,

On 2014-08-13 14:48 -0400, Frank Hunleth spake thusly:
> On Mon, Aug 11, 2014 at 6:50 AM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> > Johan, All,
> >
> > On 2014-08-11 12:33 +0200, Yann E. MORIN spake thusly:
> >> On 2014-08-11 11:36 +0200, Johan Oudinet spake thusly:
> >> > On Wed, Aug 6, 2014 at 10:23 PM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> > [--SNIP--]
> >> > > And it fails at build time, with a lengthy error message, that I do not
> >> > > completely grasp:
> >> > >
> >> > >     /home/ymorin/dev/buildroot/O/host/usr/lib/erlang/bin/escript rebar
> >> > > get-deps && :> deps/.got
> >> > >     ==> rel (get-deps)
> >> > >     Uncaught error in rebar_core: {'EXIT',
> >> > >                                    {badarg,
> >> >
> >> > Very strange. It looks like the rebar script didn't accept the
> >> > get-deps argument.
> >> > Could you try with the same defconfig as mine to see if the problem
> >> > comes from there.
> > [--SNIP--]
> >> I'll check in a 32-bit chroot to see if the error is the same.
> >
> > OK, here's what it has to say when run in a 32-bit sueeze chroot:
> >
> >     ---8<---
> >     /home/ymorin/dev/buildroot/O/host/usr/lib/erlang/bin/escript rebar get-deps && :> deps/.got
> >     Uncaught error in rebar_core: {'EXIT',
> >                                    {undef,
> >                                     [{crypto,start,[],[]},
> >                                      {rebar,run_aux,2,
> >                                       [{file,"src/rebar.erl"},{line,143}]},
> >                                      {rebar,main,1,
> >                                       [{file,"src/rebar.erl"},{line,58}]},
> >                                      {escript,run,2,
> >                                       [{file,"escript.erl"},{line,752}]},
> >                                      {escript,start,1,
> >                                       [{file,"escript.erl"},{line,276}]},
> >                                      {init,start_it,1,[]},
> >                                      {init,start_em,1,[]}]}}
> >     make[2]: *** [deps/.got] Error 1
> >     ---8<---
> 
> I think that you can get this error if host erlang is compiled without
> openssl. Maybe you don't have the openssl headers installed on your
> system and Johan does?

Alas, no better luck.

I did de-install my libssl-dev package, so I only get the runtime from
openssl, and not the development files.

Then, I did three tests, all starting afresh from a clean tree, with the
ejabberd patch applied on top of master (e3bb4ac: fbv: fix typo in
pkg-config variable):

  - with just the patch;
  - then with a modified erlang.mk to compile our host erlang without ssl;
  - then with a modified erlang.mk to compile our host erlang with ssl.

All three build failed in the exact same way.

To disable ssl, I did:
    HOST_ERLANG_CONF_OPT += --without-ssl

To enable ssl, I did:
    HOST_ERLANG_CONF_OPT += --with-ssl
    HOST_ERLANG_DEPENDENCIES += host-openssl

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH v3] ejabberd: new package

[Frank Hunleth]

Yann, All,

On Wed, Aug 13, 2014 at 4:44 PM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
>
> Frank, All,
>
> On 2014-08-13 14:48 -0400, Frank Hunleth spake thusly:
> > On Mon, Aug 11, 2014 at 6:50 AM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> > > Johan, All,
> > >
> > > On 2014-08-11 12:33 +0200, Yann E. MORIN spake thusly:
> > >> On 2014-08-11 11:36 +0200, Johan Oudinet spake thusly:
> > >> > On Wed, Aug 6, 2014 at 10:23 PM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> > > [--SNIP--]
> > >> > > And it fails at build time, with a lengthy error message, that I do not
> > >> > > completely grasp:
> > >> > >
> > >> > >     /home/ymorin/dev/buildroot/O/host/usr/lib/erlang/bin/escript rebar
> > >> > > get-deps && :> deps/.got
> > >> > >     ==> rel (get-deps)
> > >> > >     Uncaught error in rebar_core: {'EXIT',
> > >> > >                                    {badarg,
> > >> >
> > >> > Very strange. It looks like the rebar script didn't accept the
> > >> > get-deps argument.
> > >> > Could you try with the same defconfig as mine to see if the problem
> > >> > comes from there.
> > > [--SNIP--]
> > >> I'll check in a 32-bit chroot to see if the error is the same.
> > >
> > > OK, here's what it has to say when run in a 32-bit sueeze chroot:
> > >
> > >     ---8<---
> > >     /home/ymorin/dev/buildroot/O/host/usr/lib/erlang/bin/escript rebar get-deps && :> deps/.got
> > >     Uncaught error in rebar_core: {'EXIT',
> > >                                    {undef,
> > >                                     [{crypto,start,[],[]},
> > >                                      {rebar,run_aux,2,
> > >                                       [{file,"src/rebar.erl"},{line,143}]},
> > >                                      {rebar,main,1,
> > >                                       [{file,"src/rebar.erl"},{line,58}]},
> > >                                      {escript,run,2,
> > >                                       [{file,"escript.erl"},{line,752}]},
> > >                                      {escript,start,1,
> > >                                       [{file,"escript.erl"},{line,276}]},
> > >                                      {init,start_it,1,[]},
> > >                                      {init,start_em,1,[]}]}}
> > >     make[2]: *** [deps/.got] Error 1
> > >     ---8<---
> >
> > I think that you can get this error if host erlang is compiled without
> > openssl. Maybe you don't have the openssl headers installed on your
> > system and Johan does?
>
> Alas, no better luck.
>
> I did de-install my libssl-dev package, so I only get the runtime from
> openssl, and not the development files.
>
> Then, I did three tests, all starting afresh from a clean tree, with the
> ejabberd patch applied on top of master (e3bb4ac: fbv: fix typo in
> pkg-config variable):
>
>   - with just the patch;
>   - then with a modified erlang.mk to compile our host erlang without ssl;
>   - then with a modified erlang.mk to compile our host erlang with ssl.
>
> All three build failed in the exact same way.

Do you have an output/host/usr/lib/erlang/lib/crypto-3.3/priv/lib
directory with a couple shared libraries in it? I assume not based on
the failure, but wanted to check.

Also, does the log from Erlang's ./configure provide any clues?

FWIW, everything that you're doing sounds good to me. I've only seen
the "crypto" undef error on targets when I've forgotten to enable
openssl. I've never seen it on the host, but my host has a lot of
header files, so it's probably not a good test.

>
> To disable ssl, I did:
>     HOST_ERLANG_CONF_OPT += --without-ssl
>
> To enable ssl, I did:
>     HOST_ERLANG_CONF_OPT += --with-ssl
>     HOST_ERLANG_DEPENDENCIES += host-openssl
>
> Regards,
> Yann E. MORIN.
>
> --
> .-----------------.--------------------.------------------.--------------------.
> |  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
> | +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
> | +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
> | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
> '------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH v3] ejabberd: new package

[Yann E. MORIN]

Frank, All,

On 2014-08-13 17:23 -0400, Frank Hunleth spake thusly:
[--SNIP--]
> > > >
> > > > OK, here's what it has to say when run in a 32-bit sueeze chroot:
> > > >
> > > >     ---8<---
> > > >     /home/ymorin/dev/buildroot/O/host/usr/lib/erlang/bin/escript rebar get-deps && :> deps/.got
> > > >     Uncaught error in rebar_core: {'EXIT',
> > > >                                    {undef,
> > > >                                     [{crypto,start,[],[]},
> > > >                                      {rebar,run_aux,2,
> > > >                                       [{file,"src/rebar.erl"},{line,143}]},
> > > >                                      {rebar,main,1,
> > > >                                       [{file,"src/rebar.erl"},{line,58}]},
> > > >                                      {escript,run,2,
> > > >                                       [{file,"escript.erl"},{line,752}]},
> > > >                                      {escript,start,1,
> > > >                                       [{file,"escript.erl"},{line,276}]},
> > > >                                      {init,start_it,1,[]},
> > > >                                      {init,start_em,1,[]}]}}
> > > >     make[2]: *** [deps/.got] Error 1
> > > >     ---8<---
> > >
> > > I think that you can get this error if host erlang is compiled without
> > > openssl. Maybe you don't have the openssl headers installed on your
> > > system and Johan does?
> >
> > Alas, no better luck.
> >
> > I did de-install my libssl-dev package, so I only get the runtime from
> > openssl, and not the development files.
> >
> > Then, I did three tests, all starting afresh from a clean tree, with the
> > ejabberd patch applied on top of master (e3bb4ac: fbv: fix typo in
> > pkg-config variable):
> >
> >   - with just the patch;
> >   - then with a modified erlang.mk to compile our host erlang without ssl;
> >   - then with a modified erlang.mk to compile our host erlang with ssl.
> >
> > All three build failed in the exact same way.
> 
> Do you have an output/host/usr/lib/erlang/lib/crypto-3.3/priv/lib
> directory with a couple shared libraries in it? I assume not based on
> the failure, but wanted to check.

I re-ran the test with erlang.mk patched to depend on host-openssl and
added back the --with-ssl flag when building the host erlang.

Indeed, I do not have this directory.

> Also, does the log from Erlang's ./configure provide any clues?

Aha!

    checking for static ZLib to be used by SSL in standard locations... no
    checking for OpenSSL >= 0.9.7 in standard locations... no
    configure: WARNING: No (usable) OpenSSL found, skipping ssl, ssh and crypto applications

Dang... It seems we have to tell it where to look for our own openssl.
Lemme see... Yes, we can say --with-ssl=PATH . I'll try that, and will
report later...

Thanks for the hint! :-)

Regards,
Yann E. MORIN.

> FWIW, everything that you're doing sounds good to me. I've only seen
> the "crypto" undef error on targets when I've forgotten to enable
> openssl. I've never seen it on the host, but my host has a lot of
> header files, so it's probably not a good test.
> 
> >
> > To disable ssl, I did:
> >     HOST_ERLANG_CONF_OPT += --without-ssl
> >
> > To enable ssl, I did:
> >     HOST_ERLANG_CONF_OPT += --with-ssl
> >     HOST_ERLANG_DEPENDENCIES += host-openssl
> >
> > Regards,
> > Yann E. MORIN.
> >
> > --
> > .-----------------.--------------------.------------------.--------------------.
> > |  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
> > | +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
> > | +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
> > | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
> > '------------------------------^-------^------------------^--------------------'

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH v3] ejabberd: new package

[Yann E. MORIN]

Frank, All,

On 2014-08-13 23:49 +0200, Yann E. MORIN spake thusly:
> On 2014-08-13 17:23 -0400, Frank Hunleth spake thusly:
> > > > I think that you can get this error if host erlang is compiled without
> > > > openssl. Maybe you don't have the openssl headers installed on your
> > > > system and Johan does?
[--SNIP--]
> I re-ran the test with erlang.mk patched to depend on host-openssl and
> added back the --with-ssl flag when building the host erlang.
> 
> Indeed, I do not have this directory.

OK, now I have it. My host-erlang is compiled with ssl support.
But...

> > Also, does the log from Erlang's ./configure provide any clues?
> 
> Aha!
> 
>     checking for static ZLib to be used by SSL in standard locations... no
>     checking for OpenSSL >= 0.9.7 in standard locations... no
>     configure: WARNING: No (usable) OpenSSL found, skipping ssl, ssh and crypto applications
> 
> Dang... It seems we have to tell it where to look for our own openssl.
> Lemme see... Yes, we can say --with-ssl=PATH . I'll try that, and will
> report later...

Now, my error is back to this sequence of numbers:

Uncaught error in rebar_core: {'EXIT',
                               {badarg,
                                [{re,replace,
                                  [[40,41,32,123,32,32,108,111,99,97,108,32,
                                    82,69,84,61,34,36,123,63,125,34,59,10,32,
                                    108,111,99,97,108,32,105,115,95,110,101,
                                    116,95,109,110,116,112,116,61,48,59,10,32,
                                    108,111,99,97,108,32,72,71,80,76,65,73,78,
                                    59,10,32,108,111,99,97,108,32,76,79,65,68,
...
                                    66,76,85,125,36,123,80,83,49,125,36,123,
                                    65,95,78,79,82,125,34,59,10,32,104,105,
                                    115,116,111,114,121,32,45,97,59,10,32,112,
                                    114,111,109,112,116,95,102,105,114,115,
                                    116,61,48,10,125],
                                   [92,36,40,"doPrompt",40,92,115,124,36,41,
                                    124,123,"doPrompt",125,41],
                                   [[],"\\2"],
                                   [global,{return,list}]],
                                  [{file,"re.erl"},{line,355}]},
                                 {rebar_port_compiler,merge_each_var,2,
                                  [{file,"src/rebar_port_compiler.erl"},
                                   {line,380}]},
                                 {rebar_port_compiler,setup_env,2,
                                  [{file,"src/rebar_port_compiler.erl"},
                                   {line,167}]},
                                 {rebar_core,'-setup_envs/2-fun-0-',2,
                                  [{file,"src/rebar_core.erl"},{line,436}]},
                                 {lists,foldl,3,
                                  [{file,"lists.erl"},{line,1261}]},
                                 {rebar_core,process_dir1,6,
                                  [{file,"src/rebar_core.erl"},{line,190}]},
                                 {rebar_core,process_commands,2,
                                  [{file,"src/rebar_core.erl"},{line,61}]},
                                 {rebar,main,1,
                                  [{file,"src/rebar.erl"},{line,58}]}]}}
make[1]: *** [deps/.got] Error 1

OK, I'm lost... :-(

One thing I just noticed, are those two lines (visible above, too):

    [92,36,40,"doPrompt",40,92,115,124,36,41,
     124,123,"doPrompt",125,41],

doPrompt is the content of my $PROMPT_COMMAND environment variable, in
case that rings a bell somewhere...

I'll let you guys investigate further. I can run tests if you need to.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH v3] ejabberd: new package

[Frank Hunleth]

Yann,

On Wed, Aug 13, 2014 at 6:18 PM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> Frank, All,
>
> On 2014-08-13 23:49 +0200, Yann E. MORIN spake thusly:
>> On 2014-08-13 17:23 -0400, Frank Hunleth spake thusly:
>> > > > I think that you can get this error if host erlang is compiled without
>> > > > openssl. Maybe you don't have the openssl headers installed on your
>> > > > system and Johan does?
> [--SNIP--]
>> I re-ran the test with erlang.mk patched to depend on host-openssl and
>> added back the --with-ssl flag when building the host erlang.
>>
>> Indeed, I do not have this directory.
>
> OK, now I have it. My host-erlang is compiled with ssl support.
> But...
>
>> > Also, does the log from Erlang's ./configure provide any clues?
>>
>> Aha!
>>
>>     checking for static ZLib to be used by SSL in standard locations... no
>>     checking for OpenSSL >= 0.9.7 in standard locations... no
>>     configure: WARNING: No (usable) OpenSSL found, skipping ssl, ssh and crypto applications
>>
>> Dang... It seems we have to tell it where to look for our own openssl.
>> Lemme see... Yes, we can say --with-ssl=PATH . I'll try that, and will
>> report later...
>
> Now, my error is back to this sequence of numbers:
>
> Uncaught error in rebar_core: {'EXIT',
>                                {badarg,
>                                 [{re,replace,
>                                   [[40,41,32,123,32,32,108,111,99,97,108,32,
>                                     82,69,84,61,34,36,123,63,125,34,59,10,32,
>                                     108,111,99,97,108,32,105,115,95,110,101,
>                                     116,95,109,110,116,112,116,61,48,59,10,32,
>                                     108,111,99,97,108,32,72,71,80,76,65,73,78,
>                                     59,10,32,108,111,99,97,108,32,76,79,65,68,
> ...
>                                     66,76,85,125,36,123,80,83,49,125,36,123,
>                                     65,95,78,79,82,125,34,59,10,32,104,105,
>                                     115,116,111,114,121,32,45,97,59,10,32,112,
>                                     114,111,109,112,116,95,102,105,114,115,
>                                     116,61,48,10,125],
>                                    [92,36,40,"doPrompt",40,92,115,124,36,41,
>                                     124,123,"doPrompt",125,41],
>                                    [[],"\\2"],
>                                    [global,{return,list}]],
>                                   [{file,"re.erl"},{line,355}]},
>                                  {rebar_port_compiler,merge_each_var,2,
>                                   [{file,"src/rebar_port_compiler.erl"},
>                                    {line,380}]},
>                                  {rebar_port_compiler,setup_env,2,
>                                   [{file,"src/rebar_port_compiler.erl"},
>                                    {line,167}]},
>                                  {rebar_core,'-setup_envs/2-fun-0-',2,
>                                   [{file,"src/rebar_core.erl"},{line,436}]},
>                                  {lists,foldl,3,
>                                   [{file,"lists.erl"},{line,1261}]},
>                                  {rebar_core,process_dir1,6,
>                                   [{file,"src/rebar_core.erl"},{line,190}]},
>                                  {rebar_core,process_commands,2,
>                                   [{file,"src/rebar_core.erl"},{line,61}]},
>                                  {rebar,main,1,
>                                   [{file,"src/rebar.erl"},{line,58}]}]}}
> make[1]: *** [deps/.got] Error 1
>
> OK, I'm lost... :-(
>
> One thing I just noticed, are those two lines (visible above, too):
>
>     [92,36,40,"doPrompt",40,92,115,124,36,41,
>      124,123,"doPrompt",125,41],
>

The lists of numbers are Erlang's way of printing strings when it gets
confused. Presumably your $PROMPT_COMMAND is
"\\$(doPrompt(\\s|$)|{doPrompt})". It looks like rebar is trying to do
a regular expression search and replace in a string that starts with
"() {  local RET=\"${?}\";\n local is_net_mntpt=0;\n local HGPLAIN;\n
local LOAD".

I looked through the rebar source code to see why it would do this,
but ejabberd must have an old version of rebar since it didn't match.
Just as an aside, in the Erlang world, people often copy the
"compiled" version of rebar to their projects so that any one who
wants to build them doesn't have to download and build the build tool.
Rebar has some issues, so many projects have switched back to
Makefiles, but clearly not ejabberd.

I have two thoughts: first is to try to build with a minimal
environment just in case rebar is getting confused on something in
yours (like your prompt settings). The second is to replace the
version of rebar in ejabberd with the latest and greatest in case they
fixed it. See https://github.com/rebar/rebar/releases.

To be honest, this feels like it's getting above and beyond the level
of debug that you should have to do. I have some fondness for Erlang,
so I might try to put in some more time this weekend to figure out
what's going on.

Frank

> doPrompt is the content of my $PROMPT_COMMAND environment variable, in
> case that rings a bell somewhere...
>
> I'll let you guys investigate further. I can run tests if you need to.
>
> Regards,
> Yann E. MORIN.
>
> --
> .-----------------.--------------------.------------------.--------------------.
> |  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
> | +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
> | +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
> | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
> '------------------------------^-------^------------------^--------------------'



-- 
Frank Hunleth
Troodon Software LLC
Embedded Software Development
http://troodon-software.com/

[Buildroot] [PATCH v3] ejabberd: new package

[Yann E. MORIN]

Frank, All,

Thanks for all the help so far! :-)

On 2014-08-14 08:40 -0400, Frank Hunleth spake thusly:
> On Wed, Aug 13, 2014 at 6:18 PM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> > On 2014-08-13 23:49 +0200, Yann E. MORIN spake thusly:
[--SNIP--]
> > Now, my error is back to this sequence of numbers:
> >
> > Uncaught error in rebar_core: {'EXIT',
> >                                {badarg,
> >                                 [{re,replace,
> >                                   [[40,41,32,123,32,32,108,111,99,97,108,32,
> >                                     82,69,84,61,34,36,123,63,125,34,59,10,32,
> >                                     108,111,99,97,108,32,105,115,95,110,101,
> > ...
> >                                     115,116,111,114,121,32,45,97,59,10,32,112,
> >                                     114,111,109,112,116,95,102,105,114,115,
> >                                     116,61,48,10,125],
> >                                    [92,36,40,"doPrompt",40,92,115,124,36,41,
[--SNIP--]
> The lists of numbers are Erlang's way of printing strings when it gets
> confused. Presumably your $PROMPT_COMMAND is
> "\\$(doPrompt(\\s|$)|{doPrompt})". It looks like rebar is trying to do
> a regular expression search and replace in a string that starts with
> "() {  local RET=\"${?}\";\n local is_net_mntpt=0;\n local HGPLAIN;\n
> local LOAD".

    $ echo $PROMPT_COMMAND
    doPrompt

doPrompt is a shell function that prepares my prompt with a lot of
information (git status, time, battery left...)

I've run a build where PROMPT_COMMAND was missing in the envirnment (but
doPrompt still exists), to no avail. I still get all those numbers...
I did decode all those numbers, and they happen to be exactly the
content of my doPrompt function.

I really wonder what is so strange that rebar chokes on it. Why doe it
even have to look at those, to begin with? :-(

Oh, could that be that doPrompt is exported?

    $ env |grep doPrompt
    PROMPT_COMMAND=doPrompt
    doPrompt=() {  local RET="${?}";

I have this in my .bashrc :

    export -f doPrompt

Hm... I'll try to find some time to run without that in my env...
Yet, it should not choke on it.

> I have two thoughts: first is to try to build with a minimal
> environment just in case rebar is getting confused on something in
> yours (like your prompt settings). The second is to replace the
> version of rebar in ejabberd with the latest and greatest in case they
> fixed it. See https://github.com/rebar/rebar/releases.

I was thinking about the exact same solution, to build our own rebar.

> To be honest, this feels like it's getting above and beyond the level
> of debug that you should have to do.

Well, to be honest, I don't think ejabberd can go in Buildroot at all
for now. It has to do downloads during build time, which is a big
show-stopper IMHO. We currently have no other package that downloads
stuff during the build phase, and for those that usualy do (eg.
tvheadend), we fixed them not to (e.g. to rely on another package, like
dtv-scan-tables.)

And to be further honest, I see Erlang and its ecosystem to be just
completely broken, even more broken than Perl+CPAN (which I do not like
much to start with.)

Yet, I would like to see a Jabber server in Buildroot. I would *love*
that. Hence my persistence in trying to find a solution. But I'm here at
a loss, with no further idea... :-(

> I have some fondness for Erlang,
> so I might try to put in some more time this weekend to figure out
> what's going on.

That'd be great, thanks! :-)

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH v3] ejabberd: new package

[Johan Oudinet]

Yann, all,

On Mon, Aug 11, 2014 at 12:33 PM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
>
> My build machine is an x86_64, running an up-to-date Ubuntu 14.04.
> I'll check in a 32-bit chroot to see if the error is the same.

I removed ejabberd and all erlang packages installed on the host, even
purged them to be sure buildroot does not use their configuration
files. It is also an up-to-date Ubuntu 14.04 64bits.
After that, make clean all (with your minimal defconfig) still work :-/
Is there anything more I can do?

-- 
Johan

[Buildroot] [PATCH v3] ejabberd: new package

[Yann E. MORIN]

Johan, All,

On 2014-08-11 15:13 +0200, Johan Oudinet spake thusly:
> On Mon, Aug 11, 2014 at 12:33 PM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> >
> > My build machine is an x86_64, running an up-to-date Ubuntu 14.04.
> > I'll check in a 32-bit chroot to see if the error is the same.
> 
> I removed ejabberd and all erlang packages installed on the host, even
> purged them to be sure buildroot does not use their configuration
> files. It is also an up-to-date Ubuntu 14.04 64bits.
> After that, make clean all (with your minimal defconfig) still work :-/
> Is there anything more I can do?

No, sorry. I am clueless now...

If I get a bit of time, I'll run some tests tonight...

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH v3] ejabberd: new package

[Yann E. MORIN]

Johan, All,

On 2014-07-18 14:33 +0200, Johan Oudinet spake thusly:
> diff --git a/package/Config.in b/package/Config.in
> index 22ddea8..eb0aaaa 100644
> --- a/package/Config.in
> +++ b/package/Config.in
> @@ -943,6 +943,7 @@ endif
>  	source "package/dnsmasq/Config.in"
>  	source "package/dropbear/Config.in"
>  	source "package/ebtables/Config.in"
> +	source "package/ejabberd/Config.in"
>  	source "package/ethtool/Config.in"
>  	source "package/faifa/Config.in"
>  	source "package/fmc/Config.in"
[--SNIP--]

We've been discussing this ejabberd patch during the current Developpers
Day in D?sseldorf.

Given the current issues that ewre noticed with building ejabberd, we
decided to mark the patch as Rejected in patchwork.

This means that we rejected that very specific patch, *not* that we
decided not to have ejabberd. But before it gets included, all the
issues must be fixed first, especially the build-time downloading of
dependencies, as well as all the remarks that were made by Thomas and I.

Of course, we are happy to help solve them, if you need help/advice on
it.

Thank you for working on this!

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH v3] ejabberd: new package

[Johan Oudinet]

Hi Yann, all,

On Sat, Oct 11, 2014 at 6:21 PM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
>
> We've been discussing this ejabberd patch during the current Developpers
> Day in D?sseldorf.
>
> Given the current issues that ewre noticed with building ejabberd, we
> decided to mark the patch as Rejected in patchwork.
>
> This means that we rejected that very specific patch, *not* that we
> decided not to have ejabberd. But before it gets included, all the
> issues must be fixed first, especially the build-time downloading of
> dependencies, as well as all the remarks that were made by Thomas and I.

Sure, it makes sense to me as well. As I said in a previous mail, I
did fix my patch to include your remarks, but two:
1. Fix ejabberd build system to not download dependencies at build time.
2. Avoid to use a fix UID and GID for ejabberd user.

I don't know if I should republish the patch before fixing these two issues.
I'd like your help on both of them.

** Fix ejabberd build system
** ===================
The only solution i see is to create a buildroot package for every
ejabberd dependency, listed in rebar.config.script :
esip, goldrush, lager, p1_cache_tab, p1_iconv, p1_stringprep, p1_stun,
p1_tls, p1_utils, p1_xml, p1_yaml, p1_zlib, xmlrpc
Then, modify ejabberd package to not use rebar at all, or at least to
not call rebar get-deps. Thus, if I remove deps from the `all'
makefile rule and deps/.build from the `src' rule dependency, it might
work.

Do you have a better idea?

** Avoid to use a fix UID and GID for ejabberd user
** ===================================

I still don't know how I could set the correct permissions to ejabberd
files in <PKG>_PERMISSIONS if I set -1 for UID and GID in <PKG>_USERS

Best regards,
-- 
Johan

[Buildroot] [PATCH v3] ejabberd: new package

[Yann E. MORIN]

Johan, All,

On 2014-10-16 14:38 +0200, Johan Oudinet spake thusly:
> On Sat, Oct 11, 2014 at 6:21 PM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> >
> > We've been discussing this ejabberd patch during the current Developpers
> > Day in D?sseldorf.
> >
> > Given the current issues that ewre noticed with building ejabberd, we
> > decided to mark the patch as Rejected in patchwork.
> >
> > This means that we rejected that very specific patch, *not* that we
> > decided not to have ejabberd. But before it gets included, all the
> > issues must be fixed first, especially the build-time downloading of
> > dependencies, as well as all the remarks that were made by Thomas and I.
> 
> Sure, it makes sense to me as well. As I said in a previous mail, I
> did fix my patch to include your remarks, but two:
> 1. Fix ejabberd build system to not download dependencies at build time.
> 2. Avoid to use a fix UID and GID for ejabberd user.
> 
> I don't know if I should republish the patch before fixing these two issues.
> I'd like your help on both of them.
> 
> ** Fix ejabberd build system
> ** ===================
> The only solution i see is to create a buildroot package for every
> ejabberd dependency, listed in rebar.config.script :
> esip, goldrush, lager, p1_cache_tab, p1_iconv, p1_stringprep, p1_stun,
> p1_tls, p1_utils, p1_xml, p1_yaml, p1_zlib, xmlrpc
> Then, modify ejabberd package to not use rebar at all, or at least to
> not call rebar get-deps. Thus, if I remove deps from the `all'
> makefile rule and deps/.build from the `src' rule dependency, it might
> work.
> 
> Do you have a better idea?

No, I have no better idea. I don't know how rebar works, but we indeed
need to have one package for each dependency. Having ejabberd (rebar, in
fact) do the download at configure/build time is not acceptable.

Howeever, I can see where that brings us:

  - there are so far 14 identified such dependencies;

  - maybe (probably?) each of those dependencies mya in turn have more
    dependencies, which add up to the list;

  - I have absolutely no idea how rebar (or the whole erlang ecosystem)
    behaves for corss-compilation (hint: probably badly), which would
    make for very tricky package recipes;

  - thus, we'd highly benefit from a specialised package infrastructure,
    like we have for perl, python or lua packages, though I'm afraid
    that would not be a piece of cake to add such an infra.

So, I really don;t know where to go from there... :-(

If you were inclined into looking into this, then I think the best
course of actions for you would be somelthing along those lines:

  (1) create a new package for the simplest, leaf-most dependency; this
      will allow you to assess how complex it is to cross-build a single,
      simple erlang package;

  (2) add a new package that depends directly on, and only on the one
      above; this will allow you to assess how complex it is to express
      erlang dependencies in cross-compilation;

  (3) progress with a few more packages (say, up to 3-5 packages); this
      will allow you to have a global understanding about the
      comonalities and specifities of erlang packages;

  (4) see how to turn that into a specific package infrastructure;

  (5) post your results to the list, so we can all agree on that new
      infra; this will allow all of us to get to solve issues in a clean
      and sane way;

  (6) introduce that new infra, and convert the existing packages over
      to that new infra;

  (7) add every missing ejabberd dependencies one after the other,
      adapting the new infra in case it is needed, until you eventually
      reach to packaging ejabberd;

  (8) rejoice! ;-)

Note that this will probably be a lot of work, and I do not expect it to
be easy at all. I'm willing to participate in this effort, if you want.

> ** Avoid to use a fix UID and GID for ejabberd user
> ** ===================================
> 
> I still don't know how I could set the correct permissions to ejabberd
> files [...]

A quick solution to that would be to have all of ejabberd's files in a
specific directory, like /var/ejabberd (find a better location1), add
the necessary symlinks to point to that location, and use that location
in EJABBERD_USERS:

    ejabberd -1 ejabberd -1 * /var/ejabberd - - ejabberd daemon

> [...] in <PKG>_PERMISSIONS if I set -1 for UID and GID in <PKG>_USERS

Indeed, there is no provision for using UIDs/GIDs from the _USERS variable,
from the _PERMISSIONS.

I'll look into that...

Regards,
Yann E. MORIN.


-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH v3] ejabberd: new package

[Arnout Vandecappelle]

On 16/10/14 14:38, Johan Oudinet wrote:
> ** Fix ejabberd build system
> ** ===================
> The only solution i see is to create a buildroot package for every
> ejabberd dependency, listed in rebar.config.script :
> esip, goldrush, lager, p1_cache_tab, p1_iconv, p1_stringprep, p1_stun,
> p1_tls, p1_utils, p1_xml, p1_yaml, p1_zlib, xmlrpc
> Then, modify ejabberd package to not use rebar at all, or at least to
> not call rebar get-deps. Thus, if I remove deps from the `all'
> makefile rule and deps/.build from the `src' rule dependency, it might
> work.
> 
> Do you have a better idea?

 Perhaps it's an option to run rebar in download-only mode in the download step?
We'd probably need to add a rebar-specific download option, and make sure that
it downloads to the download directory, and make sure that it doesn't do any
network access if the files are already there. This may be complicated...

 If you need to create separate packages, it's probably worthwhile to create a
script to automate that, like Francois Perrad did for the perl modules.


 Regards,
 Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] [PATCH v3] ejabberd: new package

[Yann E. MORIN]

Arnout, All,

On 2014-10-18 01:06 +0200, Arnout Vandecappelle spake thusly:
> On 16/10/14 14:38, Johan Oudinet wrote:
> > ** Fix ejabberd build system
> > ** ===================
> > The only solution i see is to create a buildroot package for every
> > ejabberd dependency, listed in rebar.config.script :
> > esip, goldrush, lager, p1_cache_tab, p1_iconv, p1_stringprep, p1_stun,
> > p1_tls, p1_utils, p1_xml, p1_yaml, p1_zlib, xmlrpc
> > Then, modify ejabberd package to not use rebar at all, or at least to
> > not call rebar get-deps. Thus, if I remove deps from the `all'
> > makefile rule and deps/.build from the `src' rule dependency, it might
> > work.
> > 
> > Do you have a better idea?
> 
>  Perhaps it's an option to run rebar in download-only mode in the download step?

The problem is that rebar is an executable bundled in the ejabberd
archive, so, we can't run it before we extract ejabberd... :-(

Unless we can switch to using an external rebar. Johan?

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH v3] ejabberd: new package

[Johan Oudinet]

Yann, Arnout, All,
Le 18 oct. 2014 12:00, "Yann E. MORIN" <yann.morin.1998@free.fr> a ?crit :
> On 2014-10-18 01:06 +0200, Arnout Vandecappelle spake thusly:
> > On 16/10/14 14:38, Johan Oudinet wrote:
> > > ** Fix ejabberd build system
> > > ** ===================
> > > The only solution i see is to create a buildroot package for every
> > > ejabberd dependency, listed in rebar.config.script :
> > > esip, goldrush, lager, p1_cache_tab, p1_iconv, p1_stringprep, p1_stun,
> > > p1_tls, p1_utils, p1_xml, p1_yaml, p1_zlib, xmlrpc
> > > Then, modify ejabberd package to not use rebar at all, or at least to
> > > not call rebar get-deps. Thus, if I remove deps from the `all'
> > > makefile rule and deps/.build from the `src' rule dependency, it might
> > > work.
> > >
> > > Do you have a better idea?
> >
> >  Perhaps it's an option to run rebar in download-only mode in the
download step?
>
> The problem is that rebar is an executable bundled in the ejabberd
> archive, so, we can't run it before we extract ejabberd... :-(
>
> Unless we can switch to using an external rebar. Johan?

Well, we could package the rebar project and use it instead of the binary
included in ejabberd but I don't think it's a good idea.
Actually, I've looked at how Debian has packaged ejabberd and they did
patch it to get rid of the get-deps rule and packages every dependency
separately.
I'm going to have a look how perl is integrated in buildroot.
Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20141018/e2704eb2/attachment.html>

[Buildroot] [PATCH v3] ejabberd: new package

[Johan Oudinet]

On Sat, Oct 18, 2014 at 12:31 PM, Johan Oudinet <johan.oudinet@gmail.com> wrote:
> Yann, Arnout, All,
> Le 18 oct. 2014 12:00, "Yann E. MORIN" <yann.morin.1998@free.fr> a ?crit :
>> On 2014-10-18 01:06 +0200, Arnout Vandecappelle spake thusly:
>> > On 16/10/14 14:38, Johan Oudinet wrote:
>> > > ** Fix ejabberd build system
>> > > ** ===================
>> > > The only solution i see is to create a buildroot package for every
>> > > ejabberd dependency, listed in rebar.config.script :
>> > > esip, goldrush, lager, p1_cache_tab, p1_iconv, p1_stringprep, p1_stun,
>> > > p1_tls, p1_utils, p1_xml, p1_yaml, p1_zlib, xmlrpc
>> > > Then, modify ejabberd package to not use rebar at all, or at least to
>> > > not call rebar get-deps. Thus, if I remove deps from the `all'
>> > > makefile rule and deps/.build from the `src' rule dependency, it might
>> > > work.
>> > >
>> > > Do you have a better idea?
>> >
>> >  Perhaps it's an option to run rebar in download-only mode in the
>> > download step?
>>
>> The problem is that rebar is an executable bundled in the ejabberd
>> archive, so, we can't run it before we extract ejabberd... :-(
>>
>> Unless we can switch to using an external rebar. Johan?
>
> Well, we could package the rebar project and use it instead of the binary
> included in ejabberd but I don't think it's a good idea.
> Actually, I've looked at how Debian has packaged ejabberd and they did patch
> it to get rid of the get-deps rule and packages every dependency separately.
> I'm going to have a look how perl is integrated in buildroot.
> Thanks.

I (with the help of a colleague) manage to package every ejabberd
dependency separately. We also had to package rebar because some
erlang packages rely on it but do not provide it. Therefore, if an
erlang package includes a rebar script, we use it. Otherwise, we add a
dependency on host-erlang-rebar and we use this one instead.
To simplify the task (12 erlang packages), we created a pkg-rebar.mk
file that provides {host-}rebar-package, similar to pkg-autotools.mk.
In doing so, we had to factorize the hooks in pkg-autotools.mk.

I guess the minor modifications of pkg-autotools.mk should be pushed
in a separate patch.
Then, should I push the rest of my commits as a big new revision of
this patch, or should I push each erlang package as a separate patch ?

-- 
Johan

[Buildroot] [PATCH v3] ejabberd: new package

[Thomas Petazzoni]

Dear Johan Oudinet,

On Mon, 27 Oct 2014 15:42:48 +0100, Johan Oudinet wrote:

> I (with the help of a colleague) manage to package every ejabberd
> dependency separately. We also had to package rebar because some
> erlang packages rely on it but do not provide it. Therefore, if an
> erlang package includes a rebar script, we use it. Otherwise, we add a
> dependency on host-erlang-rebar and we use this one instead.
> To simplify the task (12 erlang packages), we created a pkg-rebar.mk
> file that provides {host-}rebar-package, similar to pkg-autotools.mk.
> In doing so, we had to factorize the hooks in pkg-autotools.mk.
> 
> I guess the minor modifications of pkg-autotools.mk should be pushed
> in a separate patch.
> Then, should I push the rest of my commits as a big new revision of
> this patch, or should I push each erlang package as a separate patch ?

Each should be a separate patch. Basically, you should send a patch
series, which contains separate patches for the various functionalities
(new package infrastructure, changes to existing package
infrastructure, new packages, etc.). Do not forget to document what you
are doing in the commit logs, especially for the modification to
existing package infrastructures and the new package infra.

Thanks,

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