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.

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,

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.

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.

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