Bug 498194 - Review Request: zarafa - Zarafa Outlook Sharing and Open Source Collaboration
Review Request: zarafa - Zarafa Outlook Sharing and Open Source Collaboration
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Jeroen van Meeuwen
Fedora Extras Quality Assurance
:
Depends On: 498688 498837 521352 530824
Blocks: 498195 498197
  Show dependency treegraph
 
Reported: 2009-04-29 08:22 EDT by Robert Scheck
Modified: 2010-08-09 21:57 EDT (History)
15 users (show)

See Also:
Fixed In Version: zarafa-6.30.10-2.el5
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-02-26 06:49:07 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
vanmeeuwen+fedora: fedora‑review+
tibbs: fedora‑cvs+


Attachments (Terms of Use)

  None (edit)
Description Robert Scheck 2009-04-29 08:22:14 EDT
Spec URL: [Will come very soon]
SRPM URL: [Will come very soon]
Description:
Zarafa Outlook Sharing is a Microsoft Exchange replacement. The Open Source
Collaboration provides an integration with your existing Linux mail server,
native mobile phone support by ActiveSync compatiblity and a webaccess with
'Look & Feel' similar to Outlook using Ajax. Including an IMAP4 and a POP3
gateway as well as an iCal/CalDAV gateway, Zarafa can combine the usability
with the stability and flexibility of a Linux server.

The proven Zarafa groupware solution is using MAPI objects, provides a MAPI
client library as well as programming interfaces for C++, PHP and Perl. The
other Zarafa related packages need to be installed to gain all the features
and benefits of Zarafa Outlook Sharing and Open Source Collaboration.


I'll add the spec file, once I clarified some library dependency issues with
Jeroen or so. SRPM shipping is for now a legal problem as I'm testing with an
non-official release candidate, nevertheless, there are still some licensing 
issues with Zarafa, Tom is investigating into.
Comment 1 Robert Scheck 2009-05-10 19:17:02 EDT
Spec URL: http://labs.linuxnetz.de/bugzilla/zarafa.spec

If you currently want to test this package, you need to be an approved Zarafa 
beta tester. Needed patches for Zarafa are included in the *.nosrc.rpm package.
Note, that 6.30.0 hasn't been released and I'm updating the snapshot whenever
a new beta preview gets available.
Comment 2 Robert Scheck 2009-06-13 17:42:45 EDT
I need some help because of a undefined symbol issue in Fedora 11 and newer:
https://www.redhat.com/archives/fedora-devel-list/2009-June/msg00999.html
Comment 3 Axel Thimm 2009-10-24 02:39:33 EDT
There seem to be official open source tarballs available versioned 6.30.4.
Comment 4 Robert Scheck 2009-10-24 07:40:40 EDT
It doesn't absolutely matter what version Zarafa is currently at, as long as
the legal blocker still exists. Fedora Legal is either paranoid or super-duper
careful and once the trademark issue with Zarafa is not solved, there will be
nothing new in this review request - given that I'm waiting for some upstream
inclusions of my patches to hopefully ship a vanilla Zarafa (maybe 6.30.6?).
Comment 5 Axel Thimm 2009-10-24 10:56:36 EDT
(In reply to comment #0)
> SRPM shipping is for now a legal problem as I'm testing with an
> non-official release candidate, nevertheless, there are still some licensing 
> issues with Zarafa, Tom is investigating into.  

(In reply to comment #4)
> It doesn't absolutely matter what version Zarafa is currently at, as long as
> the legal blocker still exists. Fedora Legal is either paranoid or super-duper
> careful and once the trademark issue with Zarafa is not solved, there will be
> nothing new in this review request - given that I'm waiting for some upstream
> inclusions of my patches to hopefully ship a vanilla Zarafa (maybe 6.30.6?).  

Sorry, I read that the legal issues were due to using non-official sources and that the license issue was being looked at half a year ago and now I see that zarafa is AGPL, which is a fine license.

AFAIU any trademark issues are a different thing (and there is no discussion of them in the bugzilla or even a legal block on this ticket, so how could one know that there are any such issue?).

Anyway according to

    http://www.zarafa.com/content/copyright-trademark

if you were to import w/o any patches you may use the trademark. If you want to have patches in the package (which you will), then the URL above says

    If you want to propagate modified versions  of the Program under the name
    "Zarafa" or "Zarafa Server", you may do so if you have a written permission
    by Zarafa (to acquire a permission please contact Zarafa at 
    trademark@zarafa.com). 

I'll send out a mail to this address and Cc you. I don't think Zarafa will deny this request. And I don't think Fedora legal can do anything either, there is nothing to decide, you either get the permission, or not. I think this is the same issue like Mozilla Firefox.
Comment 6 Robert Scheck 2009-10-24 11:12:46 EDT
(In reply to comment #5)
> I'll send out a mail to this address and Cc you. I don't think Zarafa will deny
> this request. And I don't think Fedora legal can do anything either, there is
> nothing to decide, you either get the permission, or not. I think this is the
> same issue like Mozilla Firefox.  

As already written, you've unfortunately created a duplicate request.

Up-to-date situation is: Zarafa is very positive and enthusiastic to have
Zarafa in upstream distributions like Fedora, so it's no problem. We are 
currently just and only waiting for the lawyers to get it legally fixed &
solved.
Comment 7 Axel Thimm 2009-10-24 11:23:05 EDT
OK, so we could move on reviewing the package in expectation of the trademark issue to have been solved by the end of the review? I would volunteer to review, but it would be nice to use a non-rc version like 6.30.4. I did read that you have some patches waiting to be merged upstream, but that shouldn't stop us from reviewing now - you will always find something to improve with patches ;)
Comment 9 Jeroen van Meeuwen 2009-10-25 08:02:21 EDT
Just a few initial remarks;

* Please include the following conditional BuildRequires:

%if 0%{?fedora} >= 12
BuildRequires: libuuid-devel
%endif

Since uuid has been split into uuid and libuuid since Fedora 12.

* Koji build for Fedora 12 fails, see also https://koji.fedoraproject.org/koji/taskinfo?taskID=1766801 (or https://koji.fedoraproject.org/koji/getfile?taskID=1766805&name=build.log)

* Mock build for F-11 does succeed ;-)

* rpmlint shows us a couple of warnings and errors
Comment 10 Jeroen van Meeuwen 2009-10-25 08:25:32 EDT
* http://aur.archlinux.org/packages/zarafa-server/zarafa-server/php-5.3.0-changes.patch applies nicely and causes the F-12 build to succeed;
Comment 11 Dan Horák 2009-10-25 08:31:15 EDT
(In reply to comment #9)
> Just a few initial remarks;
> 
> * Please include the following conditional BuildRequires:
> 
> %if 0%{?fedora} >= 12
> BuildRequires: libuuid-devel
> %endif
> 
> Since uuid has been split into uuid and libuuid since Fedora 12.

uuid is completely different package, libuuid was split off e2fsprogs and moved into util-linux-ng as a subpackage, IIRC
Comment 12 Robert Scheck 2009-10-25 09:43:07 EDT
I'll add a build requirement %{_includedir}/uuid/uuid.h to avoid all these
conditionals making spec files unreadable. And a file dependency like this
only matters in the build system, but not for runtime/installation.

I've figured out another issue: For EPEL 5, bug #530824 is a issue. We either 
need a fix or a workaround here.
Comment 13 Jeroen van Meeuwen 2009-11-01 08:11:16 EST
Compiling with --enable-release toggles the -pedantic switch which makes the compilation process less prune to errors like these.

I've been talking to Zarafa about the following spec, which splits up several server/service components and libraries, and they seem to agree this would be the better approach for 6.40:

http://www.kanarip.com/custom/SPECS/zarafa.spec

Please let me know what you think.
Comment 14 Robert Scheck 2009-11-01 08:54:34 EST
Well, what exactly will Zarafa do for their own RPM package builds for the 6.40
release? Will they split up as same or won't they do? I feel very uncomfortable
to do these split-ups, if they don't do the same. And I still don't want to see 
this package similar over-engineered and unusable such as the current Fedora 
clamav package.
Comment 15 Axel Thimm 2009-11-01 14:02:36 EST
If there are sane use cases where users will really need only parts of the package then split the package there, but splitting for splitting's sake (e.g. like clamav) is not good.

Also relying on an external vendor's packaging style is also not sane - when we say that Fedora follows upstream we mean the source code, not the packaging practice. Of course the other way, e.g. persuading upstream packaging to lean on our package style is always fine. :)
Comment 16 Jeroen van Meeuwen 2009-11-01 19:58:53 EST
(In reply to comment #14)
> Well, what exactly will Zarafa do for their own RPM package builds for the 6.40
> release? Will they split up as same or won't they do? I feel very uncomfortable
> to do these split-ups, if they don't do the same. And I still don't want to see 
> this package similar over-engineered and unusable such as the current Fedora 
> clamav package.  

Zarafa's Steve Hardy seems to like the split-up for 6.40. I highly doubt they'll change their packaging of 6.30.

(In reply to comment #15)
> If there are sane use cases where users will really need only parts of the
> package then split the package there, but splitting for splitting's sake (e.g.
> like clamav) is not good.
> 

I agree with what you're saying here, but all of these are separate components to the Zarafa architecture, and can be installed on separate servers.

> Also relying on an external vendor's packaging style is also not sane - when we
> say that Fedora follows upstream we mean the source code, not the packaging
> practice. Of course the other way, e.g. persuading upstream packaging to lean
> on our package style is always fine. :)  

This is going upstream, yes ;-)
Comment 17 Axel Thimm 2009-11-08 16:02:17 EST
(In reply to comment #16)
> (In reply to comment #15)
> > If there are sane use cases where users will really need only parts of the
> > package then split the package there, but splitting for splitting's sake (e.g.
> > like clamav) is not good.
> 
> I agree with what you're saying here, but all of these are separate components
> to the Zarafa architecture, and can be installed on separate servers.

We need to think about whether it will be done that way, not whether it can be done. Even for the rare cases where an admin will be splitting out parts of the services he will probably not mind installing the bundle but using only part of it.

> > Also relying on an external vendor's packaging style is also not sane - when we
> > say that Fedora follows upstream we mean the source code, not the packaging
> > practice. Of course the other way, e.g. persuading upstream packaging to lean
> > on our package style is always fine. :)  
> 
> This is going upstream, yes ;-)  

Well, the argument above was "Upstream packaging is doing something not really Fedoraish, but since it's upstream let's adopt Fedora's package to do the same" which we should not do as we only follow upstream on the code level and hopefully know better how to package bits for Fedora.

So the decision on granularity of package should remain a distribution's choice, and if upstream has decided to package up differently, then how is this "going upstream"?
Comment 18 Jeroen van Meeuwen 2009-11-08 16:47:28 EST
(In reply to comment #17)
> (In reply to comment #16)
> > I agree with what you're saying here, but all of these are separate components
> > to the Zarafa architecture, and can be installed on separate servers.
> 
> We need to think about whether it will be done that way, not whether it can be
> done. Even for the rare cases where an admin will be splitting out parts of the
> services he will probably not mind installing the bundle but using only part of
> it.
> 

Well then have you got some arguments for or against what I've put in c#13? It makes no sense to me to go all philosophical on the issue. It's more efficient to address the facts, especially since -like I said- upstream likes the concept.

> > This is going upstream, yes ;-)  
> 
> Well, the argument above was "Upstream packaging is doing something not really
> Fedoraish, but since it's upstream let's adopt Fedora's package to do the same"
> which we should not do as we only follow upstream on the code level and
> hopefully know better how to package bits for Fedora.
> 
> So the decision on granularity of package should remain a distribution's
> choice, and if upstream has decided to package up differently, then how is this
> "going upstream"?  

This argument makes no sense to me.
Comment 19 Tom "spot" Callaway 2009-11-30 20:09:33 EST
FWIW, we are waiting to hear back from Till Jaeger regarding the trademark licensing details.
Comment 20 Jeroen van Meeuwen 2010-01-20 19:17:31 EST
Brian Joseph has accepted the new proposed license text and is going to release such in 6.30.10 (< Feb 1st) and 6.40 (beta or RC1)
Comment 21 Jeroen van Meeuwen 2010-02-04 05:13:11 EST
The technical issue of the undefined symbol has just been resolved.

An SRPM (with the necessary patch) can be found at http://www.kanarip.com/custom/custom-f12-kanarip.com/SRPMS/zarafa-6.30.10-2.fc12.src.rpm
Comment 22 Robert Scheck 2010-02-04 05:20:34 EST
I'll try to put my new packages into the review either over the weekend,
if FOSDEM allows me to spend some time or hopefully at least during the
next week.
Comment 23 Jeroen van Meeuwen 2010-02-06 04:55:04 EST
Tom, could you please verify and possibly lift the legal blocker based on the 6.30.10 version of the product, including the modified license text(s), along with the .spec file "statement", or advise us on the path forward?
Comment 24 Tom "spot" Callaway 2010-02-06 17:33:22 EST
License: should be "AGPLv3 with exceptions", but otherwise, everything looks good. Lifting FE-Legal.
Comment 26 Jeroen van Meeuwen 2010-02-07 06:07:09 EST
Worked with Robert during FOSDEM, I'm approving this package!

<o/ <o/ <o/
\o> \o> \o>

Thanks for all the great work!
Comment 27 Robert Scheck 2010-02-07 06:25:04 EST
Thank you all as well and thank you Jeroen for all your support and reviewing.


New Package CVS Request
=======================
Package Name: zarafa
Short Description: Zarafa Outlook Sharing and Open Source Collaboration
Owners: robert
Branches: EL-4 EL-5 F-11 F-12
InitialCC:
Comment 28 Kevin Fenzi 2010-02-07 16:20:47 EST
CVS done (by process-cvs-requests.py).
Comment 29 Fedora Update System 2010-02-08 10:15:39 EST
zarafa-6.30.10-1.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/zarafa-6.30.10-1.fc12
Comment 30 Fedora Update System 2010-02-08 10:15:42 EST
zarafa-6.30.10-1.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/zarafa-6.30.10-1.fc11
Comment 31 Fedora Update System 2010-02-08 10:16:51 EST
zarafa-6.30.10-1.el5 has been submitted as an update for Fedora EPEL 5.
http://admin.fedoraproject.org/updates/zarafa-6.30.10-1.el5
Comment 32 Pavel Lisý 2010-02-08 19:09:05 EST
How can I help to push it in repository? 

I want to test it (and make karma better) but there is many packages, can I install it through repository somehow?
Comment 33 Pavel Lisý 2010-02-09 01:56:56 EST
Sorry I was too quick. It is in testing repository this morning on my mirror.
I will try it and change karma status :-)
Comment 34 Fedora Update System 2010-02-25 15:15:15 EST
zarafa-6.30.10-2.el5 has been submitted as an update for Fedora EPEL 5.
http://admin.fedoraproject.org/updates/EL-5/FEDORA-EPEL-2010-2312
Comment 35 Fedora Update System 2010-02-25 15:18:44 EST
zarafa-6.30.10-2.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/F13/FEDORA-2010-2816
Comment 36 Fedora Update System 2010-02-26 03:08:09 EST
zarafa-6.30.10-2.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/F11/FEDORA-2010-2958
Comment 37 Fedora Update System 2010-02-26 03:09:08 EST
zarafa-6.30.10-2.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/F12/FEDORA-2010-2948
Comment 38 Fedora Update System 2010-02-26 06:48:43 EST
zarafa-6.30.10-2.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 39 Fedora Update System 2010-02-26 22:32:10 EST
zarafa-6.30.10-2.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 40 Fedora Update System 2010-02-26 22:47:46 EST
zarafa-6.30.10-2.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 41 Fedora Update System 2010-03-16 15:33:56 EDT
zarafa-6.30.10-2.el5 has been pushed to the Fedora EPEL 5 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 42 Robert Scheck 2010-08-09 17:47:43 EDT
As far as I can see, our pkgdb isn't able to update the short description, so
let's do it here:


Package Change Request
======================
Package Name: zarafa
Short Description: Open Source Edition of the Zarafa Collaboration Platform
Comment 43 Jason Tibbitts 2010-08-09 21:57:42 EDT
pkgdb is supposed to take the summary from the package itself.  Not sure why that's not happening, but it's being worked on.  I tried to change it manually and it looks like it took.

Note You need to log in before you can comment on or make changes to this bug.