Files are not accessible.

Sorry, my server has a configuration problem, you can find the files here:


Spec URL: https://fedoraproject.org/wiki/File:Openerp-client.spec
SRPM URL: https://fedoraproject.org/wiki/File:Openerp-client-5.0.14-1.fc13.src.rpm

There is a problem that must be resolved with upstream before we can continue - the files in bin/SpiffGtkWidgets are licensed as "GPLv2 only" making them incompatible with the rest of the project that is GPLv3+ (https://fedoraproject.org/wiki/Licensing#GPL_Compatibility_Matrix)

Other issues found during my review are
- the uploaded file has the first character in upper-case, but the content of the srpm itself is fine, should be all lower-case
- cli_dir macro is defined but not used anywhere, please remove
- I'd personally use %{name} macro instead of the openerp-client string inside the %build/%install/%files sections
- build in mock for rawhide and F-14 fails with
...
+ /usr/bin/python setup.py build
Error: Can not find dsextras or gtk.dsextras

- the --vendor option shouldn't be used in new packages (https://fedoraproject.org/wiki/Packaging/Guidelines#desktop-file-install_usage)
- locales are not handled correctly, see https://fedoraproject.org/wiki/Packaging/Guidelines#Handling_Locale_Files

(In reply to comment #3)
> There is a problem that must be resolved with upstream before we can continue -
> the files in bin/SpiffGtkWidgets are licensed as "GPLv2 only" making them
> incompatible with the rest of the project that is GPLv3+
> (https://fedoraproject.org/wiki/Licensing#GPL_Compatibility_Matrix)

And the same problem exists also in the upcoming 6.0 with the exception that AGPLv3+ is used for the whole project.

(In reply to comment #3)
> There is a problem that must be resolved with upstream before we can continue -
> the files in bin/SpiffGtkWidgets are licensed as "GPLv2 only" making them
> incompatible with the rest of the project that is GPLv3+
> (https://fedoraproject.org/wiki/Licensing#GPL_Compatibility_Matrix)

This problem seems to be solved now because openerp is released under AGPLv3

> Other issues found during my review are
> - the uploaded file has the first character in upper-case, but the content of
> the srpm itself is fine, should be all lower-case
> - cli_dir macro is defined but not used anywhere, please remove
> - I'd personally use %{name} macro instead of the openerp-client string inside
> the %build/%install/%files sections
> - build in mock for rawhide and F-14 fails with
> ...
> + /usr/bin/python setup.py build
> Error: Can not find dsextras or gtk.dsextras
> 
> - the --vendor option shouldn't be used in new packages
> (https://fedoraproject.org/wiki/Packaging/Guidelines#desktop-file-install_usage)
> - locales are not handled correctly, see
> https://fedoraproject.org/wiki/Packaging/Guidelines#Handling_Locale_Files

that  problems should be solved now in the last version that you can find here:

Spec URL: http://vezza2.dyndns.org/openerp-client.spec
SRPM URL: http://vezza2.dyndns.org/openerp-client-5.0.14-1.fc14.src.rpm

(In reply to comment #5)
> (In reply to comment #3)
> > There is a problem that must be resolved with upstream before we can continue -
> > the files in bin/SpiffGtkWidgets are licensed as "GPLv2 only" making them
> > incompatible with the rest of the project that is GPLv3+
> > (https://fedoraproject.org/wiki/Licensing#GPL_Compatibility_Matrix)
> 
> This problem seems to be solved now because openerp is released under AGPLv3

I don't think you can mix AGPLv3+ and GPLv2 files in a project, but I will send a question to the fedora legal list.

we have a real problem, see http://lists.fedoraproject.org/pipermail/legal/2010-October/001420.html

After some investigation I found a guy that helped me on this problem...

http://code.google.com/p/spiff-gtkwidgets/issues/detail?id=9

so at the moment we have to wait if something will change...

Guys,

I'm an OpenERP integrator and contributor.
I understand the issue about the license mix and hope they will sort this out soon.

But:
If I understand correctly, the issue is only about the GTK client.
Well, why don't you package the server and the web-client who don't have those issues (to my knowledge) and hold only the client?

You have to know that the GTK client will probably be used from others PC's that are more likely to run Windows than Fedora (client-side) and in any case, the GTK client is totally optional, once you installed the "web-client" component, OpenERP can be accessed fully in your browser. So why not package the server first?

Finally, I tel you: beware of what is said about OpenERP: there is a high discrepancy between the marketing and the reality unfortunately (read about experience third parties integration in forums and list to know the truth; no well known open source ERP has a better story either to my knowledge unfortunately), so my point is:
don't bother to package the 5.0 version it's useless, only usable by alien integrators managing to stabilize it , not stable and usable directly in production.
So you'll need to package version 6.x instead. Well, not so easy either given it's still developed, may be you'll be able to package the coming RC2 and coming releases (6.x are likely to be more professional cause it's finally tested systematically).
Given the relative instability of the whole (though improving fortunately), distro packages of OpenERP will only be usable if they are updated often (like every month), and if it's easy for and advanced users to apply bzr patches that come from Launchpad (indeed the issue, is that it's very hard to find a version with no bug or no regression, you always has to fix bugs for your use case to make it work). All installed I've seen of OpenERP where always made from source using bzr and only worked if great professionals where supporting it.

All right, hope this helps.

It seems to me that in the development version Openerp-*-6.0-rc2 the licence problem has been solved, at the moment I'm not able to package it so I hope that someone will look at the integration of this software... thanks

*** This bug has been marked as a duplicate of bug 693425 ***