Re: Questions...

2016-04-14 Thread Adrian Reber
On Wed, Apr 13, 2016 at 09:19:45AM -0700, John Oliver wrote:
> 1) Is this project the 'jabberd' that's available in EPEL?

I can answer that one. jabberd in EPEL is jabberd2. As it is EPEL it
will not see as many updates as the upstream package

Adrian




Re: Questions...

2016-04-14 Thread Adrian Reber
On Thu, Apr 14, 2016 at 10:49:30AM +0200, Matěj Cepl wrote:
> On 2016-04-14, 06:27 GMT, Adrian Reber wrote:
> > On Wed, Apr 13, 2016 at 09:19:45AM -0700, John Oliver wrote:
> >> 1) Is this project the 'jabberd' that's available in EPEL?
> >
> > I can answer that one. jabberd in EPEL is jabberd2. As it is EPEL it
> > will not see as many updates as the upstream package
> 
> I agree that I would keep EPEL-6 (or even EPEL-5) untouched just 
> with possible security patches, but it seems to me that rebase 
> in EPEL-7 would not be the worst idea. What do you think? I am 
> willing to help with patching.
> 
> Do we know what is the upgrade story? Does the latest jabberd2 
> just takes over the original configuration?

In the configuration I am running jabberd2 on Fedora I did not have many
(maybe any) upgrading the last few versions. EPEL-7 would be an upgrade
from 2.3.2 to 2.3.6. It probably depends on the installation and which
backends are used if the upgrade. Looking at

 https://github.com/jabberd2/jabberd2/blob/master/NEWS

it seems upgrading from 2.3.4 to 2.3.5 can require database changes. Not
sure how to handle this. But we can try.

Adrian




Re: Questions...

2016-04-14 Thread Matěj Cepl
On 2016-04-14, 06:27 GMT, Adrian Reber wrote:
> On Wed, Apr 13, 2016 at 09:19:45AM -0700, John Oliver wrote:
>> 1) Is this project the 'jabberd' that's available in EPEL?
>
> I can answer that one. jabberd in EPEL is jabberd2. As it is EPEL it
> will not see as many updates as the upstream package

I agree that I would keep EPEL-6 (or even EPEL-5) untouched just 
with possible security patches, but it seems to me that rebase 
in EPEL-7 would not be the worst idea. What do you think? I am 
willing to help with patching.

Do we know what is the upgrade story? Does the latest jabberd2 
just takes over the original configuration?

Best,

Matěj

-- 
https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz
GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC
 
SCSI is *not* magic. There are *fundamental* *technical*
reasons why you have to sacrifice a young goat to your SCSI
chain every now and then.
-- John F. Woods





Re: Questions...

2016-04-14 Thread Adrian Reber
On Thu, Apr 14, 2016 at 04:19:06PM +0200, Matěj Cepl wrote:
> On 2016-04-14, 10:26 GMT, Adrian Reber wrote:
> > In the configuration I am running jabberd2 on Fedora I did not  
> > have many (maybe any) upgrading the last few versions. EPEL-7 
> > would be an upgrade from 2.3.2 to 2.3.6. It probably depends 
> > on the installation and which backends are used if the 
> > upgrade. Looking at 
> >
> >  https://github.com/jabberd2/jabberd2/blob/master/NEWS
> >
> > it seems upgrading from 2.3.4 to 2.3.5 can require database  
> > changes. Not sure how to handle this. But we can try. 
> 
> # mod_verify requires CREATE TABLE "verify" in DB. Make sure 
> # you created it before enabling the module in sm.xml.
> 
> However, the mod_verify is new in 2.3.5, so we don't have to 
> care about its migration, right? Or what am I missing?

Ah, now that you say so. I never read it that way. But true.

Then it is probably not more than a 'git merge master' to get the latest
jabberd2 on EPEL-7. If you want you can update it for EPEL-7.

Adrian