| Message ID | 1405686837-1418-1-git-send-email-johan.oudinet@gmail.com |
|---|---|
| State | Rejected |
| Headers | show |
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@busybox.net > http://lists.busybox.net/mailman/listinfo/buildroot
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@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, 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.
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
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, 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.
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@busybox.net > http://lists.busybox.net/mailman/listinfo/buildroot
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.
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, 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.
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.
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, 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, 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.
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
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.
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, 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. | > '------------------------------^-------^------------------^--------------------'
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. | > > '------------------------------^-------^------------------^--------------------'
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, 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, 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.
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.
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, 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.
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, 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, 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.
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 ?
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
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))
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