go and ask when you have an issue → ok, I go OUT 
2 Likes
You’re the right guy! You did a great job with sogo.conf Love it
Please do it @stephdl will support you! 
Everything you need, just ask!
1 Like
The SOGo packages and nethserver-sogo need some update’s, I commit to that
Going to search the wiki on “how to nethforge” if you know a short-lane, @alefattorini happy to hear it
Thanx! And think you do enough as it is. (after cleaning it up i’ll ask you for a first review)
3 Likes
For the daredevils among us SOGo 3.2.0 . !!! ONLY FOR TESTING !!!
Make a yum repository file:
[markvnl-SOGo]
name=Copr repo for SOGo owned by markvnl
baseurl=https://copr-be.cloud.fedoraproject.org/results/markvnl/SOGo/epel-7-$basearch/
type=rpm-md
skip_if_unavailable=True
gpgcheck=1
gpgkey=https://copr-be.cloud.fedoraproject.org/results/markvnl/SOGo/pubkey.gpg
repo_gpgcheck=0
enabled=1
enabled_metadata=1
yum makecache
yum update
Let me know if it works[quote=“mark_nl, post:39, topic:3957”]
Is this any good?; Who wants to test?
EDIT: Spec Files https://github.com/markVnl/SOGo-spec
[/quote]
8 Likes
I’m impressed!!
Really really good job! 
(PS: In the meanwhile I saw that Jalie updated its own repos 
EDIT: I’m wrong! I was looking to the COPRS of Mark 
)
5 Likes
What? Can’t believe it!
Can I add you the NethServer SOGo maintainer title? 
You deserve one of my preferred pics!
3 Likes
Where/how do you request access to the nethforg?
And how does it work?
I like to get my vanilla sogo 3.20 builds and srpm’s in testing;
for me they work like a charm.
@stephdl , could you have a brief look at the spec files?
They build like a charm, there is nothing wrong with them;
but i’d like your opinion and maybe learn something.
1 Like
Nothing much to add as I said I’m not really a rpm guru, however I could advice on two things
the %changelog could be written just after the %description (to avoid to scroll down when you build a new rpm)
What about the first builder, did you try to contact him and ask an update or collaborate with him. Sometime two brains are better than just one. I have not compared with the srpm of Inverse but I bet it is not the same and he did some changes to make it workable.
1 Like
Just send your ssh public key Davide with a private message and and we will give you the access (and the instructions, probably we forgot to publish them).
When a package has passed the QA, Stephane (or someone from the dev team), will move the rpm into the forge updates!
Thx a lot!
He didn’t leave any contact information, but ill try to find it again.
Inverse must be using some build macro’s or at least set some %… variables. Without them its not possible to rebuild a sprm they provide. So I diffed “originals” with others had done refactored the “originals” to build against epel 7 in mock. I truly believe inverse does not build in / against clean sources.
BTW the “originals” are in a separate branch; so everybody can “diff” them
1 Like
Hi there,
I need some reflection on the insane versioning of sope (dependency of sogo)
My curl pit is get the new packages to update with sane versioning
here we go: In original versioning of sope we have
sope_version 3.2.0 (=version of courses and in sync with sogo)
sope_major_version 4
sope_minor_version 9
sope_release JJJJMMDD_1664
sope_buildcount 1
Resulting in this:
=============================================================================================================================================================================================================================================
Package Arch Version Repository Size
=============================================================================================================================================================================================================================================
Updating:
sope49-appserver x86_64 4.9-20161021_1664.ns7.1 nethlocal 920 k
Looking at specs of others, they have the same thoughts about the sanaty of versioning and just gave it the source version (=sope_version 3.2.0).
=====================================================================================================================
Package Arch Version Repository Size
=====================================================================================================================
Updating:
sope49-cards x86_64 3.2.0-2.ns7 nethlocal 180 k
witch of cause does not update on our installs…
So i though someting like this:
============================================================================`
sope49-appserver-devel.x86_64 4.9-3.2.0.2.ns7 nethlocal`
============================================================================
It does not update…
the only way i get it working is keeping that bogus release tag (sope_release JJJJMMDD_1664)
all ideas are welcome 
maybe I didn’t understand your issue, but you must follow the sope rpm version of sogo, even if they made a horrible bug. It is like Centos and RHEL, Centos is a bug to bug clone.
I know that the sope version is not easily upgradable with sogo2 and sogo3, the reinstallation is a mandatory → Sogo - SME Server
it is not a real issue, in the NS repository some how there is a Sope package with a “nightly” release tag (JJJJMMDD_1664). I hoped there was a “obsoletes” ( as I am used of Arch Linux) that no matter what replaces a package.
The only way can think of is ask users to downgrade for a update 
Or keep on going with “nightly” release tags.
And inverse should version sope right, there are binary’s in there with version 4.9.231. This is not reflected on the versioning of the sope package, its 4.9.
EDIT BTW, sogo 3.2.0 runs just fine on the old Sope so we could not be worried at all 
1 Like
I recall some fun bugs when the version is not the good one expected
this funny version was already used at the time their repository was open, see sogo3 is released
an upgrade from sogo2 to sogo3 didn’t update sope.
1 Like
But nothing stops re-installing the “old” package.
we don’t have this problem, you can always downgrade. You get the package released in the netforge.
the “problem” is in the netforrge older packages with a “newer” release tag.
Edit all nightly releases should be corrected by a downgrade. Even if they are from 1999, in a nutshell that’s the issue.