Bug 498194

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.

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

There seem to be official open source tarballs available versioned 6.30.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?).

(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). 

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.

(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.

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 ;)

Spec URL: http://labs.linuxnetz.de/bugzilla/zarafa.spec
SRPM URL: http://labs.linuxnetz.de/bugzilla/zarafa-6.30.4-1.svn17264.src.rpm

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

* 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;

(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

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.

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.

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.

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. :)

(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 ;-)

(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"?

(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.

FWIW, we are waiting to hear back from Till Jaeger regarding the trademark licensing details.

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)

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

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.

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?

License: should be "AGPLv3 with exceptions", but otherwise, everything looks good. Lifting FE-Legal.

Spec URL: http://labs.linuxnetz.de/bugzilla/zarafa.spec
SRPM URL: http://labs.linuxnetz.de/bugzilla/zarafa-6.30.10-1.src.rpm

Worked with Robert during FOSDEM, I'm approving this package!

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

Thanks for all the great work!

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:

CVS done (by process-cvs-requests.py).

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

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

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

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?

Sorry I was too quick. It is in testing repository this morning on my mirror.
I will try it and change karma status :-)

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

zarafa-6.30.10-2.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/F13/FEDORA-2010-2816

zarafa-6.30.10-2.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/F11/FEDORA-2010-2958

zarafa-6.30.10-2.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/F12/FEDORA-2010-2948

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.

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.

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.

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.

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

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.