incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jürgen Schmidt <jogischm...@googlemail.com>
Subject Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)
Date Fri, 01 Jun 2012 10:09:57 GMT
Hi,

sorry for top posting but I followed Ross advice and will give a
concrete example.

Hunspell -> MPL + LGPL

- we use currently version 1.2.9 and compile the source in our build env
on demand when the correct configure switch is used

- we apply 4 or in case of mingw 5 patch files (depends on the mechanism
that is used in our build env generally for this kind of things)

3 of these patch files contains minor changes used/necessary for our
build env.

For example hunspell-solaris.patch:
###
--- misc/hunspell-1.2.9.orig/src/tools/hunspell.cxx     2010-02-27
23:42:05.000000000 +0000
+++ misc/build/hunspell-1.2.9/src/tools/hunspell.cxx    2010-02-27
23:43:02.000000000 +0000
@@ -10,6 +10,9 @@
 #include "hunspell.hxx"
 #include "csutil.hxx"

+// switch off iconv support for tests (fixing Solaris problems)
+#undef HAVE_ICONV
+
 #ifndef HUNSPELL_EXTRA
 #define suggest_auto suggest
 #endif
###

One patch apply a back port patch for an important issue that is fixed
in a newer version. Don't ask me why we haven't upgraded the version
already. But that is as I mentioned before on our plan.

hunspell-stackmash.patch
###
--- misc/hunspell-1.2.9/src/hunspell/hunspell.cxx       2010-03-04
10:25:06.000000000 +0000
+++ misc/build/hunspell-1.2.9/src/hunspell/hunspell.cxx 2010-03-04
10:25:38.000000000 +0000
@@ -1665,7 +1665,7 @@
   if (!q2) return 0; // bad XML input
   if (check_xml_par(q, "type=", "analyze")) {
       int n = 0, s = 0;
-      if (get_xml_par(cw, strchr(q2, '>'), MAXWORDUTF8LEN)) n =
analyze(slst, cw);
+      if (get_xml_par(cw, strchr(q2, '>'), MAXWORDUTF8LEN - 1)) n =
analyze(slst, cw);
       if (n == 0) return 0;
       // convert the result to <code><a>ana1</a><a>ana2</a></code>
format
       for (int i = 0; i < n; i++) s+= strlen((*slst)[i]);
@@ -1686,13 +1686,13 @@
       (*slst)[0] = r;
       return 1;
   } else if (check_xml_par(q, "type=", "stem")) {
-      if (get_xml_par(cw, strchr(q2, '>'), MAXWORDUTF8LEN)) return
stem(slst, cw);
+      if (get_xml_par(cw, strchr(q2, '>'), MAXWORDUTF8LEN - 1)) return
stem(slst, cw);
   } else if (check_xml_par(q, "type=", "generate")) {
-      int n = get_xml_par(cw, strchr(q2, '>'), MAXWORDUTF8LEN);
+      int n = get_xml_par(cw, strchr(q2, '>'), MAXWORDUTF8LEN - 1);
       if (n == 0) return 0;
       char * q3 = strstr(q2 + 1, "<word");
       if (q3) {
-        if (get_xml_par(cw2, strchr(q3, '>'), MAXWORDUTF8LEN)) {
+        if (get_xml_par(cw2, strchr(q3, '>'), MAXWORDUTF8LEN - 1)) {
             return generate(slst, cw, cw2);
         }
       } else {
###

This fix is fixed upstream in version 1.2.11, see
http://hunspell.cvs.sourceforge.net/viewvc/hunspell/hunspell/src/hunspell/hunspell.cxx?r1=1.8&r2=1.9


That means with our further ongoing improvements in this area we get rid
of this patch and have only minor patches for our build env.

Building these libs on demand in our build env is for convenience.
Otherwise we would have to put them somewhere else, have to duplicate
the build env or would need to build them with our build env and use the
binary libraries from there. That would mean a further huge burden to
make the development for AOO more complicate.

I hope this helps

Juergen


On 6/1/12 11:07 AM, Ross Gardler wrote:
> On 1 June 2012 09:50, Jürgen Schmidt <jogischmidt@googlemail.com> wrote:
>> On 6/1/12 9:47 AM, Ross Gardler wrote:
>>> Sent from my mobile device, please forgive errors and brevity.
>>> On May 31, 2012 5:26 PM, "Pedro Giffuni" <pfg@apache.org> wrote:
>>>>
> 
> ...
> 
>>>> I admit this is very clear. I don't expect such development to be
>>>> a requirement for graduation but the transitory situation of a source
>>>> release that depends on carrying category-B tarballs in SVN now is
>>>> not really acceptable.
>>>
>>> I do expect this to be sorted out before graduation.
>>
>> it is addressed already
>>
>>> That might be as simple as getting clarity on the policy, it might be more
>>> than that. However, as a mentor I am uncertain about the practice adopted
>>> here and as such will not encourage the IPMC to vote for graduation until
>>> someone in the PPMC gets clarity.
>>
>> what do you expect?
> 
> Someone needs to take out all the rhetoric and abstract concepts. Pick
> any one of the cat-b cases and describe *exactly* how it is addressed
> in that case and *exactly* how this conforms to documented ASF
> policies.
> 
> Once we have clarity on the first case we can ask whether any of the
> other cases are different and then examine those.
> 
>> Should we remove all this dependencies and make AOO more or less
>> unusable or better uninteresting for real usage?
> 
> I am making no comment on what the technical solution is.
> 
> I want to see consensus. Consensus cannot be gained by shouting at one
> another about vague examples. I want concrete examples on a case by
> case basis until nobody is objecting or until the issues can be
> clearly communicated to either the IPMC or legal@ so that a
> clarification of ASF policy can be made.
> 
>> Anyway I think we tried everything to address this and we still work on
>> improvements step by step. If that is not enough for graduation I would
>> feel very unsatisfied.
> 
> It is, and always has been, a condition of graduation that the IP
> situation in the project conforms to ASF policies. There is a question
> about these tarballs and it must be resolved before graduation.
> 
> Ross


Mime
View raw message