ejabebrd 13.10 was just released. It uses a new versioning scheme, but does not bring major changes [1]. From the announcement [2]: --- [...] It is also the first official stable release of ejabberd Community after ejabberd 2.1.13. [...] ejabberd 2.1.x support is discontinued. --- Reading the announcement, it seems as if the build process was changed and additional Erlang modules are required. [1] http://lists.jabber.ru/pipermail/ejabberd/2013-March/007974.html [2] http://www.ejabberd.im/ejabberd-13.10 Reproducible: Always
Also, new ejabberd compiled by "rebar" script, which depends only on erlang itself. Bad news: for optional features it pull modules from number of git repos in configure/compile time... I'm now trying to adjust ebuild for it.
(In reply to Vadim Efimov from comment #1) > I'm now trying to adjust ebuild for it. Have you had any success with this?
New version, 13.10 http://blog.process-one.net/ejabberd-community-13-12/ (In reply to Dennis Schridde from comment #2) > (In reply to Vadim Efimov from comment #1) > > I'm now trying to adjust ebuild for it. > > Have you had any success with this? More or less. I'll finish it in holidays, on first week of 2014. I have half writed ebuild, which have all depends, but I didn't figure out yet how to manage this additional repos.
Any news on this ?
ejabberd Community 14.05 released http://blog.process-one.net/ejabberd-community-14-05/
Is there any progress on this? Version 14.05 adds new configuration options to disable insecure SSL protocols and ciphers, so it would be good to have it in the portage tree.
I'm working on a -9999 ebuild just now, should be ready in a day or two. Only a couple of checks left to do. I'm not sure if we'll ever get the new ejabberd into stable though - given rebar fetches components from a repository, it wouldn't be possible to guarantee two builds are the same. I've been chatting with the ejabberd guys (mainly getting pointers for the 'new' way of doing things for writing the ebuild), and it's not even as if, for example, the 14.05 rebar will fetch a 14.05 snapshot of the repository for the components (which would seem the most sensible way to provide consistent builds). If any devs could comment on the guidelines for this, namely if it would be acceptable or not, then I could start work on a 14.05 ebuild to submit. NB This is my first 'real' ebuild - the rest I've made have been for personal use, but the ejabberd guys have been so helpful and friendly I thought I'd give it a go and help them out with a distro package.
(In reply to Steve from comment #7) > I'm not sure if we'll ever get the new ejabberd into stable though - given > rebar fetches components from a repository, it wouldn't be possible to > guarantee two builds are the same. I've been chatting with the ejabberd > guys (mainly getting pointers for the 'new' way of doing things for writing > the ebuild), and it's not even as if, for example, the 14.05 rebar will > fetch a 14.05 snapshot of the repository for the components (which would > seem the most sensible way to provide consistent builds). > > If any devs could comment on the guidelines for this, namely if it would be > acceptable or not, then I could start work on a 14.05 ebuild to submit. I've made ebuilds/tarballs for myself for the past few releases but never put them in the tree for the reason you state above. Have you explicitly asked upstream to pin 3rd party packages to specific versions for official releases of ejabberd? That would remove most of my hesitation to put it into the official tree since then we could make tarballs for ejabberd including all the deps at versions upstream expects (really ejabberd upstream should be doing this though otherwise it seems 3rd party libs could randomly break for users and they'll get to triage related bugs).
(In reply to Tim Harder from comment #8) > Have you explicitly asked upstream to pin 3rd party packages to specific > versions for official releases of ejabberd? That would remove most of my > hesitation to put it into the official tree since then we could make > tarballs for ejabberd including all the deps at versions upstream expects > (really ejabberd upstream should be doing this though otherwise it seems 3rd > party libs could randomly break for users and they'll get to triage related > bugs). Not explicitly, but the general feeling is it wouldn't happen. Another work-around, which I know isn't ideal, is to make our own snapshots of these repositories and host them somewhere. But that would then also mean patching the rebar script to point to our repositories. Other than that, if we could get an 'official' -9999 ebuild, even if masked, in portage, then at least we'd have something.
I just added an issue for ejabberd on this: https://github.com/processone/ejabberd/issues/233
I've finished the -9999 ebuild. Tested it as much as I can think of in an empty chroot, didn't encounter any problems. If you do, let me know on github. https://github.com/sdfg2/sdfg-overlay The response from the ejabberd guys is that they are aware of the issue, so hopefully it will get resolved. It sounds like other distro maintainers might have said something too :-)
Hi! Thanks for your work! I've installed ejabberd using your ebuild. I noticed that you used USE flag "pgsql", in Gentoo more common is USE flag "postgres". Next I tried to create tables in postgres, I couldn't find any files under /usr/share/ejabberd/. I have to do unpack phase in ebuild to get sql files from /var/tmp/portage/net-im/ejabberd-9999/work/ejabberd-9999/sql. I suggest to add those scripts in src_install(). Inside ejabberd.yml is wrong path: captcha_cmd: /usr/lib64/erlang/lib/ejabberd-9999/priv/bin/captcha.sha" should be: captcha_cmd: /usr/lib64/erlang/lib/ejabberd-9999/priv/bin/captcha.sh"
Created attachment 385730 [details, diff] Specify desired commits of dependencies
The above patch specifies the commits to use for each dependency in the rebar configuration. You could apply that to get a reproducible build. The source tarball of the next ejabberd release will probably have that, too (I'm a contributor to the upstream project).
Created attachment 385964 [details, diff] ejabberd-9999-no-docs.patch Hi, thanks for ebuild! The 'dev-tex/hevea' package (dependency for generating ejabberd docs) pull lots of other packages, which in many cases isn’t required on server. I attach patch for ebuild, that remove that dependency (just works for me), but I think 'hevea' dependency possible to make optional via 'doc' USE flag and latter solution would be better.
Note for fresh intallation from that ebuild. You need set correct shell for user 'jabber' (/bin/bash in my case), because 'ejabberdctl' script fails in other cases. Now ebuild don’t set it automatically. Related commit: https://github.com/processone/ejabberd/commit/3e232952ea587a4d4c42e37f1a3dbdc3c5750b41 Also 'ejabberdctl' do some manipulation with it’s home directory, so I change it from '/dev/null' (no home dir) to '/var/spool/jabber'. Maybe it isn’t correct, but works for me.
Ping? Any ETA for the Bump. I just got some need for that, too;)
On https://www.ejabberd.im/, version 2.1.13 is marked "obsolete" :-(
We need a fix for this, and the easiest way to go would be to pin the rebar script upstream to fixed versions, is that right? So either we convince them to merge the patch proposed on this bug (e.g. someone could create a pull request for it it make it even easier for them), or we find a couple of volunteers who maintain a fork of their github with that one patch added on top at all times, and we base the ebuild off of that version? Would that work?
As I said above, the next upstream release tarball will probably specify fixed versions of the dependencies (though the Git repository won't). I suggested the patch for Gentoo in case you don't want to wait for that, or in case you don't want to build from the tarball for some reason.
okay, that wasn't too clear to me. In that case I am directing Marc's question at you and ask "is there an ETA for an upstream tarball that has this patch"? If we want this version, we should just take the upstream tarball and apply the patch you provided as an epatch then. Is there another reason anyone is aware of why we cannot just update the existing ebuild with a new version number and this one patch? Otherwise I suggest to try that, I will probably play around with it on one of the coming weekends.
The 14.12 tarball is now available, and it uses fixed dependency versions: https://www.process-one.net/en/ejabberd/downloads/ In case you prefer building from Git, the repository now includes a tools/set-dep-versions script which can be used to auto-create such a patch against the rebar.config.script file. Hope this helps.
Created attachment 392110 [details] work-in-progress ebuild Hi again! Note that this ebuild is incomplete: - mysql support is most certainly broken - other authentication backends than postgresql are untested - some comments in the ebuild need to be updated - there needs to be information about the following changes: - user jabber needs a valid home dir and a working shell - default directories for spool and logs needs to be configured, as the hardcoded defaults do not exist on gentoo other than that, this version is now running on my setup. Thanks also to Holger for telling us about the new tarball and helping me find the correct thing to download, which made updating the ebuild a lot easier.
*** Bug 537060 has been marked as a duplicate of this bug. ***
This old ebuild is holding back an update to erlang, which is holding back my ability to properly secure rabbitmq (won't disable insecure ssl versions). Thanks for your efforts!
ejabberd Community 15.02 Here is the detailed changelog: add Elixir support, allows to write plugins in Elixir New command to reload configuration without restart Support old style erlang expressions in YAML configuration Improved captcha listener parsing when protocol not specified Fix upgrade of old unbinarized pubsub table from 2.1 Minor updates in the documentation Other bugfixes https://blog.process-one.net/ejabberd-community-15-02/
HARDER, TIM! TIM THE EBUILD HARDER!! HARDER! Damn, its an awesome name you got. If I had that name I'd consider a porn star career. On a side note, srsly, 15 months to bump ejabberd? What the hell?
From what I gather by reading the conversatione here, the roadbump that prevented the bump is solved upstreams and this seems to have been forgotten. Can anyone confirm if there is still upstreams issues that needs to be fixed, or if this is just a case of roll-up-the-sleeves-and-get-it-done?
I can confirm that this is just "roll-up-the-sleeves-and-get-it-done". My work-in-progress ebuild has been in use on my server since christmas with no problems on my end, but it only covers my specific setup. E.g. I only included support for postgresql, not for mysql as a database backend in the ebuild. Unfortunately I will not have time to deal with this in the near future, but if this is still around once I find some time I probably will patch it up to be feature-complete. Of course I would not object to someone else doing it instead of me.
I look at build process of 15.02 and it still pull from git repos during compile. Good thing - they hardcode exact commits to rebar script. So - it anyway live pakage now. We can package downloaded modules and patch out git pull during compile by palacing ".got" file into "deps" folder and unpack needed modules to it.
ejabberd 15.03 released https://blog.process-one.net/ejabberd-15-03/ changelog: Add support for WebSocket Flexible session management with multiple backends: Mnesia/SQL/Redis or custom backend for session manager Security improvement with SCRAM based password encryption in SQL authentication backends. Package management for ejabberd contributed modules. Improved Elixir experience Automatic clustering scripts Added missing index on database Important updates on the documentation, with the launch of a new documentation site: docs.ejabberd.im Several other bugfixes
my ejabberd hasn't been updated since 2013, i start to get nervous about having such an old beast on my server :-(
(In reply to Thomas Capricelli from comment #32) > my ejabberd hasn't been updated since 2013, i start to get nervous about > having such an old beast on my server :-( I also see this point. The maintainer SHOULD add the newer versions to the portage even if it wouldn't become stable. IMO, solving security issues like broken ciphers and protocols are more important than stability.
Tim, how is the thing going?
Sorry for the delay, 15.03 now added to the tree. It's still a semi-manual process to generate a proper tarball for Gentoo. It would be really nice if upstream also generated a tarball with all the deps prefetched in it now that they add hashes/tags for version deps... but we can't have everything. ;) I'm sure there are probably a few bugs in the ebuild since it's been so long, please file new bugs if you run into anything. Also, note I'm not the primary maintainer anymore (mostly because I rarely have time and/or interest to write many ebuilds these days) but I felt I should kick this out the door before dropping it on someone else.
