Re: [Kolab-devel] current dev state

Christoph Erhardt <[email protected]> Thu, 08 Jun 2017 12:18:19 +0200

Newsgroups	gmane.comp.kde.devel.kolab
Message-ID	<10495006.frxxzDj3Nb__18492.6955648281$1496917131$gmane$org@delle>

Hi hede,

> What kind of headache? I haven't followed kolab recently.
php-kolab and php-kolabformat have changed the priority of their .ini files, 
but did not remove the respective old symlinks. For instance, now both 20-
kolab.ini (old) and 31-kolab.ini (new) are lying around, causing the logs to 
be spammed with "PHP Warning: Module already loaded".

In the irony package, the Apache configuration file got renamed from 
iRony.conf to irony.conf (accidentally?), causing a dangling symlink in 
"sites-enabled".

> Okay, right now I'm digging my way into the dependency hell. ;-)
> ... see my home:hede winterfell subproject
Oh, it looks like the two of us have been ploughing the same field! Perhaps 
it's a good idea if you take a look at my branch at https://obs.kolabsys.com/
project/show/home:sicherha:branches:Kolab:Winterfell so we don't accidentally 
do the same work twice.

> btw: erlang-ssl_verify_fun and erlang-ssl_verify_hostname are building with
> debian 9 if using rebar (2.6.4) from debian. But OBS prefers to use its own
> (older) rebar (2.6.1) - which fails. Is there a way to prioritise the
> package from debian even if there's a rebar package in the main winterfell
> repository?
I was able to solve that problem by adding a build dependency on erlang (which 
pulls in erlang-crypto).

> PS: guam itself is not the biggest problem. It needs only a few dependencies
> which are not already in debian. It's rebar3 which multiplies deps. Maybe
> there's a way to use rebar2 with guam 0.9? (with guam 0.8.3 it was the
> default to use rebar2 after all)
That's a valid point. I have to admit that I'm not really familiar with Erlang 
either, so I don't feel qualified to answer that question (without trying it 
out, that is).

If it were indeed possible to keep using the distro-provided rebar 2 for now 
(even though upstream says that version "is deprecated and will receive only 
bug fixes" [1]), that would reduce the packaging and maintenance effort for 
us. I think it's a good idea to stay as close to the distribution as possible 
and keep the number of extra packages low that we have to drag along.

Best regards,
Christoph

[1] https://github.com/rebar/rebar

_______________________________________________
devel mailing list
[email protected]
https://lists.kolab.org/mailman/listinfo/devel

signature.asc (application/pgp-signature, 819 B)