While my cute little arm-boards are compiling at a speeds to get nostalgic, had not much better to do that have a look at SOGo. (oke: frustrated me it did not build)
Fiddelt with the spec files from Jalie. The odd thing is: there was a build dependency missing:
gnustep-base. I can’t understand how they (including inverse-inc/sogo) build it without this.
I don’t know what stacks Jalie used, this is built without patches from SOGo github sources:
And we all know we need a maintainer of the nethforge-sogo. And I don’t qualyfi in my own definition of a maintainer: he/she should be a regular (power) user of the application. I’m not
However I know the nethsever-sogo application quite well, and have just enough understanding of the e-smith configuration layer. But Apache not so well, all web thingy thingy’s not so well. (i more a hardware kind of guy).
I’m willing to give it a try, but need help with this.
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.
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.
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!
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
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
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