Re: DicOOo Wizard ?? (+en_GB dictionary) (was Re: [RELEASE]: status update and plan)

[Pedro F. Giffuni]

Hi Stuart;

--- Lun 23/4/12, Stuart Swales ha scritto:
...
> en_GB dict? it's been in the source
> tree for ages!  See 
> http://svn.services.openoffice.org/opengrok/xref/OOO330_m20/dictionaries/en/
> 


Hmm.. we removed all the dictionaries from
the tree after the Apache move.

Can you add the latest en_GB dictionary to
the extensions site? We take all dictionaries
from there now.

cheers,

Pedro.

R: BSD (without advertisiong) Category A

[Pedro F. Giffuni]

--- Gio 22/3/12, Armin Le Grand  ha scritto:

>     Hi List,
> 
> in http://www.apache.org/legal/resolved.html
> BSD (without advertising clause) is part of Category A. I
> found no information in which category BSD *with advertising
> clause* maybe? Does someone know this?
> 

I think it is also in Category A because it matches the
requirements of the Apache Source License 1.0. Also
OpenSSL is OK.

Pedro.



> Sincerely
>     Armin
> --
> ALG
> 
>

Re: Rat scan vs SGA

[Pedro F. Giffuni]

hello;
--- Mar 20/3/12, Dave Fisher  ha scritto:
...
> Hi,
> 
> Just investigating and not acting:
> 
> libtextcat/data/new_fingerprints/fpdb.conf
> 
> This is based on this http://odur.let.rug.nl/~vannoord/TextCat/
> which is LGPL, not maintained.  We are in luck since
> Apache Spamassassin has a version of TextCat.
> 

We are actually using this:
http://software.wise-guys.nl/libtextcat/

Ubder a BSD License.

More information here:
https://issues.apache.org/ooo/show_bug.cgi?id=73173

The copyright is in that same directory so I think we
can just add a header there.

Pedro.

Re: Heads up: KDE Crystal Icon set going away.

[Pedro F. Giffuni]

--- On Thu, 11/17/11, Ariel Constenla-Haile  wrote:


>  
> IMO the tango icons look uglier than the Galaxy icon set,
> but it's just
> a question of taste. And the Galaxy is the only one we can
> be sure that
> has all the required icons. (try the tango icon set and
> you'll see that
> OOo still uses some Galaxy icons for the missing icons).
> What happens now in OOo from Oracle's times if you remove
> the crystal icon set
> from OOo installation? ... it will default to the default
> icon set; your
> patch was changing the existing behaviour.
> 

OK, you convinced me. :)


> On the other hand, AOO is removing copy left stuff from the
> source code,
> but not removing the functionality in the OOo side, that is
> fine as it
> is code now under the AL. So it seems that the approach
> with the images
> should be to add some configure switches to enable them
> providing some
> --with-system-crystal-icons or --with-system-icons etc.
>

OK, but that doesnt look easy. I will have to think
of something that is not ugly and we still cant ship
LGPL :(

Pedro.

Re: hwpfilter/source/ksc5601.h - header from GNU c library

[Pedro F. Giffuni]

Hi Oliver;

--- On Thu, 9/29/11, Oliver-Rainer Wittmann wrote:
...
> 
> Thanks for the input.
> 
> Adding the URL for the origin of the copyright and license
> text is a good idea. I will add it and use it also to point
> to the origin of  ksc5601.h.
> As Pedro researched the files are also found at 
> http://cgit.freedesktop.org/xorg/lib/libX11/tree/src/xlibi18n/lcUniConv
> I will use this URL as the origin.
> 

I suggest we take the original XFree86 file as this preserves
better the origin information. At a later time we can update
it to the X.Org version but XFree86 deserves some form of
credit for convincing the FSF ;).

(Just for curiosity I will compare the file we have with
the new header to check if there may be any significant
difference.)

cheers,

Pedro.

Re: hwpfilter/source/ksc5601.h - header from GNU c library

[Pedro F. Giffuni]

--- On Thu, 9/29/11, Rob Weir  wrote:
...
> 
> OK.  So [4] is a permissive license for all files in
> the directory.
> This may seen odd, coming from the FSF, but they encourage
> this is some cases, such as when the code is very small,
> or where the code promotes the use of an open standard
> that competes against a proprietary standard.
> 
> http://www.gnu.org/licenses/license-recommendations.html
> 

FWIW, What happened here is that the XFree86 guys
only uses code under MIT/BSD licenses, so they
contacted the FSF and got the permission from them. 

The X.org guys forked from XFree86 and I see they removed
the XFree86 CVS tags. Normal practice is keep the tags,
for origin reference. 

Pedro.


> > [4]
> > http://cvsweb.xfree86.org/cvsweb/*checkout*/xc/lib/X11/lcUniConv/COPYRIGHT?rev=HEAD&content-type=text/plain
> >
> 
>

Re: BZ css testing

[Pedro F. Giffuni]

Alejandro;

--- On Wed, 9/28/11, Alexandro Colorado wrote:

> Is there a way i can test de OOo CSS
> skin on the apache implementation?
> I had been tweaking to the current theme of the site. Also
> would be doing some custom imaging.

That's very cool, thanks!

Please open a jira issue with infra if there isn't one
already.

I know you probably thought of it but I guess you could
also setup your personal bugzilla to test with in a
linux/bsd box.

Pedro.

Re: A systematic approach to IP review?

[Pedro F. Giffuni]

--- On Wed, 9/28/11, Norbert Thiebaud wrote:
...
> On Wed, Sep 28, 2011 at 5:42 PM,
> Dennis E. Hamilton wrote:
> > It is unlikely that machine-generated files of any
> kind are copyrightable subject matter.
> 
> I'd imagine that Pixar, for instance, would have a problem
> with that
> blanket statement...
> 
> The very existence of this paragraph in the Bison manual :
> http://www.gnu.org/s/bison/manual/bison.html#Conditions
> also raise doubt as the the validity of the premise.
> 

Ugh... I am not a lawyer and I normally prefer not to be have
to read all that but OOo requires bison to build, so if that
paragraph still applies we should be using yacc instead.

Pedro.

RE: my next (tiny) steps - clean up regarding stuff which is not conform to the Apache license

[Pedro F. Giffuni]

FWIW;

--- On Wed, 9/28/11, Dennis E. Hamilton  wrote:
...
> If you mean ODMA.h, I don't believe
> there is any dependency on it and you should just get rid of
> it.
> 
> If you need to deal with it as third-party code, I can get
> you a version with a BSD-variant license that applies,
> although the header itself has not been touched.  AIIM
> approved the license some time ago.
> 
> I think the simple solution is to remove the ODMA.h header
> and delete the dialog about offering ODMA selections on Open
> ... first or not (if that is even present in current
> OpenOffice.org builds).  Post the patch on removing
> ODMA.h and I'll be happy to commit it [;<).
> 

odma.h is only used here:

ucb/source/ucp/odma/odma_lib.hxx

odma.h by itself doesn't have any license information
but it has the copyright:

/* odma.h - Definitions, prototypes, etc. for Open Document Managment API
 (ODMA) version 2.0.

 COPYRIGHT (C) 1994, 1995
 AIIM International
 All Right Reserved
*/

The surrounding code, however, is all LGPL by Oracle.

I checked the Hg log (I told you it might useful!) and
the initial revision is copyrighted by SUN so I guess we
will get it through the SGA.

I think we should just leave it as is for now.

Pedro.


>  - Dennis
> 
> DETAILS
> 
> In fact, ODMA.h is not a file anyone would use to bind to
> the ODMA32.dll, because then ODMA32.dll is required to be on
> the system.  The whole idea is that ODMA32.dll and the
> present of a DMS that is registered to work with
> OpenOffice.org is done by discovery, and these are the wrong
> headers and the wrong protocol for that.  
> 
> If someone wants to figure out a decent binding for ODMA32
> (there is no ODMA64 at this time) in the future, I can help
> with that.  I even have better headers and sample code
> for going through the discovery process.  I can even
> Apache License those [;<).  (Duhh.  I just
> realized that.)
> 
> However, I suspect that any further efforts at DMS and
> Content Management systems would be by tightening the WebDAV
> integration and also looking into CMIS as the most promising
> low-hanging fruit for content-management integration.
> 
> -Original Message-
> From: Oliver-Rainer Wittmann [mailto:orwittm...@googlemail.com]
> 
> Sent: Wednesday, September 28, 2011 06:05
> To: ooo-dev@incubator.apache.org
> Subject: my next (tiny) steps - clean up regarding stuff
> which is not conform to the Apache license
> 
> Hi,
> 
> I will now join the folks who are working on the clean up
> regarding 
> non-Apache license conform stuff.
> 
> Looking at the wiki - http://ooo-wiki.apache.org/wiki/ApacheMigration - 
> provides some low-hanging fruits for me for a start.
> I will create patches for the following Apache license
> problems:
> - UnixODBC
> - dtrans/source/os2/clipb/OS2Bitmap.cxx
> - A header from GNU c library
> - ODMA
> 
> Any objections to execute these already proposed and marked
> as solved 
> issues?
> 
> 
> Best regards, Oliver.
> 
> 
>

RE: my next (tiny) steps - clean up regarding stuff which is not conform to the Apache license

[Pedro F. Giffuni]

--- On Wed, 9/28/11, Pedro F. Giffuni wrote:

> Well... now that I think about it
> ...
> 
> The linux header (which is actually an GNU iconv header),
> can probably be dealt without too. The MIT licensed header
> in XFree86 is not on X.Org anymore so they did something
> about it.
>

X.Org uses git and everything git makes itself very difficult
to find (or perhaps it's just me against git!)
I found this minor enhancement in X.org sources (MIT license)
that we may want to carry too:

http://cgit.freedesktop.org/xorg/lib/libX11/commit/?id=83ce4daefdf544f801c7d666c89162690a36ce41

They are just comments though, nothing important.

> Is OOo on a opengrok anywhere? It would be good to see
> where such headers are used.
> 

(Thanks to mst@ for the link.)
FWIW, the header is only used here:
hwpfilter/source/hcode.cpp

Looks pretty easy to just replace it with the XFree86
version.

Pedro.

> > From: Oliver-Rainer Wittmann [mailto:orwittm...@googlemail.com]
> > 
> > Sent: Wednesday, September 28, 2011 06:05
> > To: ooo-dev@incubator.apache.org
> > Subject: my next (tiny) steps - clean up regarding
> stuff
> > which is not conform to the Apache license
> > 
> > Hi,
> > 
> > I will now join the folks who are working on the clean
> up
> > regarding 
> > non-Apache license conform stuff.
> > 
> > Looking at the wiki - http://ooo-wiki.apache.org/wiki/ApacheMigration - 
> > provides some low-hanging fruits for me for a start.
> > I will create patches for the following Apache
> license
> > problems:
> > - UnixODBC
> > - dtrans/source/os2/clipb/OS2Bitmap.cxx
> > - A header from GNU c library
> > - ODMA
> > 
> > Any objections to execute these already proposed and
> marked
> > as solved 
> > issues?
> > 
> > 
> > Best regards, Oliver.
> > 
> > 
> >
> 
> 

RE: handling of ext_sources - Juergen's suggestion [was: Re: A systematic approach to IP review?]

[Pedro F. Giffuni]

The idea (not originally mine) is to have keep only compatible
licensed code under an isolated (3rdparty) directory.

I think on the long run we should try to use the system versions
of such software when available, and every linux/bsd distribution
is probably doing that for LO already.

Pedro.

--- On Wed, 9/28/11, Dennis E. Hamilton  wrote:

> The problem with bringing the 3rd
> party software completely into the SVN tree and modifying it
> in the tree has to do with the license the updated software
> is under.  In that case, there *is* a code provenance
> issue and I believe it crosses a line that the Apache
> Software Foundation is unwilling to cross with regard to the
> integrity of its code bases.
> 
> The current patches to Boost, for example, do not change
> the license on the code and preserve the Boost
> license.  But since this is ephemeral and the source is
> never in the SVN tree (is that correct?) the derivative use
> disappears at the end of a build.  It is sufficient
> then to include the dependency in the NOTICE for the release
> and not worry further.
> 
> Also, the current dependency is several releases behind the
> current Boost release.  This might not matter - the
> specific Boost libraries that are used might not be
> effected.  But there is a release synchronization
> issue.  A fork would have to be maintained.  Also,
> the dependencies are managed better now, rather than having
> the entire Boost library installed for cherry picking.
> 
> (This will all change at some point, since Boost is being
> incorporated into ISO C++.  It is probably best to wait
> for that to ripple out into the compiler distributions.)
> 
>  - Dennis
> 
> -Original Message-
> From: Pedro F. Giffuni [mailto:giffu...@tutopia.com]
> 
> Sent: Wednesday, September 28, 2011 08:32
> To: ooo-dev@incubator.apache.org
> Subject: Re: handling of ext_sources - Juergen's suggestion
> [was: Re: A systematic approach to IP review?]
> 
> FWIW;
> 
> I don't like the patches because I can't really examine
> well
> the code, besides this is something the VCS handles
> acceptably:
> commit the original sourcecode and then apply the patches
> in a
> different commit. If we start with up to date versions
> there
> would not be much trouble.
> 
> just my $0.02, not an objection.
> 
> Pedro.
> 
> --- On Wed, 9/28/11, Jürgen Schmidt 
> wrote:
> 
> ...
> 
> > > I wouldn't give up the patches, as they allow to
> > handle updates better.
> > > This would cause a problem, as direct changes to
> the
> > 3rd party stuff without
> > > additional authorization (means: changing the
> source
> > code must not happen
> > > accidently, only when the 3rd party code gets an
> > update from upstream) must
> > > be prevented, while still patch files must be
> allowed
> > to added, removed, or
> > > changed, not the original source code. If that
> wasn't
> > possible or too
> > > cumbersome, checking in the tarballs in
> "3rdparty"
> > would be better.
> > >
> > 
> > i also wouldn't give up the patches and for that
> reason i
> > would like to move
> > forward for now with keeping the tarballs as proposed.
> But
> > i like the name
> > "3rdparty" for the directory and we can later on
> change it
> > from the tarballs
> > to the unpacked code it we see demand for it. At the
> moment
> > it's just easier
> > to keep the tarballs and focus on other work.
> > 
> > 
> > >
> > > As svn users never download the complete history
> as
> > DSCM users do, the pain
> > > of binary files in the repo isn't that hard. In
> case
> > AOOo moved to a DSCM
> > > again later, the tarballs could be moved out
> again
> > easily.
> > >
> > 
> > agree, we don't really loose anything, can change if
> > necessary and can
> > continue with our work
> > 
> > Juergen
> > 
> 
> 
>

RE: my next (tiny) steps - clean up regarding stuff which is not conform to the Apache license

[Pedro F. Giffuni]

Well... now that I think about it ...

The linux header (which is actually an GNU iconv header),
can probably be dealt without too. The MIT licensed header
in XFree86 is not on X.Org anymore so they did something
about it.

Is OOo on a opengrok anywhere? It would be good to see where
such headers are used.

Pedro.

--- On Wed, 9/28/11, Dennis E. Hamilton  wrote:

> From: Dennis E. Hamilton 
> Subject: RE: my next (tiny) steps - clean up regarding stuff which is not 
> conform to the Apache license
> To: ooo-dev@incubator.apache.org
> Date: Wednesday, September 28, 2011, 2:40 PM
> If you mean ODMA.h, I don't believe
> there is any dependency on it and you should just get rid of
> it.
> 
> If you need to deal with it as third-party code, I can get
> you a version with a BSD-variant license that applies,
> although the header itself has not been touched.  AIIM
> approved the license some time ago.
> 
> I think the simple solution is to remove the ODMA.h header
> and delete the dialog about offering ODMA selections on Open
> ... first or not (if that is even present in current
> OpenOffice.org builds).  Post the patch on removing
> ODMA.h and I'll be happy to commit it [;<).
> 
>  - Dennis
> 
> DETAILS
> 
> In fact, ODMA.h is not a file anyone would use to bind to
> the ODMA32.dll, because then ODMA32.dll is required to be on
> the system.  The whole idea is that ODMA32.dll and the
> present of a DMS that is registered to work with
> OpenOffice.org is done by discovery, and these are the wrong
> headers and the wrong protocol for that.  
> 
> If someone wants to figure out a decent binding for ODMA32
> (there is no ODMA64 at this time) in the future, I can help
> with that.  I even have better headers and sample code
> for going through the discovery process.  I can even
> Apache License those [;<).  (Duhh.  I just
> realized that.)
> 
> However, I suspect that any further efforts at DMS and
> Content Management systems would be by tightening the WebDAV
> integration and also looking into CMIS as the most promising
> low-hanging fruit for content-management integration.
> 
> -Original Message-
> From: Oliver-Rainer Wittmann [mailto:orwittm...@googlemail.com]
> 
> Sent: Wednesday, September 28, 2011 06:05
> To: ooo-dev@incubator.apache.org
> Subject: my next (tiny) steps - clean up regarding stuff
> which is not conform to the Apache license
> 
> Hi,
> 
> I will now join the folks who are working on the clean up
> regarding 
> non-Apache license conform stuff.
> 
> Looking at the wiki - http://ooo-wiki.apache.org/wiki/ApacheMigration - 
> provides some low-hanging fruits for me for a start.
> I will create patches for the following Apache license
> problems:
> - UnixODBC
> - dtrans/source/os2/clipb/OS2Bitmap.cxx
> - A header from GNU c library
> - ODMA
> 
> Any objections to execute these already proposed and marked
> as solved 
> issues?
> 
> 
> Best regards, Oliver.
> 
> 
>

Re: EIS replacement needed? WAS Re: why can't I access this address : http://tools.services.openoffice.org/EIS2/

[Pedro F. Giffuni]

Hi Bern;

From what I read, I don't think we want to get into all that
complexity right now. We have enough work already developing
OpenOffice to start developing something like EIS from
scratch :-(.

Perhaps there something opensource already that we can use to
some of the EIS functionality?

I doubt it will cover the same functionality but we have some
tools that we haven't explored yet.
For example gump:

http://ci.apache.org/#gump

cheers,

Pedro.


--- On Wed, 9/28/11, Bernd Eilers  wrote:
...
> 
> Hi there!
> 
> There is now no one anymore activly maintaining the EIS
> server, EIS software and EIS database.
> At Oracle some of my duties where just these tasks but I
> now have no longer access to this service.
> 
> It may have worked some time without maintenance but now
> it´s gone.
> That means that neither the web application nor the SOAP
> webservice used by some commandline tools in the build
> environment will work anymore.
> 
> Please also note that the EIS source code was closed source
> and has not been donated to apache.
> If the apache OOo Community needs a replacement for these
> services this will have to be rewritten from scratch
> probably with some adaption to some different kind of
> workflow.
> 
> See also:
> http://wiki.services.openoffice.org/wiki/EIS
> 
> I think using such a tool like EIS to organize workflow
> between development and QA has proven to be useful in the
> past and that something like this might also be useful on
> the new home of openoffice.org at apache.
> 
> What do others think?
> 
> 
> Kind regards,
> Bernd Eilers
> 
>

Re: Not new but under a new hat

[Pedro F. Giffuni]

Hi;

First of all, I am very glad seeing all this OOo developers
hired at IBM .. it's great news!!

FWIW, I've seen codebases fork under the same license and
never reunite (FreeBSD, NetBSD, and more forks coming out
of each afterwards) so while I don't say merging back LO
into OOo is impossible, it's really really difficult.

--- On Wed, 9/28/11, Ian Lynch  wrote:

> >
> > If you have a specific proposal for use of
> Apache-owned trademarks,
> > then you are welcome to submit it to this list. 
> We can then review,
> > discuss and make a recommendation to Apache branding.
> >
> 
> Yes it is straightforward, I have been through the process
> so I can vouch
> for it from first hand experience.
> 
> >
> > But I think reunification is more than brand
> reunification.  Simply
> > renaming LO to OOo would only confuse the users, since
> the products
> > differ in features and quality.
> 
> 
> Which is why I suggested LibO on Linux and AOO on Windows
> and Mac. Google has different brand names for Chrome on
> Windows and Linux.
> 

What I've noticed lately is that the ASF has many projects
that relate directly to things we want to have in OOo so
I have to say the decision Oracle took to give OOo to
the Apache Foundation was the right one.

AOOo will not give up on supporting linux because it also
involves having support for Solaris, *BSD and there is
a lot of shared code with Mac and Windows.

There are, however, some things that we can't work on and
that leaves space for LibreOffice. GPL and LGPL stuff is
license X - no touch - and this does limit what we can do
with linux desktop integration since both Gnome and KDE
are GPL'd.

For now we have still a lot to do here @Apache but it's
clear to me, that there will be healthy Apache OOo.
LO can choose to join forces now, when it easier, or
join forces later, when taking code from Apache will
be more difficult. Either way.. they are welcome.

Pedro.

Re: my next (tiny) steps - clean up regarding stuff which is not conform to the Apache license

[Pedro F. Giffuni]

Hi Oliver-Rainer;

--- On Wed, 9/28/11, Oliver-Rainer Wittmann wrote:

> Hi,
> 
> I will now join the folks who are working on the clean up
> regarding non-Apache license conform stuff.
> 
> Looking at the wiki - http://ooo-wiki.apache.org/wiki/ApacheMigration -
> provides some low-hanging fruits for me for a start.
> I will create patches for the following Apache license
> problems:
> - UnixODBC
> - dtrans/source/os2/clipb/OS2Bitmap.cxx
> - A header from GNU c library
> - ODMA
> 
> Any objections to execute these already proposed and marked
> as solved issues?
>

No at all... this has waited enough, thanks!

Do remember this has to be registered in the NOTICE file.

http://www.apache.org/legal/src-headers.html

cheers,

Pedro.

Re: handling of ext_sources - Juergen's suggestion [was: Re: A systematic approach to IP review?]

[Pedro F. Giffuni]

FWIW;

I don't like the patches because I can't really examine well
the code, besides this is something the VCS handles acceptably:
commit the original sourcecode and then apply the patches in a
different commit. If we start with up to date versions there
would not be much trouble.

just my $0.02, not an objection.

Pedro.

--- On Wed, 9/28/11, Jürgen Schmidt  wrote:

...

> > I wouldn't give up the patches, as they allow to
> handle updates better.
> > This would cause a problem, as direct changes to the
> 3rd party stuff without
> > additional authorization (means: changing the source
> code must not happen
> > accidently, only when the 3rd party code gets an
> update from upstream) must
> > be prevented, while still patch files must be allowed
> to added, removed, or
> > changed, not the original source code. If that wasn't
> possible or too
> > cumbersome, checking in the tarballs in "3rdparty"
> would be better.
> >
> 
> i also wouldn't give up the patches and for that reason i
> would like to move
> forward for now with keeping the tarballs as proposed. But
> i like the name
> "3rdparty" for the directory and we can later on change it
> from the tarballs
> to the unpacked code it we see demand for it. At the moment
> it's just easier
> to keep the tarballs and focus on other work.
> 
> 
> >
> > As svn users never download the complete history as
> DSCM users do, the pain
> > of binary files in the repo isn't that hard. In case
> AOOo moved to a DSCM
> > again later, the tarballs could be moved out again
> easily.
> >
> 
> agree, we don't really loose anything, can change if
> necessary and can
> continue with our work
> 
> Juergen
>

Re: Iaccessible2 in OOo

[Pedro F. Giffuni]

Hi;

There was an interesting cross-posting by Malte Timmermann
not long ago:

http://mail-archives.apache.org/mod_mbox/incubator-ooo-dev/201109.mbox/ajax/%3c4e6dc5c3.9050...@gmx.com%3E

I am not suggesting it should be done now but perhaps
committing accfixes2 would help the IBM IA2 integration.

cheers,

Pedro.


--- On Wed, 9/28/11, Jürgen Schmidt  wrote:
...
> 
> even though the fact and the necessity of better
> accessibility is known it is very good that you
> raise this point again and make clear the
> situation. I think with the whole transition of
> OpenOffice.org to Apache that is still
> ongoing and not finished we lose important time to work on
> this but we can't change it. We can only try to work
> harder to provide something usable asap.
> 
> Juergen
>

Re: [EXT][DISCUSS] Including Groovy as a scripting language

[Pedro F. Giffuni]

--- On Tue, 9/27/11, Rob Weir  wrote:
...

> 
> Bringing it into SVN is easy.  Making it into a
> release is another
> question.  To do that requires going through the IP
> Clearance process.
>

Yes, I was obviously referring to the legal requirements.

> 
> I'm willing to debate it for long-established, well-known,
> high-profile OSS projects that are being used everywhere,
> e..g, ICU.
> This is partially about risk management.  That is why
> we should take
> this case by case.  But I don't think the Groovy
> extension falls into that category.
> 

OK: Ultimately this is a matter of policy and I find it
an acceptable policy to ask for an SGA to very specific
code like the groovy extension. I don't think carrying
the extension involves carrying groovy itself, so we
don't have to through all the dependency chain asking
for SGA's.

OTOH, asking for code assignment for minor stuff that
is already completely in the Public Domain or under a
BSD license, like ucpp, would be a complete nonsense.
As you say .. case by case.

Dmake does require IP clearance so good luck contacting
WTIcorp :).

Pedro.

Re: [EXT][DISCUSS] Including Groovy as a scripting language

[Pedro F. Giffuni]

--- On Tue, 9/27/11, Rob Weir  wrote:
...
> > Another point that Rob brought would be if we need a
> SGA
> > to add the Groovy (or other) extension.
> >
> > I would think an SGA is a rather extreme thing to
> require
> > for extensions: we wouldn't require that if we want
> to
> > include stuff like ucpp, bsh, or icu ... or dmake ;).
> >
> 
> Again, this is a binary versus source code question. 

Not really, that was clarified already. The issue now is
how to bring code into the the SVN tree.

> I thought the discussion was about bringing the groovy
> extension source code over, yes?

Yes.

> That would require taking it through the IP
> Clearance process.
> An SGA is the normal way to do this.
>

The PMC can require signing an SGA, I don't discuss that.

There are other ways of doing it though: people that
have signed ICLAs can bring in code under an appropriate
license and register it in the NOTICE file, and that's
about to happen as we replace copyleft components with
less restricted software.

You can't really expect opensource coders to go signing
SGAs for all the projects that want to use their code. 

cheers,

Pedro.

Re: [DISCUSS] Is it worth looking at Confluence Wiki Again?

[Pedro F. Giffuni]

--- On Tue, 9/27/11, Kay Schenk  wrote:

As Rob Weir has put it ...
...
> >
> > So obviously there is limited volunteer bandwidth to
> > migrate the wiki.
> > And I've heard from several people, on and off
> > the list, that much of what is on the wiki is
> > not very useful.
> >
> 
> uh, well...I don't know bout this. I was under the
> impression that MUCH of developer info was here.
>  Others would need to weigh in but I think it was
> widely used because of the ease of use.
> 
Just my word of advice:

Check the MediaWiki at http://ooo-wiki.apache.org/

If we take out information about Hg (dead),
the Development Teams and Projects (which will have to
be reorganized), Old News, the issue tracker ...

Is the information left worth it to run through a
MW-->CWiki conversion effort?

I think given the license situation we should just
leave that stuff as read-only for now and do all new
work on CWiki (or MoinMoin).

Pedro.

dmake licensing issues again (was Re: [EXT][DISCUSS] Including Groovy as a scripting language)

[Pedro F. Giffuni]

--- On Tue, 9/27/11, Rob Weir  wrote:

> > Hello;
> >
> > --- On Tue, 9/27/11, Shane Curcuru wrote:
> > ..
> >>
> >> I.e. there are cases where Apache projects may
> >> want to include Category-B (EPL, CPL, MPL, etc.)
> >> tools within a distribution.  This is permitted
> >> in binary form, but not source form.
> >>
> >
> > Someone correct me if I am wrong, but dmake as we have
> it
> > today clearly lies in this category.
> >
> 
> Would it be part of the released distribution?  That
> is the key question.
> 

I understand that you think that since it is a build
tool it will not be linked to the binary distribution.
If we only distribute binaries, that could be acceptable,
but I don't see how you are going to avoid it being in
the source distribution.

Redistributing the MPL stuff in source code form is
explicitly not permitted. The idea behind ASF permission
to distribute them in binary form is to avoid any potential
risk of developers editing the sources accidentally to find
out later that part of their enhancements are under a
copyleft license.

> 
> But we should watch out  and take this case-by-case.
> 

This matters.. it's not a case by case issue but rather the
rules: someone may want to make changes to dmake to build
their own modules and then make their modified version
of dmake available only on binary form. It may not make
sense for us now but it's what users expect to do from
code coming from the ASF.

With dmake and other tools, and that was the second part
of my comment, I think a tarball with the sources would be
considered binary form. And then, just like with EPM, I
think some people may prefer reusing a pre-built package
instead of adding more time to the (already demanding)
build.

Pedro.

Re: [code][repo] Integration of CWSs, HOW-TO with hg and git svn and stgit

[Pedro F. Giffuni]

Hi;

I thought it would be a good time to bring this subject
up again.

--- On Sat, 9/10/11, Mathias Bauer wrote:
...
> 
> >> and i completely forgot to mention that i've got a
> linear MQ patch
> >> series applying against OOO340 that contains the
> following:
...
> >> 
> >> ause131
> >> ause130
> >> writerfilter10
> >> gnumake4
> >> sd2gbuild
> > 
> > Nice, will you apply and commit them?
> 
> These cws were not planned to be integrated into 3.4.
> Perhaps we should stick to that?!
> 

Now that the dust seems to have settled down, and assuming 
those CWS' don't break anything, I would like to see them
committed before we start updating the license.

cheers,

Pedro.

> Regards,
> Mathias
> 
> 

Re: [EXT][DISCUSS] Including Groovy as a scripting language

[Pedro F. Giffuni]

Hello;

--- On Tue, 9/27/11, Shane Curcuru wrote:
..
> 
> I.e. there are cases where Apache projects may want to
> include Category-B (EPL, CPL, MPL, etc.) tools within a
> distribution.  This is permitted in binary form, but
> not source form.
>

Someone correct me if I am wrong, but dmake as we have it
today clearly lies in this category.

 
> With these tools in binary form in the Apache release, a
> user is unlikely to attempt to modify that non-Apache
> licensed source code (which they'd have to go find
> themselves) without clearly realizing that that portion of
> the Apache release is not under our Apache license.
> 

Concerning the external sources that we still carry: would
source tarballs of MPL/LGPL stuff be considered binary form?
This is mostly what we do today so it would solve
most of our issues (gettext still has to go), but that
workaround would remove the motivation to further cleanup
of the source (glibc could stay!)

Pedro.

Re: ooo-myspell at apache-extras.org

[Pedro F. Giffuni]

--- On Mon, 9/26/11, Rob Weir  wrote:

> > --- On Sat, 9/24/11, Rob Weir wrote:
> > ...
> >> If I understand corectly, Apache considers MPL 1.1
> >> to be "weak copyleft" and we have some limited ways
> >> (as a binary of using it in our releases.
> >>
> >
> > Yes we can. I am not sure what a company would think
> > about it though: some lawyers are more strict than
> > others. What does IBM use in Lotus Symphony?
> >
> 
> We use an library from our LanguageWare project.  It
> is not open source, unfortunately.
> 
> http://www-01.ibm.com/software/globalization/topics/languageware/
>

Ugh, this link was supposed to go with the reply but my
mailer ate the original message :(.
http://incubator.apache.org/opennlp/index.html

In any case, the issue with hunspell is that copyleft is
always a problem when it comes to companies where lawyers
take decisions. That's the reason for keeping myspell
around, even when I don't expect it to see much
development.

Pedro.

Re: ooo-myspell at apache-extras.org

[Pedro F. Giffuni]

FWIW,
It may be like fitting a square peg in a round hole but there is something
similar coming to Apache:

http://incubator.apache.org/opennlp/index.html

Pedro

Re: [DISCUSS] Is it worth looking at Confluence Wiki Again?

[Pedro F. Giffuni]

Hi;

--- On Mon, 9/26/11, Kay Schenk  wrote:

> 
> So, what IS going on? Anybody?
> 
> I think (thought?) Pedro was kind of coordinating the test
> of Confluence with the infra folks but ???
> 

Unfortunately not. I asked infra@ and they didn't answer: I
understand they expect us to do it.
I have rather limited resources right now so I dropped it
from my plans.

Terry did leave a dump of the data if anyone wants to try but
from the information of the plugin it would look like whomever
tries must have Confluence with the latex plugin installed.

This said, from what I've seen in the MediaWiki, a lot of the
information there requires serious updating, a lot simply
doesn't apply anymore. Maybe it's not crazy to just copy-paste
and reformat the information that is still valid manually.

Pedro.

Re: ooo-dmake now at Google Code

[Pedro F. Giffuni]

--- On Sun, 9/25/11, Rob Weir  wrote:
...
> 
> Why exactly do we need to move dmake?
> 
> Having copyleft build tools is not necessarily a problem,
> especially if the code is not included in the release.

If you don't include it in the release, how are people
going to build OpenOffice?

> Remember, when we build on Linux we use many GNU utilities.   I
> don't see anything wrong with just leaving Dmake where it was.
> 

I don't see the source code for GNUmake, gcc, or epm in the
repository. We can use GNU stuff but we just can't carry it.


> > http://code.google.com/p/ooo-dmake/
> >
> > Why Google Code and not apache-extras you might
> > wonder: Dmake is something that is unlikely to
> > be transferred to Apache and it's a tool that
> > both AOOo and LibreO are interested in getting
> > rid of. Adding it to apache-extras would've
> > given that impression that dmake somehow had a
> > future in Apache ;).
> >
> 
> Hosting at Apache-Extra does not imply something "has a
> future in Apache".  Its purpose is specifically for
> things that cannot come to Apache. We have the incubation
> process for bringing code (and communities) to Apache.

There is no Dmake community coming to Apache. Dmake is
going out sooner or later, and having it in apache-extras
won't help it.

> And we have an Apache Labs for starting new
> code bases, pre-incubation.  But Apache-Extras is
> for:
>

... 
> 
> See:  http://community.apache.org/apache-extras/faq.html
> 

Quite honestly I don't see any problem why it can't be in
Google Code instead. If someone else want's to maintain it
in apache-extras instead I won't object, just let me know
and I'll remove it.

> 
> I'm not seeing the benefit here.
> 
> We currently have a dependency on a build tool that any
> committer can modify and improve, or fix bugs in.
>
 
The only planned improvement is to remove it. I don't
think it's acceptable to depend in any way on a hacked
copyleft utility.


> This is replaced by having the same tool in an external
> repository that only one committer has rights to modify.
> 

Really? It seems like I am the only one interested in doing
something with it and I am not a committer. If anyone
(committer or not) wants access I'll be glad to add them:
just send me email addresses.

> 
> What am I missing?   I'm not saying you are wrong to do
> this.  I'm just saying that I don't see why this is a good
> thing.
>

For me it's quite obvious. If you really think 3.4 can be
released with that copylefted monster in the tree go ahead.
I will keep using the tarball in the Google Code because an 
independent dmake package is already a dependency to build
LibreOffice on FreeBSD and some versions of linux.

Pedro.

ooo-dmake now at Google Code

[Pedro F. Giffuni]

Hello;

As you all might've been thinking, one of the things
we really have to move out of the tree is dmake so I
just helped dmake step out by moving it to it's own
repo at Google Code.

http://code.google.com/p/ooo-dmake/

Why Google Code and not apache-extras you might
wonder: Dmake is something that is unlikely to
be transferred to Apache and it's a tool that
both AOOo and LibreO are interested in getting
rid of. Adding it to apache-extras would've
given that impression that dmake somehow had a
future in Apache ;).

I was not even going to add the ooo- prefix but
the simple "dmake" name was taken by some other,
completely unrelated, project.

I also had a try at transferring the SVN history
from the older repository but that involves getting
a dump of all the OOo repository and then using
svndumpfilter ... it was just not worth it IMHO,
If someone wants to do it, I could try to load
it though.

I will try to provide some prebuilt win32 binaries
on the Google Code site but now we can focus on
removing dmake from the tree and adding a build
dependency in the same lines of epm.

cheers,

Pedro.

Re: ooo-myspell at apache-extras.org

[Pedro F. Giffuni]

--- On Sat, 9/24/11, Rob Weir  wrote:
...
> 
> HunSpell code is tri-licensed under GPL/LGPL/MPL.
>

That particular licensing scheme is rather weird: LGPL
implies that it can become GPL so you could just say
dual licensed LGPL/MPL, and then, once you make something
pluggable, the GPL basically becomes unenforceable but
let's not get into that right now ;).


> If I understand corectly, Apache considers MPL 1.1 to be
> "weak copyleft" and we have some limited ways (as a
> binary of using it in our releases.
> 

Yes we can. I am not sure what a company would think about
it though: some lawyers are more strict than others. What
does IBM use in Lotus Symphony?

> 
> Individual dictionaries, however, can have their own
> license as you know.  So there may be some that we cannot
> include in the release, but we can still point the user to.
>

It looks like we might have a bunch of them that we can
relicense to AL2. We will have to wait for the SGA to know
for sure but if it does happen, it is a nice treasure that
we should take advantage of.

Pedro.

Re: ooo-myspell at apache-extras.org

[Pedro F. Giffuni]

+1

I don't want to send Apache back to the spell checker in
OOo 2.x, and the LO guys have made a nice job creating
independent Hunspell+lang dictionaries already.

What I am doing with MySpell is just making sure it doesn't
disappear so that if someone needs an alternative he/she/them
won't have to start from scratch.

FWIW, today I made my first and final release :-P.

Pedro.

--- On Sat, 9/24/11, Andrea Pescetti wrote:
...
> On 22/09/2011 Pedro F. Giffuni
> wrote:
> > Hi Gianluca;
> > Is your work related to this version?
> > http://members.xoom.it/trasforma/ispell/
> > Just wondering if we have to contact them too.
> 
> Whatever this is, it is widely unrelated to the dictionary
> currently included in OpenOffice.org 3.3. The best starting
> point for it is http://extensions.services.openoffice.org/en/project/dict-it
> (note that the latest release is more recent than OOo 3.3
> and was supposed to be included in OOo 3.4 as expected to be
> released by Oracle).
> 
> The current version is GPL3 and it has a few copyright
> holders (including Gianluca and myself), but we are sure
> that some of the copyright holders will never give
> permission to relicense their work.
> 
> But we need to open, at due time, a dedicated discussion on
> writing aids before saying that GPL dictionaries cannot be
> used. Shipping an older Italian dictionary (or no Italian
> dictionary at all) would be a huge regression and it would
> definitely lead to users abandoning OpenOffice.org in
> scores, and to community members feeling frustrated because
> their work of years is removed from OpenOffice.org just for
> the stubbornness of one copyright holder opposing the
> license change.
> 
> Workarounds can surely be found (like OOo offering to
> download GPL dictionaries upon installation or first run)
> and I'd urge to consider them before risking to alienate
> entire native-lang communities.
> 
> Regards,
>   Andrea.
> 
>

Re: [DISCUSSION] start collecting the correct content for a NOTICE.txt file

[Pedro F. Giffuni]

 Hello juergen;

I think the file should be named NOTICE (without the .txt extension):

https://svn.apache.org/repos/private/committers/

Cheers,

Pedro.

Re: Re[2]: ooo-myspell at apache-extras.org

[Pedro F. Giffuni]

Hi Yakov;

--- On Fri, 9/23/11, Yakov Reztsov  wrote:

> 
> 22 сентября 2011, 20:29 от "Pedro F. Giffuni":
> > HunSpell is copyleft so we cannot include it. 
> 
> Hi! 
> Hunspell is  C++ library under GPL/LGPL/MPL
> tri-license.  (http://hunspell.sourceforge.net/).

http://www.apache.org/legal/resolved.html

My interpretation: GPL we won't take, MPL we will leave
outside the tree. AL2 is best.

> What license is required for dictionaries in AOOo?

We are not sure yet if AOOo will carry dictionaries but
if we do they will be subject to the link above.

> Can you include Russian spellcheck dictionary  in
> AOOo?
> See https://issues.apache.org/ooo/show_bug.cgi?id=113873
>

The license looks good to me, we can use it. 

thanks,

Pedro.

Re: ooo-myspell at apache-extras.org

[Pedro F. Giffuni]

Hi Gianluca;
Is your work related to this version?
http://members.xoom.it/trasforma/ispell/
Just wondering if we have to contact them too.
With respect to Hunspell vs. Myspell, there is still no decision and I 
thinkthat will have to wait until the Oracle SGA is in.
HunSpell is copyleft so we cannot include it. We could include MySpelland the 
free (less-restricted) dictionaries we can get and have an optionfor Hunspell, 
or we could make Myspell an extension.
Both would work for me, I just wanted to make sure MySpell could bepreserved 
before the Oracle OpenOffice site disappears.
cheers,
Pedro.
--- On Thu, 9/22/11, Gianluca Turconi  wrote:

From: Gianluca Turconi 
Subject: Re: ooo-myspell at apache-extras.org
To: ooo-dev@incubator.apache.org, giffu...@tutopia.com
Date: Thursday, September 22, 2011, 10:41 AM

2011/9/22 Pedro F. Giffuni 


The case of the italian support is indeed "special",

and is something I am particularly interested in. The

linguistico project seems to be particularly political:

they have this long discourse on how "OpenSource is

evil, free is good". Maybe the author of the original

ispell dictionary is more condescending.
I'm the original author of the Italian OOo dictionary and I wouldn't have any 
issue in re-licensing the original MySpell dictionary as far as it is included 
in a AOOo user-oriented binary release, if and when it will be released.


However, the Italian dictionary has a 10-years long history of improvement 
under LGPL/GPL and several different co-author. The current version is simply a 
lot better than the original one whose copyright rights I own.


So, the re-licensing would be, IMO, just a regression. Of course, a less 
complete dictionary is always better than nothing, from a user point of view. 
;-)

However, I haven't understood yet (this list is sometimes really overwhelming), 
what linguistic tools will be used in AOO:


1) MySpell or Hunspell?
2) for hyphenation?

Regards,

Gianluca
-- 
Lettura gratuita o acquisto di libri e racconti di fantascienza, fantasy, 
horror, noir, narrativa fantastica e tradizionale:
http://www.letturefantastiche.com/

Re: AOOo can't save passwort protected file

[Pedro F. Giffuni]

Hi;

--- On Thu, 9/22/11, Michael Stahl wrote:
...
> > Thanks for this point. NSS is not certified and given
> the
> 
> where the heck did you get that idea?
> 
> http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#1280
>

Ugh.. there's something broken in the iPad safari
search option. OK, it's still not too easy to ship
NSS with Apache OO and we already have OpenSSL anyways.

...
> > While here .. I also think we should kill mozilla:
> > 
> > 1) The version we carry also has serious security
> issues.
> > 2) Google Chromium has a better license.
> 
> but can Google Chromium read Mozilla address books?
> 
> AFAIK that is all that OOo uses Mozilla for...
> 

I thought it was to use embedded links in documents.
Mozilla address books can continue being optional,
I'd just be more tempted to use just mozilla
thunderbird for that.

cheers,

Pedro.

Re: ooo-myspell at apache-extras.org

[Pedro F. Giffuni]

Ciao Gianluca!

I am afraid there's nothing as a systematic approach
to this yet.

When the new grant is in we can see which dictionaries
SUN got an assignment for and relicense them under AL2.
(From some bugzilla issues I've seen it's evident they
did try to get the copyrights assigned).

I think most linux/BSD distributions will end up using
hunspell + language specific dictionaries that are
already available for LibreOffice but still it's
important that we, as a community, raise awareness that
GPL tends to be more a limitation than an asset when
trying to make your work widely available.

The case of the italian support is indeed "special",
and is something I am particularly interested in. The
linguistico project seems to be particularly political:
they have this long discourse on how "OpenSource is
evil, free is good". Maybe the author of the original
ispell dictionary is more condescending.

cheers,

Pedro.

--- On Thu, 9/22/11, Gianluca Turconi wrote:
...
> 2011/9/21 Pedro F. Giffuni
> 
> 
> > If some of the dictionary files can be relicensed
> under
> > an Apache License I would consider including them
> there
> > too but I would prefer to keep any copyleft stuff out
> of
> > the new project.
> >
> 
> BTW, is there any idea here about how to manage the
> dictionaries that were
> *included* into the OOo dev repository (as third party
> code) and the binary
> distribution of the product too?
> 
> And about the hyphenation dictionaries?
> 
> Some of these dictionaries, like the Italian one, have a
> very old history
> that goes back to 2000/2001 and a very difficult licensing
> history (changes
> of license and of copyright owners).
> 
> Is there any plan for a systematic approach to their
> copyright owners for a
> license change?
> 
> It isn't a duty to included such dictionaries in the native
> language
> binaries, but it's surely a user friendly behavior. Indeed,
> a *very
> appreciated* user oriented behavior.
> 
> Regards,
> 
> Gianluca
> -- 
> Lettura gratuita o acquisto di libri e racconti di
> fantascienza,
> fantasy, horror, noir, narrativa fantastica e
> tradizionale:
> http://www.letturefantastiche.com/
> 

[AOOo 4.0] dev wishlist (Re: Starting a conversation on AOOo 4.0)

[Pedro F. Giffuni]

Hmm ...OK.

- You've been hearing I'd like to see a more Apache
  (not necessarily Java) stuff. 
- OCR capabilities (Google made them free) would
  also be nice.

But here is a really crazy idea:

How about using the Math Template Library for calc:

http://osl.iu.edu/research/mtl/mtl2.php3

MTL4 has an open source version too: both are
basically a BSD-like license with advertisement
clause.

I am not sure if most people will feel comfortable
having (for example) imaginary numbers in a cell,
but I've heard people using math-specific tools
that would like to do serious calculations in a
spreadsheet. This would make calc an interesting
tool for "real" scientific users. 

cheers,

Pedro.

ooo-myspell at apache-extras.org

[Pedro F. Giffuni]

Hello guys;

I have created a new project at apache-extras.org to preserve
MySpell:

http://code.google.com/a/apache-extras.org/p/ooo-myspell/

There's not much there yet: basically just the original
tarball I got from OpenOffice.org, but I felt it was
important to preserve this code in some way. I couldn't
find any official repository and no version control.

In the following days I will probably start playing with
subversion and perhaps clean it up to work with clang but
I am not really planning to do major development.

Of course if anyone is willing to work on it I will be
glad to add other developers or even hand over control.

If some of the dictionary files can be relicensed under
an Apache License I would consider including them there
too but I would prefer to keep any copyleft stuff out of
the new project.

FWIW, I also contacted the Hunspell author about
(re)licensing but I have not heard from him. Usually
a FSF email address is not a good sign for that type
of requests, but it is worth the try.

Cheers,

Pedro.

Re: A systematic approach to IP review?

[Pedro F. Giffuni]

--- On Mon, 9/19/11, Rob Weir  wrote:
...
> 2011/9/19 Jürgen Schmidt :
...
> >
> > do you mean to check in the files under ext_source
> into svn and remove it
> > later on when we have cleaned up the code. Or do you
> mean to put it
> > somehwere on apache extras?
> > I would prefer to save these binary files under apache
> extra if possible.
> >
> 
> 
> Why not just keep in in SVN?   Moving things
> to Apache-Extras does not
> help us with the IP review.   In other
> words, if we have a dependency
> on a OSS module that has an incompatible license, then
> moving that
> module to Apache Extras does not make that dependency go
> away.  We
> still need to understand the nature of the dependency: a
> build tool, a
> dynamic runtime dependency, a statically linked library, an
> optional
> extensions, a necessary core module.
>

But adding in stuff that we have to remove immediately (nss,
seamonkey, .. ) doesn't help either. I also think a lot of
that stuff has to be updated before brought in: ICU
apparently would be trouble, but the Apache-commons, ICC,
and other stuff can/should be updated.



>> a) Track this in SVN properties.  So set ip:sga
> for the SGA files,
> >> ip:mit for files that are MIT licensed, etc.


I thought we had delayed updating the copyrights in the
header to ease the CWS integration. I still hope to see
more of those, especially anything related to gnumake
(I don't know when, but dmake has to go!).

Using the SVN properties is a good idea. And we do have
to start the NOTICES file.

All just IMHO, of course.

Pedro.

Re: AOOo can't save passwort protected file

[Pedro F. Giffuni]

 Ugh ... nevermind, we already carry xmlsec !

I guess we have everything to get rid of nss but we are not using it right? 
Apache Santuario is interesting though.

Cheers, Pedro.

Re: AOOo can't save passwort protected file

[Pedro F. Giffuni]

 Hi again;

I think I found the missing piece in the puzzle ...
OOo already uses OpenSSL, but in order to replace nss we need support for 
xmlsecurity. This library provides just that under an MIT license:

 http://www.aleksey.com/xmlsec/

Alternatively Apache has it's own stuff:

 http://santuario.apache.org/

Cheers, Pedro.

Beanshell to be relicensed under Apache License 2 !!

[Pedro F. Giffuni]

Dear Apache OpenOffice.org community;

I have been authorized, and it is my pleasure, to share
with you the good news ...

The Beanshell scripting language will be made available
soon under the Apache License version 2. Later on, this
month, the website will be updated to reflect that:

 http://beanshell.org/

This is done specifically to permit wider utilization of
bsh by Apache projects. It will benefit the OOo incubator
but also Apache Camel and others and is actually a very
nice technology that is now unrestrictedly available to
all Java developers and users.

Special thanks to Daniel Leuck and Pat Niemeyer @ikayzo
for trusting their technology to an even wider audience
of open source developers and users!

Pedro.

Re: AOOo can't save passwort protected file

[Pedro F. Giffuni]

--- On Sat, 9/17/11, Rob Weir  wrote:
...
> 
> OpenSSL is a a validated module when run in "FIPS mode":
> 
> http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2009.htm#
> 
> But that would still apply to AES, not Blowfish.
> 
> Think of it this way:  FIPS 140 defines what the
> acceptable algorithms are.  Then the actual modules,
> the actual libraries, are validated by 3rd party
> testing labs according to NIST criteria.   If we use
> validated modules implementing approved algorithms, then
> we're golden.
> 

Thanks for this point. NSS is not certified and given the
version OOo carries has known security issues I suggest
we kill the configure option to avoid hazards to our users.

Without other options I prefer Blowfish to no security at all.
Again, patches for OpenSSL or any other certified solution
are welcome :).

While here .. I also think we should kill mozilla:

1) The version we carry also has serious security issues.
2) Google Chromium has a better license.
3) I actually think we should be browser version agnostic. 

> I'd be happy if we had deep in some configuration dialog
> the ability for user (or more likely the IT department)
> to specify the algorithm to use.
>

I would think it could be a compile time option so we could
name such switch "configure --with-ssl".

See? Everyone happy now :).

Cheers,

Pedro.

Re: saxon

[Pedro F. Giffuni]

Hi again;

I noticed this nice package came in through FreshPorts:

http://www.zorba-xquery.com/

It appears to have all the functionality of saxon under
an Apache version 2 license, so it could be another
alternative to consider along with Xalan/Xerces.

I should also mention that I contacted the saxon authors
and while they would've really liked to adopt an Apache
License this is not really possible anytime soon due
to some contributed code and difficulties getting all
the approvals. Apparently IBM also went through such
a process with them before and ended giving up.

cheers,

Pedro.

--- On Mon, 8/29/11, Mathias Bauer  wrote:

> Am 29.08.2011 17:41, schrieb Pedro F. Giffuni:
> 
> > Looking a bit into Matthias' list, there's the saxon
> issue.
> > 
> > I looked for a replacement and it would look like the
> > Apache Xalan project could be an alternative:
> > 
> >    http://xalan.apache.org/
> > 
> > If, for some reason, we want to keep saxon, please
> note:
> > 
> > - In principle it would seem like it's required by
> doc
> > developers only, right? So in principle we shouldn't
> > require it unless we are regenerating the help files.
> > BTW, the DITA toolkit also uses saxon.
> > 
> > - The version we use is extremely outdated and without
> support
> > of any kind. I would recommend checking out the
> Homepage and
> > adopt either the last Saxon-B or, preferable,
> Saxon-HE.
> > Also the saxon patch in OO mentions a bug in ant that
> was
> > solved long ago.
> 
> saxon is used at least for our xslt filters (or only for
> some of them, I
> don't know). Until noone investigated that further, we
> can't exclude
> that we need a replacement.
> 
> Regards,
> Mathias
> 
>

Re: Hi everybody

[Pedro F. Giffuni]

Welcome zhong zhao!

It's nice to see people from China joining.. I guess this
project will be really alive in all timezones! :).

Pedro.

--- On Wed, 9/14/11, 赵忠  wrote:
...
> Hi all:
> I am working for the company, RedFlag 2000(China),and start
> to develope office suit two months ago. Till now, my work is
> mainly to fix bugs related to SC,SD and SW modules,and I
> have a strong willing to participate AOOo community,and
> render my contributions.Thanks!
> 
> Best Regards!
> 
> zhong zhao
> 
> 2011-09-15
> 
> 
> Beijing Redflag Chinese 2000 Software Co., Ltd.
> Building No.2, Block A, Huilongsen, 18 Xihuan Nanlu
> Beijing Economic-Technological Development Area
> 100176 Beijing - P.R.China
> -- 
> 赵忠
> 中企动力 应用开发部
> 手机: 15201238409
> 邮编:
>

RE: How to do with glibc-2.1.3 in AOOo?

[Pedro F. Giffuni]

--- On Wed, 9/14/11, Dennis E. Hamilton  wrote:
..
> Backing up a little.  I don't
> know if the original BSD license is a problem for Apache,
> but it becomes a problem downstream, so it is good to avoid
> having to carry that license and a NOTICE file about it
> around in Apache OOo.
>

Well, having both we obviously choose the less restricted.

 
> LESS RELEVANT: I've been looking for a good getopt( ) for
> my own use on some other projects, and the Todd Miller
> versions seems to be a good starting point.  It is not
> what I would use, but I would use it as a compatibility
> check.
>

If you want to use the standard version you should compare
against this:
http://pubs.opengroup.org/onlinepubs/009695399/functions/getopt.html

of course you can customize it but then I'd suggest renaming it
to something else. 

> Question: Is it always sufficient to be limited to char[]
> or would a w_char[ ] or even UTF-8 version be more suitable
> these days?  Just curious.
>

For command line options I think the normal char is enough
but if you have special needs I guess you can customize it.
Again I would avoid namespace conflicts with libc.

cheers,

Pedro. 

RE: How to do with glibc-2.1.3 in AOOo?

[Pedro F. Giffuni]

Ahem ...

Guys;

--- On Wed, 9/14/11, Dennis E. Hamilton  wrote:
...
> If you list the functions you have in
> mind, and the names of the headers normally used to
> introduce their signatures, I will double-check the VC++
> 2008 and VC++ 2010 libraries to see what the status
> is.  
>

We are far from being the only unixy port to Windows:
A quick google for "getopt_long Windows" returns:

http://opensource.apple.com/source/Kerberos/Kerberos-47/KerberosFramework/Kerberos5/Sources/util/windows/getopt_long.c

I think it's a matter of someone with a Windows compiler
to just go over the code and build a small compatibility
library.

Can we first merge mingwport35 CWS, though? I suspect that
would touch some of those files and I don't want
to introduce conflicts to the Oracle updates just yet.

Pedro.

Re: How to do with glibc-2.1.3 in AOOo?

[Pedro F. Giffuni]

--- On Wed, 9/14/11, Michael Stahl wrote:
...
> > 
> > In FreeBSD we were using an independent library in
> some ports to
> > support getopt_long but the regular library now
> supports the GNU
> > extensions. If it's needed it can be taken from
> there.
> 
> if it's not in a C standard at least 20 years old then
> usually MSVC doesn't have it.
>

Yes :(. At least configure/autoconf could learn to
avoid building the extra stuff on linux/BSD. 

...
> 
> only reason why OOo ships STLport is ABI compatibility
> of the URE and for C++ UNO extensions.
> 
> we wanted to get rid of it for OOo 4.0 anyway.
>

Sounds like something we could anticipate for AOOo
too. The specific extension that requires it should
provide it.

Pedro.

Re: The OOo Community Wiki handover of activities

[Pedro F. Giffuni]

Hello Terry;

Thanks for doing this last stuff for us!

--- On Wed, 9/14/11, Terry Ellison  wrote:
...
> 
> 3. I am still concerned about this whole issue of content
> attribution.  IIRC, under the old OCA contributors only
> vested joint rights to Sun/Oracle and free licence on any
> patents.  The base copyright and patents were
> maintained by the originator. The PDL is even tighter of
> contributor rights retention.  So far we have discarded
> all audit of contribution in svn and are currently
> considering doing likewise for documentation content,
> dropping contribution audit trails and defaulting to blanket
> Apache copyright.  As some third parties  might
> take a different view on this, I propose to keep a full
> private archive of the D/B myself as an independent audit
> reference.
>

I am also concerned about this. Two things two note:

1) If we can't get the documentation with attribution or
under an appropriate license we should not host it under
Apache Servers. In other words the Wiki as it is now,
is dead and only for backup purposes.
 
2) Looking around, a lot of the information is obsolete,
or made obsolete as part of the migration, and is probably
not worth migrating at all. Some of this also applies to
the Web Pages: in particular mentions to CVS, Development
team, EIS and SUN specific infrastructure, QA will
probably see changes, etc ..). It's something we will
have to sort out once we have the information in it's
final development environment.
 
> With these changes, I would be happy to put a copy of the
> wiki dump on one of the old OOo servers so that it could be
> pulled by any ooo-dev developers.
> 

It's nice to have that dump to attempt the confluence
conversion. The tools do support extracting information
from the database:
https://studio.plugins.atlassian.com/wiki/display/UWC/UWC+Mediawiki+Notes

but we don't want people to run password crackers on the
database, so removing all user/password information would
be fine.

Again, thanks for taking the time to help rescue this
in a sensible form and enjoy Greece if you're still there!

Pedro.

Re: How to do with glibc-2.1.3 in AOOo?

[Pedro F. Giffuni]

Thanks Tor, this is all good to know!

--- On Wed, 9/14/11, Tor Lillqvist  wrote:
...
> > The question is why do we need
> this? I would think
> > all supported platforms have standard conformant
> > C/C++ libs.
> 
> Yeah, but the code uses non-standard library functions,
> apparently.

Both of these appear to be standard (now?)

> See external/glibc/makefile.mk. Apparently what's needed is
> getopt()

In FreeBSD we were using an independent library in some
ports to support getopt_long but the regular library now
supports the GNU extensions. If it's needed it can be
taken from there.

> and readdir_r().
>

Quote from:

http://womble.decadent.org.uk/readdir_r-advisory.html

"
OpenOffice.org (at least version 1.1.3)
The code that enumerates fonts and plugins in the appropriate directories uses 
a stack buffer of type long[sizeof(struct dirent) + _PC_NAME_MAX + 1]. I can 
only assume this is the result of a programmer cutting his crack with aluminium 
filings. "

I just don't like using extensions but the code has to be
reviewed.
 
> > In the same line of questioning, but not a license
> > issue, why do we need STLport?
> 
> (In LibreOffice we don't use STLport any more on any
> platform.) Your code presumably still relies on some
> STLport stuff on Windows. Anyway, even if AOOo itself
> wouldn't use STLport itself, if you want to be binary
> compatible with binary extensions, those might rely
> on the OOo installation containing a STLport shared
> library so you need to build and ship it.
>

I think we should just follow LO on this one. The
STLport OOo carries is outdated and the latest
versions in sourceforge (2008) are not very well
maintained (broken on MacOS X and BSD, AFAICT).
 
Pedro.

RE: Problem using Java for integration from JBoss 5.1

[Pedro F. Giffuni]

Hi;

ooo-users@ may be more appropriate although I admit that
type of questions may not be that easy to solve there
either :(.

Perhaps on the JBoss lists ...

cheers,

Pedro.

--- On Tue, 9/13/11, Herter, Scott  wrote:

> Thanks, that at least gives me a clue.
> 
> As for the list, I looked around, there isn't much here yet
> so this seemed the best fit.
> 
> Are there other lists that would be better or is the
> project not quite that far along yet?
> 
> Thanks.
> 
> -----Original Message-
> From: Pedro F. Giffuni [mailto:giffu...@tutopia.com]
> 
> Sent: Tuesday, September 13, 2011 2:55 PM
> To: ooo-dev@incubator.apache.org
> Cc: Herter, Scott
> Subject: RE: Problem using Java for integration from JBoss
> 5.1
> 
> Hi;
> 
> I think JBoss is trying to use saxon but the version in
> OpenOffice conflicts with what JBoss expects.
> 
> Installing the complete saxon may work but maybe it's a
> CLASSPATH issue and reinstalling JBoss does the trick. It's
> not an issue to be solved in this list though, except for
> reminding us to replace saxon with Apache Xalan in the
> future :(.
> 
> Pedro.
> 
> --- On Tue, 9/13/11, Herter, Scott 
> wrote:
> 
> > The problem is that we were not using
> > Saxon to begin with, it is something in the OpenOffice
> 3.3 jars that 
> > is causing this.  Unfortunately I have been unable to
> find anything 
> > that says you only need jars x,y, and z in order to
> use the UNO API 
> > from Java to OpenOffice so we just dumped all of them
> in the EAR file.  
> > With earlier versions it didn't seem to matter, now it
> does.  Looks 
> > like I am in for some long nights trying to figure out
> what Jars we 
> > don't really need or we wait for the next version and
> hope the problem 
> > goes away.
> > 
> > Thanks for the help.
> > 
> > -Original Message-
> > From: Pedro F. Giffuni [mailto:giffu...@tutopia.com]
> > 
> > Sent: Tuesday, September 13, 2011 12:57 PM
> > To: ooo-dev@incubator.apache.org
> > Cc: Herter, Scott
> > Subject: Re: Problem using Java for integration from
> JBoss
> > 5.1
> > 
> > Interesting ...
> > 
> > We carry an older version of saxon but we don't carry
> saxon9-dom.jar
> > 
> > Newer versions of saxon don't carry saxon9-dom
> either.
> > 
> > Try getting Saxon-B from http://saxon.sourceforge.net/
> > 
> > cheers,
> > 
> > Pedro.
> > 
> > --- On Tue, 9/13/11, Herter, Scott 
> > wrote:
> > ...
> > > We have been using OpenOffice in the past to
> convert RTF documents 
> > > to PDF and to print
> > them.  We have
> > > upgraded and after updating the Jar files in our
> EAR
> > file we now get
> > > an exception:
> > > 
> > > 2011-09-13 10:58:19,725 ERROR [STDERR]
> > > (http-0.0.0.0-8080-1) Error   DOMSource cannot
> be
> > processed: check
> > > that saxon9-dom.jar is on the classpath
> > > 2011-09-13 10:58:19,725 ERROR [STDERR]
> > > (http-0.0.0.0-8080-1)
> > net.sf.saxon.trans.XPathException:
> > > DOMSource cannot be processed: check that
> > saxon9-dom.jar is on the
> > > classpath
> > > 2011-09-13 10:58:19,725 ERROR [STDERR]
> > > (http-0.0.0.0-8080-1)   at
> > > net.sf.saxon.event.Sender.send(Sender.java:226)
> > > 2011-09-13 10:58:19,725 ERROR [STDERR]
> > > (http-0.0.0.0-8080-1)   at
> > >
> >
> net.sf.saxon.IdentityTransformer.transform(IdentityTransformer.java:29
> > > )
> > > 2011-09-13 10:58:19,725 ERROR [STDERR]
> > > (http-0.0.0.0-8080-1)   at
> > >
> >
> com.napersoft.databases.R70.NRUtils.decodeXML(NRUtils.java:1160)
> > > ...
> > > 
> > > Without the OpenOffice 3.3 jar files that code
> works
> > fine, with the
> > > 3.3 Jar files it fails with the message above. 
> The
> > code being invoked
> > > has nothing to do with OpenOffice, it has to do
> with
> > formatting some
> > > XML for display.  I noticed that there is a
> > saxon9.jar as part of the
> > > 3.3 jars and that is included in the manifest as
> a jar
> > file dependency
> > > and it is bundled with the EAR file.  It is like
> some
> > of the Jar files
> > > are replacing or interfering with the
> javax.xml.*
> > packages provided by
> > > JBoss.
> > > 
> > > Is there some minimal set of 3.3 jars I can use?
> > Most of the time we
> > > are loading an RTF document and converting it to
> PDF
> > or printing it.
> > > We also use cursors to search for bookmarks and
> insert
> > page breaks as
> > > well as get a page count.
> > > 
> > > Any help would be appreciated.
> > > 
> > > Thanks.
> > > 
> > > 
> > 
> > 
> > 
> > 
> 
> 
> 
>

RE: Problem using Java for integration from JBoss 5.1

[Pedro F. Giffuni]

Hi;

I think JBoss is trying to use saxon but the version in
OpenOffice conflicts with what JBoss expects.

Installing the complete saxon may work but maybe it's a
CLASSPATH issue and reinstalling JBoss does
the trick. It's not an issue to be solved in this list
though, except for reminding us to replace saxon with
Apache Xalan in the future :(.

Pedro.

--- On Tue, 9/13/11, Herter, Scott  wrote:

> The problem is that we were not using
> Saxon to begin with, it is something in the OpenOffice 3.3
> jars that is causing this.  Unfortunately I have been
> unable to find anything that says you only need jars x,y,
> and z in order to use the UNO API from Java to OpenOffice so
> we just dumped all of them in the EAR file.  With
> earlier versions it didn't seem to matter, now it
> does.  Looks like I am in for some long nights trying
> to figure out what Jars we don't really need or we wait for
> the next version and hope the problem goes away.
> 
> Thanks for the help.
> 
> -Original Message-
> From: Pedro F. Giffuni [mailto:giffu...@tutopia.com]
> 
> Sent: Tuesday, September 13, 2011 12:57 PM
> To: ooo-dev@incubator.apache.org
> Cc: Herter, Scott
> Subject: Re: Problem using Java for integration from JBoss
> 5.1
> 
> Interesting ...
> 
> We carry an older version of saxon but we don't carry
> saxon9-dom.jar
> 
> Newer versions of saxon don't carry saxon9-dom either.
> 
> Try getting Saxon-B from http://saxon.sourceforge.net/
> 
> cheers,
> 
> Pedro.
> 
> --- On Tue, 9/13/11, Herter, Scott 
> wrote:
> ...
> > We have been using OpenOffice in the
> > past to convert RTF documents to PDF and to print
> them.  We have 
> > upgraded and after updating the Jar files in our EAR
> file we now get 
> > an exception:
> > 
> > 2011-09-13 10:58:19,725 ERROR [STDERR]
> > (http-0.0.0.0-8080-1) Error   DOMSource cannot be
> processed: check 
> > that saxon9-dom.jar is on the classpath
> > 2011-09-13 10:58:19,725 ERROR [STDERR]
> > (http-0.0.0.0-8080-1)
> net.sf.saxon.trans.XPathException:
> > DOMSource cannot be processed: check that
> saxon9-dom.jar is on the 
> > classpath
> > 2011-09-13 10:58:19,725 ERROR [STDERR]
> > (http-0.0.0.0-8080-1)   at
> > net.sf.saxon.event.Sender.send(Sender.java:226)
> > 2011-09-13 10:58:19,725 ERROR [STDERR]
> > (http-0.0.0.0-8080-1)   at
> >
> net.sf.saxon.IdentityTransformer.transform(IdentityTransformer.java:29
> > )
> > 2011-09-13 10:58:19,725 ERROR [STDERR]
> > (http-0.0.0.0-8080-1)   at
> >
> com.napersoft.databases.R70.NRUtils.decodeXML(NRUtils.java:1160)
> > ...
> > 
> > Without the OpenOffice 3.3 jar files that code works
> fine, with the 
> > 3.3 Jar files it fails with the message above.  The
> code being invoked 
> > has nothing to do with OpenOffice, it has to do with
> formatting some 
> > XML for display.  I noticed that there is a
> saxon9.jar as part of the 
> > 3.3 jars and that is included in the manifest as a jar
> file dependency 
> > and it is bundled with the EAR file.  It is like some
> of the Jar files 
> > are replacing or interfering with the javax.xml.*
> packages provided by 
> > JBoss.
> > 
> > Is there some minimal set of 3.3 jars I can use? 
> Most of the time we 
> > are loading an RTF document and converting it to PDF
> or printing it.  
> > We also use cursors to search for bookmarks and insert
> page breaks as 
> > well as get a page count.
> > 
> > Any help would be appreciated.
> > 
> > Thanks.
> > 
> > 
> 
> 
> 
>

Re: Problem using Java for integration from JBoss 5.1

[Pedro F. Giffuni]

Interesting ...

We carry an older version of saxon but we don't
carry saxon9-dom.jar

Newer versions of saxon don't carry saxon9-dom either.

Try getting Saxon-B from http://saxon.sourceforge.net/

cheers,

Pedro.

--- On Tue, 9/13/11, Herter, Scott  wrote:
...
> We have been using OpenOffice in the
> past to convert RTF documents to PDF and to print
> them.  We have upgraded and after updating the Jar
> files in our EAR file we now get an exception:
> 
> 2011-09-13 10:58:19,725 ERROR [STDERR]
> (http-0.0.0.0-8080-1) Error   DOMSource
> cannot be processed: check that saxon9-dom.jar is on the
> classpath
> 2011-09-13 10:58:19,725 ERROR [STDERR]
> (http-0.0.0.0-8080-1) net.sf.saxon.trans.XPathException:
> DOMSource cannot be processed: check that saxon9-dom.jar is
> on the classpath
> 2011-09-13 10:58:19,725 ERROR [STDERR]
> (http-0.0.0.0-8080-1)   at
> net.sf.saxon.event.Sender.send(Sender.java:226)
> 2011-09-13 10:58:19,725 ERROR [STDERR]
> (http-0.0.0.0-8080-1)   at
> net.sf.saxon.IdentityTransformer.transform(IdentityTransformer.java:29)
> 2011-09-13 10:58:19,725 ERROR [STDERR]
> (http-0.0.0.0-8080-1)   at
> com.napersoft.databases.R70.NRUtils.decodeXML(NRUtils.java:1160)
> ...
> 
> Without the OpenOffice 3.3 jar files that code works fine,
> with the 3.3 Jar files it fails with the message
> above.  The code being invoked has nothing to do with
> OpenOffice, it has to do with formatting some XML for
> display.  I noticed that there is a saxon9.jar as part
> of the 3.3 jars and that is included in the manifest as a
> jar file dependency and it is bundled with the EAR
> file.  It is like some of the Jar files are replacing
> or interfering with the javax.xml.* packages provided by
> JBoss.
> 
> Is there some minimal set of 3.3 jars I can use?  Most
> of the time we are loading an RTF document and converting it
> to PDF or printing it.  We also use cursors to search
> for bookmarks and insert page breaks as well as get a page
> count.
> 
> Any help would be appreciated.
> 
> Thanks.
> 
>

Re: Is there anything we can do to make AOOo code more usable by LibreOffice?

[Pedro F. Giffuni]

Hi Rob;

--- On Mon, 9/12/11, Rob Weir wrote:
..
> 
> I'd summarize it as saying that merging code Apache code
> into LibreOffice will be really difficult, especially
> since LibreOffice has made widespread source changes.
> 
> Is there anything we can do to help LibreOffice out here?
>

Develop faster ... do everything they do ... just kidding! ;).

They have done some things that we want to do too but
all in all we are mostly standing still (for good reasons,
we want to be stable in our first release) and it's them
diverging: ultimately if they want to be different they
will be.
 
> 
> Anything else we should be doing? (Or not doing?)
>

At this point we have to try to rescue all we can from
Oracle: this means getting most all the useful stuff
from the CWSs, which is of benefit to all the community.

We also have to replace some copyleft code, and what we
have to do here is not simply remove it but instead
replace it with stuff so good that LO will want to go
through the effort of bringing our changes.

Hmm.. there are also 24 issues they identified in our
code and fixed in their's.

We may end up catching up in many things but at the end
I do think there will be a situation where LO and OO
differentiate significantly: I don't think that's
necessarily bad though.

cheers,

Pedro.

Re: Automated Builds and Releases

[Pedro F. Giffuni]

--- On Mon, 9/12/11, Matt Richards  wrote:
...
> Quick question (or perhaps a discussion point). With
> all this talk about how things used to be built in a
> data center in Hamburg. I am wondering how the
> release/build process works with Apache projects. Does the
> ASF provide facilities for automated builds or releases?
> Is this something each project contributor needs to do
> on their own?
>

This was pointed to in another thread:

http://ci.apache.org/#buildbot

cheers,

Pedro. 
 

Re: [repo] EIS is down

[Pedro F. Giffuni]

--- On Sun, 9/11/11, Eike Rathke  wrote:

> ... But the "ready for QA" and
> "approved by QA"
> states are lost. Or did someone take notes on those?
>

FWIW,

Michael Stahl mentioned these on 21.08.2011
__
readyforQA 3.4:

mh8tz
sw34bf06
mingwport35
tkr41
__

and it looks like he rescued mingwport35.

Pedro. 

Re: [code][repo] Integration of CWSs, HOW-TO with hg and git svn and stgit

[Pedro F. Giffuni]

Hi,

Excuse the newcomer ignorance ...

--- On Sat, 9/10/11, Michael Stahl wrote:
...
> 
> and i completely forgot to mention that i've got a linear
> MQ patch series applying against OOO340 that contains the
> following:
> 
> ooo340fixes
> mingwport35
> 
> ause131
> ause130
> writerfilter10
> gnumake4
> sd2gbuild
> 
> (second group is for 3.5 so can't be committed to SVN
> now...)
> 

Does gnumake4 save us from dmake? I suspect no one
here wants to maintain dmake in apache-extras if we
can kill it.

Pedro.

Re: [repo] External sources, ICU (was: Who wants to build OpenOffice?)

[Pedro F. Giffuni]

Hi Mathias;

--- On Fri, 9/9/11, Mathias Bauer wrote:
...
> 
> If we can be sure about the IP situation, we should at
> least add copyright headers to the files, shouldn't we?
> Or put a license file into the repository.
>

The standard Apache policy seems to be to add them to the
NOTICE file:

http://www.apache.org/legal/src-headers.html
 
cheers,

Pedro.

Re: [repo] External sources, ICU (was: Who wants to build OpenOffice?)

[Pedro F. Giffuni]

Hi Eike;

--- On Fri, 9/9/11, Eike Rathke wrote:

> > 
> > There was also a bug with Arab glyphs but it was not
> specific
> > to the icu version.
> 
> Well, yes, for those exist patches in the icu module's
> directory, that's the easy case. What I was referring
> are changes in other modules because of an upgrade of
> ICU, e.g. mostly in i18npool, vcl and sw.
>

The fix for Arab glyphs was in vcl, I couldn't find other
changes. Unfortunately the web interfaces to GIT simply
suck and it's very difficult to find changes like that.

I also have to be careful of avoiding GPL contamination
when looking for changes :(.

Hmm... there is Bug 115897 and you own Bug 104310 but
neither of them has patches.

cheers,

Pedro.

RE: [wiki] Migration - A TerryE Clipping Collection [LONG]

[Pedro F. Giffuni]

--- On Thu, 9/8/11, Dennis E. Hamilton wrote:
...
> I see you closed INFRA-3917.
>

I like to clean my own mess, yes.
 
> Keep in mind that there appear to be others willing to
> struggle with Confluence migration (CWiki?).
>

That makes me very happy!

Anyone can reopen the issue: the problem I see is that
it's basically only infra@ that can do this conversion:
I have no idea if/how someone else can mirror the original
information and assuming we can get a dump (which will
likely be big) after running the conversion it has to
be uploaded in the CWiki server for review.
 
> A problem to consider in contingency planning: What it
> means to lock down the current wiki during conversion. 
> And is the MW kept running for read-only viewing while
> conversion takes place, either bit by bit or
> wholesale?   Parallel live operation does not
> appear practical.
>

It depends: if the conversion script is fast and we are
not really editing our MW VM, I wouldn't worry about
locking, specially just for a test conversion. If
we see the test conversion could produce some
workable result we could use a snapshot.

I agree it will be tough but if we could rescue say
60% of the information, it would certainly be worth it.

> I think Confluence migration remains as a
> potentially-necessary Plan B or a potential following Plan A
> if needed for the long run.  The analysis TerryE
> provided suggests that it won't be easy whenever it is
> done.  I'm thinking it should not be done first if MW
> can be operated in the short term.
>

I agree, there's just not anything I can personally do
about it and this being about *doing* and not just
proposing I felt it was a matter of honesty to close
the issue :(.

Pedro.

Re: [repo] External sources, ICU (was: Who wants to build OpenOffice?)

[Pedro F. Giffuni]

Hi;

--- On Thu, 9/8/11, Mathias Bauer  wrote:

> 
> Which version of ICU is used in LibreOffice? If they use a
> newer one,
> this probably can tell us about possible "surprises".
>

The FreeBSD port uses 4.8.1 (with local patches). so it
looks like they use "system icu" already.  

I have also seen reports about some versions of LO being
unstable but I have no basis to say they are caused
by ICU or any other local change so let's leave it at
that before I get accused of spreading FUD.

Pedro.

RE: [wiki] Migration - A TerryE Clipping Collection [LONG]

[Pedro F. Giffuni]

--- On Thu, 9/8/11, Dennis E. Hamilton  wrote:
...
> Pedro, just a quick clarification,
> 
> My understanding is that Infra doesn't do content
> conversions of the kind we are talking about.
> 
> It is all volunteer work and it is up to the PPMC to
> resource such things. Infrastructure provided the gear and
> the platform/stack. 
>

OK, I am afraid it simply impossible then: I don't have
the resources nor it would be easy for me to get all the
MediaWiki content.

If someone from infra@ is listening, please just
close INFRA-3917.

Pedro.

Re: [wiki] Migration - A TerryE Clipping Collection [LONG]

[Pedro F. Giffuni]

--- On Wed, 9/7/11, Dave Fisher wrote:
...
> > 
> > Please hold your horses. Terry is not here, he is in
> > his way to Greece, and we are just exploring the few
> > options that are left.
> > 
> > Conversion from MW to confluence may be painful for
> > us but hopefully would be much easier for infra@.
> > (they haven't said anything about it yet but I am
> > pretty sure exploring this will take time).
> > 
> > Updating MW (which must be done for many good
> > reasons, including security) would seem more logical
> > but still has pain for both us and infra@.
> 
> But Drew is still here and he is being coached. That said,
> please go ahead with your experiment. I recall your
> mentioning this idea in June.
>

Indeed, I think the MW is plan A, but we can always
have a plan B.

I created JIRA INFRA-3917 (hope I did it right) and
estimated 2 weeks, but I am sure the infra guys
will correct that or will just let us know if
it's not possible (if they can't I doubt anyone
else does).
 
cheers,

Pedro.

Re: [wiki] Migration - A TerryE Clipping Collection [LONG]

[Pedro F. Giffuni]

--- On Wed, 9/7/11, Alexandro Colorado wrote:
..
> 
> I also have not kept up with the discussion but reading
> Terry's comments there seem to be a very huge task to
> migrate out of Mediawiki. However then I see that "due
> to lack of Mediawiki support - we are moving to
> Confluence".
> Isnt this exactly what Terry describe why would this be
> difficult to do?
> I also don't see any support for confluence products to
> match what mediawiki had. At least any solutions to
> keep the functionality for their content.
> 
> Can you please explain how will you migrate addressing
> Terry's issues on migration?
>

Please hold your horses. Terry is not here, he is in his
way to Greece, and we are just exploring the few options
that are left.

Conversion from MW to confluence may be painful for
us but hopefully would be much easier for infra@.
(they haven't said anything about it yet but I am
pretty sure exploring this will take time).

Updating MW (which must be done for many good reasons,
including security) would seem more logical but still
has pain for both us and infra@.

Pedro.

Re: [repo] External sources, ICU (was: Who wants to build OpenOffice?)

[Pedro F. Giffuni]

--- On Wed, 9/7/11, Eike Rathke wrote:

OK, I accept your reasoning.
...
> 
> > There is also interest in using icu-regex for
> > replacing the copyleft regex and the latest
> > versions seem to have improved a lot.
> 
> Of course, but upgrading ICU at this stage for a 3.4
> release IMHO is not an option.
>
Hmm.. the release.

Apart from the SGA, that doesn't really depend on us,
we need:
- new regex code (where I thought and ICU upgrade would
actually help)
- solve the lcc cpp issue (remove?).
- testing the above.

There are some other issues that may be worked around
for now.

You are the second person that I've heard on this list
saying that the release is near (the first was Marcus).

Perhaps you guys know something that I don't? ;).

cheers,

Pedro.

Re: [repo] External sources, ICU

[Pedro F. Giffuni]

--- On Wed, 9/7/11, Mathias Bauer wrote:

...
> 
> The IP of some of our i18n files is unclear and someone
> (you?) pointed out that they have been copied from ICU.
> We should clean that up. But that is not related to the
> ICU external tarball.
>

Hmm.. I thought we could use the same headers
internally since it's clear ICU will be mandatory.

Pedro. 

Re: Who wants to build OpenOffice?

[Pedro F. Giffuni]

Hi;

--- On Wed, 9/7/11, James Steinbraker wrote:

> I am a OOo user and have been wanting
> to ask but have not had the time. Does anyone know when
> version 3.4 may be released for broad user consumption? That
> is my only question. But I do understand that the code needs
> to be correct before releasing it.
>   - Original Message - 
>

No ETA. Probably not this year although we would all like
surprises.

Pedro.

Re: [repo] External sources, ICU (was: Who wants to build OpenOffice?)

[Pedro F. Giffuni]

--- On Wed, 9/7/11, Eike Rathke wrote:

> 
> I don't see why the current ICU 4.0.1 needed to be updated,
> what "issues with headers" are you referring?
> 
>   Eike
>

I am not sure exactly when the ICU license changed but
the first ICU versions had a restrictive license.

We have some code from ICU in the tree, Matthias'
ApacheMigration list has:

- get new break iterator data from current ICU

There is also interest in using icu-regex for
replacing the copyleft regex and the latest
versions seem to have improved a lot.

While here, we should also be doing these
"easy" tasks from Matthias' list ASAP:

- get new ksc5601.h file from XFree86
- get new odma.h file with suitable license
- sync unixODBC header files with opensource.apple.com

cheers,

Pedro.

Re: Need a volunteer for the Bugzilla templates

[Pedro F. Giffuni]

I did think of that we do want to favor international
feedback plus there cases when it's not too much trouble:

- Documentation.
- diffs (patches) are sometimes very readable despite
the lack of a good description.

I guess some message to give preference to English
should be in place anyways.

Pedro.

--- On Wed, 9/7/11, Reizinger Zoltán  wrote:

> 2011.09.07. 18:10 keltezéssel, Pedro F. Giffuni írta:
> > Great! Thanks to Matt!!
> >
> > One thing I didn't mention and that may be
> > interesting for international users is that
> > the new bugzilla can
> > be customized for other languages.
>
> The internationalization of bugzilla can be
> counterproductive.
> Until now only English bug reports allowed or solved,
> excluding in some 
> cases German, because most of the the developers can deal
> with.
> The translation of bugzilla UI will pretend that you can
> submit bug in 
> your language, that  could create a big mess.
> Or translated bugs not counts, and why consume space on
> "non real" bugs.
> 
> Thanks,
> Zoltan
> >
> > cheers,
> >
> > Pedro.
> >
> > --- On Wed, 9/7/11, Matt Richards  wrote:
> >
> >> I'm willing to give this a healthy
> >> try, if nobody else beats me to it.
> >>
> >> On Tue, Sep 6, 2011 at 9:01 PM, Pedro F. Giffuni
> wrote:
> >>
> >>> (This just required a new subject header)
> >>>
> >>> Hi;
> >>>
> >>> As you know the bugzilla database is working
> already
> >> (very
> >>> well to be honest) but the UI interface
> changes were
> >> not
> >>> brought in due to the extremely outdated
> version
> >> (3.2.10)
> >>> the old site was running.
> >>>
> >>> Apparently it is not a difficult task and it
> would
> >> make
> >>> our users feel more comfortable to get most of
> the
> >> previous
> >>> look and feel.
> >>>
> >>> Mark Thomas, from infrastructure@ has analysed
> the
> >> files
> >>> provided by Oracle here:
> >>> http://openoffice.org/downloads/www/mw/ooo_bz_template.tar.bz2
> >>> and has offered the pointers for anyone
> wanting to
> >> take
> >>> the job (I am attaching his post).
> >>>
> >>> If someone would like this task please let the
> list
> >> know
> >>> so that we don't have a lot of people creating
> JIRA
> >> issues.
> >>> After notifying the list do create a JIRA
> issue:
> >>>
> >>> https://issues.apache.org/jira/browse/INFRA
> >>>
> >>> cheers,
> >>>
> >>> Pedro.
> >>>
> >>> ps. I found this link that may be helpful to
> see what
> >>> we are talking about:
> >>> http://linux.die.net/Bugzilla-Guide/cust-templates.html
> >>>
> >>
> >>
> >> -- 
> >> --Matt
> >>
> 
> 
>

Re: Who wants to build OpenOffice?

[Pedro F. Giffuni]

FWIW,

The external sources include a lot of stuff that is
outdated and there may even be security risks involved.

I think I posted a list of outdated stuff before and
on FreeBSD I made sure we carry natively the latest
versions (with some care for compatibility).

Also there's the issue that was discussed already of
having an external ICU and dictionaries.

I do think that for linux/BSD distributions adding a
list of dependencies would just be better in the long
run, but that would make life more difficult for
Windows.

cheers,

Pedro.

--- On Wed, 9/7/11, Eike Rathke  wrote:

> Hi Mathias,
> 
> On Wednesday, 2011-09-07 00:32:40 +0200, Mathias Bauer
> wrote:
> 
> > >> 6) The bootstrap was pulling down
> dependencies from Hg.  We need to
> > >> get those into SVN or Apache-Extras, right?
> > > 
> > > Yes.
> > 
> > Really? The "dependencies" (I assume these are the
> external tarballs)
> > are not stored in a Mercurial repo.
> 
> Correct, I just overread "hg" and concluded there needs to
> be a place
> for the external tarballs.
> 
> > Nevertheless we have to find a place
> > for them - or to get back to the old procedure that
> stored them inside
> > the repo.
> 
> I wouldn't do that, being part of the repo we'd lose the
> --with-external-tar=... capability and a checkout really
> does not need
> to include them.
> 
> > At least those that have a suitable license.
> 
> Of course.
> 
>   Eike
> 
> -- 
>  PGP/OpenPGP/GnuPG encrypted mail preferred in all private
> communication.
>  Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3  9E96
> 2F1A D073 293C 05FD
>

Re: Need a volunteer for the Bugzilla templates

[Pedro F. Giffuni]

Great! Thanks to Matt!!

One thing I didn't mention and that may be interesting
for international users is that the new bugzilla can
be customized for other languages.

cheers,

Pedro.

--- On Wed, 9/7/11, Matt Richards  wrote:

> I'm willing to give this a healthy
> try, if nobody else beats me to it.
> 
> On Tue, Sep 6, 2011 at 9:01 PM, Pedro F. Giffuni wrote:
> 
> > (This just required a new subject header)
> >
> > Hi;
> >
> > As you know the bugzilla database is working already
> (very
> > well to be honest) but the UI interface changes were
> not
> > brought in due to the extremely outdated version
> (3.2.10)
> > the old site was running.
> >
> > Apparently it is not a difficult task and it would
> make
> > our users feel more comfortable to get most of the
> previous
> > look and feel.
> >
> > Mark Thomas, from infrastructure@ has analysed the
> files
> > provided by Oracle here:
> > http://openoffice.org/downloads/www/mw/ooo_bz_template.tar.bz2
> > and has offered the pointers for anyone wanting to
> take
> > the job (I am attaching his post).
> >
> > If someone would like this task please let the list
> know
> > so that we don't have a lot of people creating JIRA
> issues.
> > After notifying the list do create a JIRA issue:
> >
> > https://issues.apache.org/jira/browse/INFRA
> >
> > cheers,
> >
> > Pedro.
> >
> > ps. I found this link that may be helpful to see what
> > we are talking about:
> > http://linux.die.net/Bugzilla-Guide/cust-templates.html
> >
> 
> 
> 
> -- 
> --Matt
> 

Re: Status of existing OOo user guides

[Pedro F. Giffuni]

--- On Wed, 9/7/11, Alexander Thurgood wrote:

> Le 06/09/11 05:34, Jean Weber a écrit :
> 
> Hi Jean, all,
> 
> 
> >> I am afraid we must still do this. Perhaps it's
> >> easier to find the people that oppose ..
> >> Can we legally make a call to everyone that
> >> opposes the change to speak up before
> >>  a certain deadline?
> > 
> > 
> > I don't know if that would be legal, but even if it
> > is, I think it would be very difficult to do
> > that in a fair way.
> > Where are you going to make this call? On a mailing
> > list that many early contributors no longer subscribe 
> > to? On a website that they don't visit any more?
> 
> You are correct in your understanding that such an approach
> would not be legal, at least in many jurisdictions. Copyright
> does not transfer by right of silence in many instances. I
> for one, for whatever insignificant part I may have in the
> current documentation (Draw, Database - English and French),
> oppose changing the terms under which I initially contributed.
>

It was a bad idea, and wasn't aware that the docs were hosted
outside the OpenOffice.org website. What we are trying to do
is save all the information that will disappear when the old
OpenOffice.org site is shutdown. Any information we can't
get under a license accepted by ASF or relocated somewhere
else dies.

Since your guides are not in imminent danger with the
migration and they are pretty much an independent effort,
I don't think we should spend any energy on it, at least
not during the project incubation phase. 
 
> I may choose to provide new material according to "the
> Apache Way" in the future, but the heavy handedness I
> have seen elsewhere on this list has provided me with
> no incentive to be a part of the project thus far.
>

Being an independent effort you can take your own
decisions to suit better your end users, I don't
see how the transitory decisions taken here have
any effect on that, but again, it's your decision.

cheers,

Pedro.

Fwd: Need a volunteer for the Bugzilla templates

[Pedro F. Giffuni]

(This just required a new subject header)

Hi;

As you know the bugzilla database is working already (very
well to be honest) but the UI interface changes were not
brought in due to the extremely outdated version (3.2.10)
the old site was running.

Apparently it is not a difficult task and it would make
our users feel more comfortable to get most of the previous
look and feel.

Mark Thomas, from infrastructure@ has analysed the files
provided by Oracle here:
http://openoffice.org/downloads/www/mw/ooo_bz_template.tar.bz2
and has offered the pointers for anyone wanting to take
the job (I am attaching his post).

If someone would like this task please let the list know
so that we don't have a lot of people creating JIRA issues.
After notifying the list do create a JIRA issue:

https://issues.apache.org/jira/browse/INFRA

cheers,

Pedro.
--- On Tue, 9/6/11, Mark Thomas wrote:

> 
> You don't need to be a Bugzilla expert to do the migration.
> Templates was one of the first things I got involved in
> with ASF infrastructure and I no idea how the templates
> worked before I started.
> 
> What is required is some folks that are willing to do the
> work. I can provide them with some pointers to get started.
> It really isn't that hard. I've taken a quick look at the
> custom templates and my initial impressions are:
> - there are ~25 files that need to be migrated
> - most changes are relatively simple
> - not all changes will be required
> 
> On a (sort of) related topic please don't e-mail
> infrastructure folks directly. We try to avoid private
> e-mail at the ASF and many folks simply ignore e-mail
> that isn't on the appropriate list.
> 
> If you have a question for infrastructure:
> - use infrastruct...@apache.org;
> or
> - contact us on the #asfinfra IRC channel on freenode
> If there is something you need infrastructure to do
> - use Jira; or
> - contact us on the #asfinfra IRC channel on freenode
>   (we may still ask you to file a Jira)
> If there is a security problem with ASF infrastructure
> - e-mail r...@apache.org
> 
> This conversation, for example, should be on infrastruct...@apache.org
> (cc'd)
> 
> Cheers,
> 
> Mark
> 
>

ps. I found this link that may be helpful to see what
we are talking about:
http://linux.die.net/Bugzilla-Guide/cust-templates.html

Re: [DISCUSS] Is it worth looking at Confluence Wiki Again?

[Pedro F. Giffuni]

Hello;

--- On Tue, 9/6/11, Dave Fisher  wrote:

> Pedro has already gone over to check
> with Infrastructure about doing a test.
> 
...
> 
> Regards,
> Dave
>

Yes, here is the post I sent to the infrastructure guys.
I guess they have the MW data and the confluence know-how
but it will probably take some time to evaluate this so
we cannot discard the MediaWiki VM just yet.

Pedro.

Hi guys;

Sometime ago I suggested this utility on the ooo-dev list:

https://studio.plugins.atlassian.com/wiki/display/UWC/Universal+Wiki+Converter

I didn't follow up on it because, as you know, there was a
volunteer from the OOo community doing the MediaWiki
configuration.

Since the volunteer has left, perhaps infra could do a test
conversion? This would probably not go as well as the bugzilla
conversion but I think it would make it easier since we
wouldn't have to find another admin and have the extra problems
related to adapting new software to the Apache Infrastructure.

Let me know if using this would be viable and you would like me
to raise a JIRA issue.

Pedro.

Re: [DISCUSS] Announcing Apache ooo Bugzilla on OpenOffice.org Lists

[Pedro F. Giffuni]

I made a call for this before but maybe it was lost:

Do we have a bugzilla UI expert here?

I have just learned that indeed the templates for
the older bugzilla are available.

cheers,

Pedro.  

Re: [legal] ICLA paragraph 7

[Pedro F. Giffuni]

--- On Tue, 9/6/11, Rob Weir  wrote:

> On Tue, Sep 6, 2011 at 3:48 PM, Pedro F. Giffuni wrote:
> >
> >
> > --- On Tue, 9/6/11, Rob Weir 
> wrote:
> >
> >>
> >> So I don't think we can give an answer set in
> stone.
> >
> > Again, section 5 of the Apache License is clear
> enough.
> >
> > Pedro.
> >
> 
> True.  I could also send an email that says "I promise
> to pay Pedro $1 million dollars". 

So *you* are the guy sending me email from Nigeria? ;-).

> But wouldn't you feel better having that in a
> signed document?  I sure would.
>

Having the contribution in a mailing list or in
a bugzilla report is equivalent to getting the
money in the bank.

It doesn't matter if people didn't read the license
or if they got it as part of LibreOffice: if they
contribute to us, and they don't state otherwise,
it is under AL2.

Pedro.

Re: [legal] ICLA paragraph 7

[Pedro F. Giffuni]

--- On Tue, 9/6/11, Rob Weir  wrote:

> 
> So I don't think we can give an answer set in stone. 

Again, section 5 of the Apache License is clear enough.

Pedro.

Re: [DISCUSS][wiki] Migration (was Re: Who Wants to build OpenOffice?)

[Pedro F. Giffuni]

Hello;

I have not been to involved with that process lately but
my understanding is:

- Infra requires a update to recent version of the
MediaWiki software.
- It would be preferable to have no hacks or no
non-standard extensions.
- They want to have documentation concerning the
maintenance of the system.  

Additionally they would prefer to use a FreeBSD jail,
but this is not mandatory. I was considering stepping
in for this last issue but I have no MediaWiki expertise
and having me as another guy learning is probably not
helpful at this time.

Pedro.

--- On Tue, 9/6/11, Matt Richards  wrote:
...
> Well, I thought Terry has resigned
> from the project according to another
> thread, leaving the wiki migration at a bit of a stand
> still. Figured I
> could step in and pick up where he left off on this. Am I
> able to, as a
> non-contributor reach out to Apache Infra on this (from
> what I read it seems
> the infra ML are for existing contributors only)? Not sure
> who all is
> involved at this point.
> 
> On Tue, Sep 6, 2011 at 12:28 PM, Dave Fisher 
> wrote:
> 
> > On Sep 6, 2011, at 10:02 AM, Dennis E. Hamilton
> wrote:
> >
> > > My understanding that it really is a test build
> and it has *not* been
> > maintained in synchronization with the OpenOffice.org
> operating version.  So
> > if that system started to be used as a production
> instance separate from
> > OpenOffice.org, it would be a fork and there would be
> some issues with that.
> >
> > The plan was to put the existing wiki into read only
> and then do a final
> > export. That export would be used to build the final
> ooo-wiki. The next step
> > is to change the DNS. Once DNS is complete branding
> changes will be made.
> >
> > >
> > > Also, I don't believe that would be an acceptable
> arrangement for Apache
> > Infrastructure, for important operational
> reasons.  Someone from there can
> > explain the rules for having a MediaWiki server being
> sustained.
> >
> > Terry has said he will finish the work. It is possible
> that Drew can do it.
> > I know that Terry was documenting everything for
> Infrastructure.
> >
> > Perhaps you should ask infra what they will require
> given the events of the
> > last days.
> >
> > I also wonder what moderation and administrative
> situation exists on the
> > Wiki and if there is any overlap beyond Terry and Drew
> between these two
> > groups.
> >
> > Regards,
> > Dave
> >
> > PS. A lot of us are older, let's have some
> consideration for other's health
> > and stress levels.
> >
> I totally understand real life/health needs to come before
> any of these
> types of projects. No problem.
> 
> 
> >
> > >
> > > - Dennis
> > >
> > > -Original Message-
> > > From: Matt Richards [mailto:mricha...@gmail.com]
> > > Sent: Tuesday, September 06, 2011 08:32
> > > To: ooo-dev@incubator.apache.org
> > > Subject: Re: [DISCUSS][wiki] Migration (was Re:
> Who Wants to build
> > OpenOffice?)
> > >
> > > As far as point 2, I thought Terry had completed
> the all of the migration
> > > work and all that was left was to create a final
> export and cut over the
> > DNS
> > > entries? In my mind, if there is already a lot of
> content on the MW and
> > the
> > > Apache Foundation allows us to continue to use
> it, why not?
> > >
> > > On Tue, Sep 6, 2011 at 7:19 AM, Rob Weir 
> wrote:
> > >
> > >> On Tue, Sep 6, 2011 at 12:51 AM, Pedro F.
> Giffuni  > >
> > >> wrote:
> > >>> Hmm ...
> > >>> It looks like  I missed where the
> decision to use MediiaWiki and
> > >> deprecate confluence
> > >>> was taken. I guess it was arranged with
> infra as long as MW is up to
> > date
> > >> and
> > >>> the extensions are documented.
> > >>>
> > >>> I am not complaining though: it sounds
> like lazy consensus in action
> > plus
> > >> we can
> > >>> always change mind later on and try the
> conversion script.
> > >>>
> > >>
> > >> Do you have a
> counter-argument?   I think the factors are
> at play were:
> > >>
> > >> 1) We have a huge amount of content already
> in MediaWiki from the
> > >> legacy project. Although it might be
> converted to Confluence, the
> > >> effort would be large.
> > >>
> > >> on the other hand
> > >>
> > >> 2) MediaWiki was not supported by Apache
> Infrastructure and getting it
> > >> supported and migrated would require a lot of
> admin work
> > >>
> > >> So far, it looks like the admin effort has
> made more progress than the
> > >> translation effort.   Maybe
> not a final decision, but that is how it
> > >> looks to me today.
> > >>
> > >> -Rob
> > >>
> > >>> Pedro.
> > >>
> > >
> > >
> > >
> > > --
> > > --Matt
> > >
> >
> >
> 
> 
> -- 
> --Matt
>

Re: [code][repo] Integration of CWSs

[Pedro F. Giffuni]

Hello Eike;

From what I discussed with Rob there is no objection
on his side wrt to integrating the CWS'.

I was waiting for the FreeBSD port to go through before
pushing this further, but in general the idea here is
that lazy consensus applies: no one objected so the
issue is left for those that actually know what to
integrate.

Perhaps Matthias and you, which seem to know better than
anyone else what to integrate can agree on the order and
just do it?

Pedro.

ps. yes.. I agree this email list is getting just too
cluttered.


--- On Tue, 9/6/11, Eike Rathke  wrote:

> From: Eike Rathke 
> Subject: [code][repo] Integration of CWSs
> To: ooo-dev@incubator.apache.org
> Date: Tuesday, September 6, 2011, 11:50 AM
> Hi,
> 
> And now for something completely different: CODE
> 
> As lined out in
> 
> Message-ID: <20110831191817.gf29...@kulungile.erack.de>
> http://mail-archives.apache.org/mod_mbox/incubator-ooo-dev/201108.mbox/%3c20110831191817.gf29...@kulungile.erack.de%3E
> 
> there are 2 possible approaches to integrate pending CWSs
> and I favoured
> one of them. I've seen no response to that other than
> Pedro's, maybe my
> suggestion was buried too deep in that thread and people
> are too busy
> with fighting over forum and documentation governance. I'm
> tired of
> wading through those piles of mails wasting the project's
> time and
> efforts and putting people off. In the mean time -- I'm
> referring a time
> span of more than the last week that passed since my mail
> -- we could
> have had the CWSs integrated, identified copyright/license
> problematic
> bits of code, and maybe even found some solutions for
> copyleft code
> removal to get things going.
> 
> I offered my help with the CWSs since the beginning, hoping
> that the
> code repository would had been there much earlier. Summer
> here was
> almost non-existing with weather conditions just right to
> keep me
> indoors, but now I will focus on other things, spare time
> life is short
> enough and can be enjoyed.. as for my part that means I'll
> enjoy staying
> away from computer keyboards for some time starting next
> week and have
> fun under the sun.
> 
> For reference, here the body of the mail mentioned above:
> 
> | On Wednesday, 2011-08-31 09:22:46 -0400, Rob Weir wrote:
> | 
> | > It is a trade-off.  Right now I think the most
> important task is to
> | > review the IP of the code and get that fixed where
> needed.  Right now
> | > all code in the repository is in one of these
> categories:
> | > 
> | > 1) Files that are in the Oracle SGA
> | > 
> | > 2) Files that Oracle owns that are not in their
> original SGA but will
> | > need ot be in their new SGA
> | > 
> | > 3) Files that are from 3rd party open source
> modules, where the code
> | > has a compatible license
> | > 
> | > 4) Files that are from 3rd party open source
> modules, where the code
> | > has an incompatible license
> | > 
> | > 5) Files where we cannot establish accurately their
> origin or license
> | > 
> | > I think the priority should be to identify all files
> in categories #2,
> | > #4 and #5, so we can fix them.
> | > 
> | > If people are adding new code to the repository,
> that introduces a new
> | > category, of changes made by committers, under
> ALv2.  The complexity
> | > would be if they are modify or adding files that are
> in categories #2,
> | > #4, or #5.  If we can avoid that, then I don't
> see a problem.
> | > 
> | > What we want to avoid is having us review a given
> AOOo module, clean
> | > it up from IP perspective, and move on to another
> modules, and then
> | > have it recontaminated by merging in, via a patch or
> CWS integration,
> | > code that is dirty.
> | 
> | CWS integration can be of two categories:
> | 
> | a) CWS does not introduce new code covered by an
> incompatible license,
> |    should not give any problem other than merge
> conflicts if it touches
> |    code that was already removed for #2, #3 or
> #4. All other code newly
> |    introduced in such a CWS is covered by the
> SCA/OCA and hence also
> |    covered by the SGA, if I understood
> correctly.
> | 
> | b) CWS does introduce new code covered by an incompatible
> license, will
> |    pollute the tree anyway and those code parts
> will have to be removed.
> | 
> | So, we can choose:
> | 
> | x) first identify and remove license incompatible code to
> be pointed to
> |    clashes when the CWSs will be integrated,
> additionally lookout for
> |    new license incompatible code when
> integrating CWSs thereafter, or
> | 
> | y) first integrate all CWSs, note down new license
> incompatible code the
> |    CWS introduces, and after all CWSs are
> integrated start the clean-up
> |    of the entire tree. CWSs rarely introduce
> new external code, so new
> |    code that would be covered by an
> incompatible license should be an
> |    exemption.
> | 
> | I'd favour y) because we wouldn't have to deal with
> additional merge
> | conflicts as would be the case with x).
> 
> 
> 

Re: [DISCUSS][wiki] Migration (was Re: Who Wants to build OpenOffice?)

[Pedro F. Giffuni]

Hmm ...
It looks like  I missed where the decision to use MediaWiki and deprecate 
confluence
was taken. I guess it was arranged with infra as long as MW is up to date and
the extensions are documented.

I am not complaining though: it sounds like lazy consensus in action plus we can
always change mind later on and try the conversion script.

Pedro.

Re: Status of existing OOo user guides

[Pedro F. Giffuni]

Hi Jean;

Continuing on the topic of my general ignorance ...

--- On Mon, 9/5/11, Jean Weber  wrote:
...
> 
> It's not clear to me that the user guides produced by
> ODFAuthors are in fact "official documentation" even
> though they are made available as ODT and PDF through
> the OOo wiki.
>

We are talking about the same documents here?

http://documentation.openoffice.org/

Those carry the "Oracle" logo or in older versions the
"Sun" Logos.

Assuming we host the documentation it would have to be
done the "Apache Way" which would mean that the authors
would be really inside the project. If this is so, I
think it would be nice and we should consider it
"official documentation".

I recall someone (maybe you) had said that the
ODFAuthors wanted to keep independent. If they
want to join the podling they are welcome.

There are some things which I think we should consider:

1) Many things are about to change, in particular when
the new UI from Symphony is adopted, so we will have
to do a lot of updating and new documentation anyways.
Obviously all new documentation must be in a license
acceptable to the Apache Foundation.

2) infra@ is not complaining, but the fact the person
doing the MW migration will leave is an issue. We should
be considerate with the limited resources: is there a
technical reason for not using confluence for all new
documentation?

3) The license issue is really important. under all
circumstances documentation without an acceptable
copyright must be contained. In particular, the
confluence wiki must be kept clean. 

I think the logical plan would be to either find a new
home for the MW documentation or migrate what we can
into a new project.

> 
> That would be only a few scattered chapters, because so
> many people have worked on the docs over the years. And
> it only takes one person to say no, I don't agree to
> changing the license, and the chapter is
> contaminated.
>

I am afraid we must still do this. Perhaps it's easier
to find the people that oppose .. Can we legally make
a call to everyone that opposes the change to speak up
before a certain deadline?

We would probably have to deprecate the documentation
that we can't assimilate anyways (yes resistance is
futile).

Pedro. 
 

Re: Status of existing OOo user guides

[Pedro F. Giffuni]

--- On Mon, 9/5/11, Jean Weber  wrote:

...

> 
> We have established that relicensing the existing OOo user
> guides (which are licensed CC-BY) to the Apache license
> is not practical.
> Does this mean, as Rob has suggested, that these guides
> *cannot* be part of the "official" documentation for AOOo
> or only *should not* be part of that doco?
>
Please excuse my ignorance ...

If I understand well:

Despite owning the domain and the servers, the official
documentation is not owned by Sun/Oracle (otherwise it
could be relicensed).

The problem has some similarities with situation in the
forums. It's a transition process.. we have to live with
the ASF rules but there is a status quo that is doing
fine and we don't want to disrupt them.

I would think for now we can keep them running
in the Wikimedia VM that was made for that but we
will have to make some transition plan: contact the
authors that can be contacted (no spiritism, please ;) ),
and transfer the documentation that is "copyright clean"
to the confluence wiki.

cheers,

Pedro. 


 
> I think Rob's suggestions for "boldly going where OOo Docs
> have not
> gone before" are good ones, but they won't happen
> immediately. In the
> short term (for the next release of the software), we are
> most likely
> to have a choice between updated CC-BY-licensed user
> guides, or no
> user guides at all.
> 
> What should I tell the small group that remains from the
> ODFAuthors
> team that has been working on the user guides?
> 
> --Jean
> 
> 

Re: [legal] ICLA paragraph 7

[Pedro F. Giffuni]

Ahh.. found it!

The problem is solved in section 5 of the
Apache License:
___
5. Submission of Contributions.
Unless You explicitly state otherwise, any Contribution intentionally submitted 
for inclusion in the Work by You to the Licensor shall be under the terms and 
conditions of this License, without any additional terms or conditions. 
Notwithstanding the above, nothing herein shall supersede or modify the terms 
of any separate license agreement you may have executed with Licensor regarding 
such Contributions.
___


cheers,

Pedro.

--- On Sun, 9/4/11, Eike Rathke  wrote:


> 
> There are people who won't sign whatever CA, call it
> philosophical
> conception, due to history especially not if it's for OOo.
> If
> contributions are welcome only under iCLA you probably
> won't see them
> showing up here.
> 
>   Eike
> 
> -- 
>  PGP/OpenPGP/GnuPG encrypted mail preferred in all private
> communication.
>  Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3  9E96
> 2F1A D073 293C 05FD
>

Re: [legal] ICLA paragraph 7

[Pedro F. Giffuni]

--- On Sun, 9/4/11, Rob Weir wrote:

> On Sun, Sep 4, 2011 at 1:48 PM, Eike Rathke wrote:
..
> >
> > There are people who won't sign whatever CA, call it
> > philosophical conception, due to history especially
> > not if it's for OOo. If contributions are welcome
> > only under iCLA you probably won't see them
> > showing up here.
> >
>

I agree: none of the projects I usually participate in
ask for signatures. The few that require them (NetBSD
IIRC) only ask for committers to accept a CLA.

OpenOffice is probably a special case wrt patents and
that's a special strength behind the Apache License so
I think it's good in case of big contributions (like
IBM's) to have such a document but otherwise I don't
think it's standard practice on Apache to ask for
signatures for small contributions.
 
> I sometimes wonder if we'd have greater acceptance of the
> iCLA if we called it something else, a name that did not
> include "CLA" in it?
>

It looks like SUN's developer agreement left deep scars
in the community. It's common practice to assume that
developers know and accept the license of the code they
are contributing to. What I've seen in other list (tag
all patches and postings with licenses) is rather
weird.
 
Pedro. 

Re: OpenOffice most annoying bugs

[Pedro F. Giffuni]

--- On Sun, 9/4/11, Marcus (OOo) wrote:

...
> 
> As addition:
> 
> It's also about code quality and stability.
>

I have never said the contrary.
 
> Currently we have already a (relative) stable code with the
> released OOo 3.4 Beta. So, it would be IMHO not clever to
> through in all the new code from the 24 issues, build again
> and get surprised what is now not working.
>

"stable" is such a relative concept. I don't think we are stable
yet (neither is LO), and we have a long way to go before a
release.

Furthermore I am NOT suggesting we apply blindly 24 patches
today and cross fingers to see if works tomorrow.
 
> We have to select very carfully what to integrate.
>

I think that instead of complaining so much about a
list of bugs with fixes that I looked up (and that I will
likely never update again), you could spend time more
constructively criticizing the bugs at a technical level,
or at least pointing out those that you *do* consider
showstoppers.

Personally, being a new guy to this code base, I did the list
just to have an idea of what there is to be found in there. I
do think this can wait after the CWS' are integrated. I also
thought one of the general objectives was bringing the LO-OO
codebases nearer together but it seems that is not really a
priority anymore.

Drawing such a list is not exactly fun and I am, in no position
to *force* anything to be fixed so take the list just as a point
of reference and nothing more.

Also, fwiw, it is not my plan (and never was) to make this a
periodic posting (the heading is actually a pun to a similar
posting at some other list): committers will have to learn
to work as effectively as they can with Bugzilla.

cheers,

Pedro.

Re: OpenOffice most annoying bugs

[Pedro F. Giffuni]

--- On Sun, 9/4/11, Marcus (OOo)  wrote:
...
> > Example 1:
> > - A posting in LO mailinglist from Sept 2010 says:
> > "Creating a 'bug' saw no action in 3 years
> > Here is hoping that posting the patch to this
> > new project will :-)"
> > (There goes one developer that will probably
> > think it twice before submitting new patches here)
> 
> Sorry, clearly not a stopper for me. It doesn't fix a bug
> but introduce a new feature. This shouldn't be a stopper
> candidate.
>

Nahh.. you haven't been doing your homework: that issue was
indeed a bug and the issue has been fixed now. I was
highlighting the effect of ignoring bugs for too long
though: it has an influence on the community as such.
 
> > Example 2:
> > Bug 7065 (Which Marcus considers not to be a
> > showstopper) says in 2003:
> > "I think it is a mistake to future this bug. Page
> > numbering is a very important function of all
> > worprocessing software and its discoverability must
> > at least be increased."
> 
> When an issue is open und unsolved since 2003 then it is
> sad. No doubt. 
> However, it's still not an issue that should suddenly stop
> a release.
> 
> > And after that there are 13 issues closed as
> > duplicates to this same bug.
> >
> > Yes, someone has to review the patches, and the
> applied
> > fixes won't necessarily match the submitted diffs or
> what
> > LibreOffice committed but we do have a good starting
> > point to fix these issues and the wider community has
> > seen a value in fixing them so I do think they have a
> > higher priority.
> 
> Yes and no. It doesn't depend from where the issue or patch
> comes or how 
> old it is. It's about the issue itself, what part of the
> application it covers and its severity.
>

Which is all subjective and basically translates to "whatever
a random developer feels he should be working on today".

Come on.. let's admit: bug fixing never follows a coordinated,
well developed, plan to improve our product, at least not
in a volunteer project. 

What I am saying here is that setting goals is good and a new
Apache release is not around the corner so tagging some bugs
for now as release blocker (or some other less obliging tag
for what I am concerned) doesn't really mean nothing.

cheers,

Pedro.

Re: OpenOffice most annoying bugs

[Pedro F. Giffuni]

--- On Sat, 9/3/11, Raphael Bircher  wrote:
...
> Only because a patch it's included in LibO we should not
> include it automaticly here. There are many reasons to not
> include a pach.
> 
> - Lisence Problems
> - The Patch is not compatible with other Operating system.
> - The patch is bad programmed, eg. only supress a problem
> not solve it.
> 

Feel free to illustrate this in the 24 Bug reports I posted.

> 
> Yes, we should integrate patchs, but the reason should be
> technical only. But Integrate patch to give people the
> feeling they are needed here, no!
>
I have never said we should simply integrate the patches.

I do think having a bug report standing for more than 6
years is not healthy for any project, and the competition
is doing something about it.

If the patches are not acceptable let's close the bugs,
but let's just not keep prolonging the pain of our
end users ;-).

cheers,

Pedro.



 
> Greetings Raphael
> 
> 
> -- My private Homepage: http://www.raphaelbircher.ch/
> 
> 

Re: Fwd: [users] Re: Languages

[Pedro F. Giffuni]

Hi;

--- On Sat, 9/3/11, Dale Erwin  wrote:
...
> 
> Spoken like a true northern Italian bigot... with all due
> respect.
> 
> Please note I did not call you a northern Italian bigot...
> I said you speak like one.  Maybe you are just
> misinformed.
>

I should've thought better before my original posting because
this subject touches deep fibers in people.

I am pretty aware that all italian dialects are proper
languages that predate standard italian. They are very
much alive in basically every city in Italy.

The issue is none of these languages is actually taught
in schools anymore(?) and it's usually the older people
that use them most. I have no objection to any of them
being added to OpenOffice, it's just that many of the
computer related terms (open file, print, etc) are
unlikely to change with respect to the "official"
italian.

Yes, many people argue these languages are a cultural
value and I am OK with them being preserved.

Pedro.

FWIW, .. No I am not from northern Italy.

Re: Fwd: [users] Re: Languages

[Pedro F. Giffuni]

Hi Andrea and Dale;

Ugh... I'll take back everything I wrote ... sorry.

The classification between languages or dialects in Italy,
is something that I know very well not to get into.

Yes, I've had my doze of Naepolitan, Friulian, Roman,
and Triestin.

cheers,

Pedro.

--- On Sat, 9/3/11, Andrea Pescetti  wrote:

> Pedro F. Giffuni wrote:
> > Neapolitan is classified as a dialect, not a language,
> for
> > good reasons.
> 
> It's in ISO 639-2 so it's a language, and it's distinct
> from Italian. Among the local languages spoken in Italy, we
> already fully support the four variants of Sardinian
> according to ISO 639-3 (Campidanese, Gallurese, Logudorese,
> Sassarese) and Friulian according to ISO 639-2.
> 
> The first step would be to add locale data to
> OpenOffice.org so that OpenOffice.org knows that a
> Neapolitan language exists. Once that's in place, you can
> translate the interface and even create dictionaries.
> 
> Eike Rathke is on this list and he's probably the most
> knowledgeable person about this topic, so I'll stop here. I
> remember there were issues with mapping 3-letter codes (like
> "nap", ISO 639-2 for Neapolitan) to the conventions used by
> OpenOffice.org, but this could be a problem from the past.
> 
> > My recomendation is just to add a dictionary with
> Naepolitan
> > terms to the standard italian dictionary.
> 
> This won't work for regional variants of Italian: it will
> break spell checking and/or interoperability. At least in
> this case, where we are speaking of a separate language, the
> only viable solution is to make it known to OpenOffice.org
> by creating locale data for it.
> 
> Regards,
>   Andrea.
> 
>

Re: OpenOffice most annoying bugs

[Pedro F. Giffuni]

--- On Sat, 9/3/11, Rob Weir  wrote:
...
> On Sat, Sep 3, 2011 at 8:42 AM, Pedro F. Giffuni wrote:
> > Hi Marcus;
> >
> > The exact flag in bugzilla is 3.4_release_blocker.
> >
> > Not including *ALL* these 24 bugs for the next
> release
> > would be like saying to our contributors that we
> don't
> > care about them. We are talking about people that
> > spent *their* time coding and gave the preference
> > to contribute to OpenOffice that would now see that
> > their are efforts better appreciated elsewhere.
> >
> 
> I think we should classify the bugs based on their impact
> on the product, not on the identity of the person who
> submitted the patch.

I never did detail identities of contributors. I do think
it's important that they contain code: either by the
submitter or by someone else that found the issue
important enough to take the time to fix it.

The "impact on the product" is something subjective that
ultimately depends on the impact to the end-user, and
here we have users solving their own problems.

This is about meritocracy and community building too:
one unsatisfied developer can cause huge damage to a
project. I'll give you two real immediate examples:

Example 1:
- A posting in LO mailinglist from Sept 2010 says:
"Creating a 'bug' saw no action in 3 years
Here is hoping that posting the patch to this
new project will :-)"
(There goes one developer that will probably
think it twice before submitting new patches here)

Example 2:
Bug 7065 (Which Marcus considers not to be a
showstopper) says in 2003:
"I think it is a mistake to future this bug. Page
numbering is a very important function of all
worprocessing software and its discoverability must
at least be increased."

And after that there are 13 issues closed as
duplicates to this same bug.

Yes, someone has to review the patches, and the applied
fixes won't necessarily match the submitted diffs or what
LibreOffice committed but we do have a good starting
point to fix these issues and the wider community has
seen a value in fixing them so I do think they have a
higher priority.

This is all just IMHO of course, and I am biased as it
took some hours to dig through the archives and look at
all the Bug reports.

cheers,

Pedro.

Re: OpenOffice most annoying bugs

[Pedro F. Giffuni]

Hi Marcus;

The exact flag in bugzilla is 3.4_release_blocker.

Not including *ALL* these 24 bugs for the next release
would be like saying to our contributors that we don't
care about them. We are talking about people that
spent *their* time coding and gave the preference
to contribute to OpenOffice that would now see that
their are efforts better appreciated elsewhere. 

It's just 24 bugs with patches: we can do them all
before the next release (likely to happen next year).

cheers,

Pedro.

--- On Sat, 9/3/11, Marcus (OOo) wrote:

> Am 09/03/2011 04:39 AM, schrieb Pedro F. Giffuni:
> > Hi;
> >
> > I went through the early LibreOffice archives
> > checking which issues from our database they
> > considered for inclusion.
> >
> > I have to say it was a GREAT idea to start
> > from the tip of the Hg development tree as
> > most fixes already appear closed (applied
> > or integrated to a CWS).
> >
> > The following 24 open bugs in our database
> > include patches and have been integrated
> > (in some form) into LibreOffice:
> >
> > Bug 1526 - Small Caps are different sizes twixt Word
> and StarWriter
> > Bug 7065 - A wizard for Page Numbering
> > Bug 61927 - WW6: exporting a document twice replaces
> capital danish characters with squares
> > Bug 76649 - sfx2: html parser support for html with
> missing encoding
> > Bug 80184 - can't add SVG draw documents to gallery
> via API
> > Bug 92341 - WW8: CTL/Thai font convert incorrectly
> when import from MS Office 2003
> > Bug 94007 - Slideshow crashes on exit (multi-screen)
> > Bug 95369 - Writer crash related to input fields
> > Bug 97332 - MS Word 95 export filter does not
> recognize Korean characters
> > Bug 100686 - wizards: Euro converter wizard don't work
> when searching for calc documents in a dir
> > Bug 101057 - merge ww6 and wmf encoding spliter
> > Bug 101100 - allow -fstrict-aliasing
> > Bug 108846 - sfx2: gtk quick starter is still a bit
> sick
> > Bug 111741 - extras: malformed XML file
> > Bug 112387 - extras: updated Hungarian standard.bau
> > Bug 112786 - unotools: make ConfigManager a
> well-behaved singleton
> > Bug 112795 - sfx2: dock windows change position after
> restart of the app
> > Bug 112821 - configure: system mythes is not used when
> configured with --with-system-libs
> > Bug 113141 - fpicker: gtk Save As dialog should show
> all appropriate formats by default
> > Bug 113803 - Add Tower labels
> > Bug 113873 - Russian dictionary for integration
> > Bug 114012 - sd: a11y crash because ctor chain calls
> back into object before ctor is complete
> > Bug 114423 - sfx2: possible use of dangling reference
> > Bug 117017 - ARM optimization for armv6/armv7
> >
> > Perhaps we should label them "3.4 showstopper"
> > or something.
> 
> Showstopper have their own definition. As we have not yet
> defined a new 
> one I've taken the old definition:
> 
> http://wiki.services.openoffice.org/wiki/Showstopper
> 
> Especially these I cannot see as showstopper as from the
> subject:
> 7065, 80184, 113141, 117017
> 
> Marcus
> 
> 
> 
> > Also, someone please close Bugs 96705 and 113874,
> > they have dictionaries under a copyleft license so
> > we won't be including them into Apache OpenOffice.
> > 
> >
> > Of course, I may have missed some fixes, but this
> > should cover all the changes up to March 2011.
> >
> > Also, as was to be expected, the latest commits carry
> > less and less OOo fixes and more bugs of their own.
> > Just a sign that, well ... we are diverging.
> >
> > cheers,
> >
> > Pedro.
> 
> 

Re: OpenOffice most annoying bugs

[Pedro F. Giffuni]

--- On Sat, 9/3/11, Marcus (OOo)  wrote:

> > --- On Fri, 9/2/11, Rob Weir 
> wrote:
> >
> >>
>> Is it worth contacting the authors of these dictionaries to
>> see if they would consider giving it a license we can use?
> 
> Simply +1.
>
No need to vote.. just do it (TM).

I suggest you also start auditing the dictionaries we carry.
I can personally live witouht Croatian but not without Italian.

...
> 
> IMHO we had some discussions about how to continue the
> spell checker. 
> But I cannot remember where it was.
>

I think the conclusion was that we can include hunspell
as a dependency but we cannot carry it in Apache
servers.

Most distributions are carrying pre-packaged
dictionaries for LO anyways.

cheers,

Pedro.

Re: Fwd: [users] Re: Languages

[Pedro F. Giffuni]

Hi Dale;

With due respect to Italy's cultural richness (which I so
much admire being italian myself but not only because of that),
Neapolitan is classified as a dialect, not a language, for
good reasons.

Compared to standard italian you use the same character set
and gramatical rules. Furthermore the computer related terms
that OpenOffice uses are the same as in standard italian.
My recomendation is just to add a dictionary with Naepolitan
terms to the standard italian dictionary.

best regards,

Pedro,

--- On Fri, 9/2/11, Rob Weir  wrote:

> Hi Dale,
> 
> I'm forwarding your question to the Apache list where
> OpenOffice
> development discussions are now taking place. 
> Hopefully someone here
> has an answer to your question, about how to get started
> making a new
> language translation of OpenOffice.
> 
> Regards,
> 
> -Rob
> -- Forwarded message --
> From: Dale Erwin 
> Date: Mon, Aug 29, 2011 at 4:43 PM
> Subject: [users] Re: Languages
> To: us...@openoffice.org
> 
> 
> On 8/29/2011 1:53 PM, Sigrid Carrera wrote:
> >
> > Hello Erwin,
> >
> > On Mon, 29 Aug 2011 12:14:10 -0500
> > Dale Erwin
>  wrote:
> >
> >> If this is not the proper forum, perhaps someone
> could point me to the
> >> proper one, but I am trying to find out what is
> necessary to be done to
> >> have a new language available for OOo.
> >
> > You might have to download a so called "languagepack"
> for the
> > language you want and have to install it alongside
> your OOo version.
> >
> > Once you have installed it, go to Tools ->
>  Options ->  Language
> > settings ->  Language and choose there the default
> language you want.
> > You will have to close OOo completely (even the
> Quickstarter if you
> > use it) and restart OOo for the change to take
> effect.
> >
> > Hope this helps.
> >
> > Sigrid
> 
> >
> 
> After sending my email, I was afraid it would be construed
> that way.
> I don't mean adding a language to my installation that OOo
> already
> supports.  I mean adding a language to those that OOo
> supports.  I'm
> specifically thinking of the Neapolitan language (I dislike
> using the
> term dialect, but it is commonly referred to as an Italian
> dialect).
> 
> 
> --
> Dale Erwin
> Lurigancho, Lima 15 PERU
> 
> http://leather.casaerwin.org
> 
>

Re: OpenOffice most annoying bugs

[Pedro F. Giffuni]

--- On Fri, 9/2/11, Rob Weir  wrote:

> 
> Is it worth contacting the authors of these dictionaries to
> see if they would consider giving it a license we can use? 

My standard boilerplate reply was:

"Please note that we will not receive contributions under
copyleft licenses anymore. We recommend Apache License 2.0
to be consistent with the rest of the suite."

I do think that having their dictionaries in OOo is a
good motivation for them to adopt a less restrictive
license.

The issue here, however, is that we may want to rethink
if we will be carrying dictionaries at all: hunspell
is copyleft.

Pedro.

OpenOffice most annoying bugs

[Pedro F. Giffuni]

Hi;

I went through the early LibreOffice archives
checking which issues from our database they
considered for inclusion.

I have to say it was a GREAT idea to start
from the tip of the Hg development tree as
most fixes already appear closed (applied
or integrated to a CWS).

The following 24 open bugs in our database
include patches and have been integrated
(in some form) into LibreOffice:

Bug 1526 - Small Caps are different sizes twixt Word and StarWriter
Bug 7065 - A wizard for Page Numbering
Bug 61927 - WW6: exporting a document twice replaces capital danish characters 
with squares
Bug 76649 - sfx2: html parser support for html with missing encoding
Bug 80184 - can't add SVG draw documents to gallery via API
Bug 92341 - WW8: CTL/Thai font convert incorrectly when import from MS Office 
2003
Bug 94007 - Slideshow crashes on exit (multi-screen)
Bug 95369 - Writer crash related to input fields
Bug 97332 - MS Word 95 export filter does not recognize Korean characters
Bug 100686 - wizards: Euro converter wizard don't work when searching for calc 
documents in a dir
Bug 101057 - merge ww6 and wmf encoding spliter
Bug 101100 - allow -fstrict-aliasing
Bug 108846 - sfx2: gtk quick starter is still a bit sick
Bug 111741 - extras: malformed XML file
Bug 112387 - extras: updated Hungarian standard.bau
Bug 112786 - unotools: make ConfigManager a well-behaved singleton
Bug 112795 - sfx2: dock windows change position after restart of the app
Bug 112821 - configure: system mythes is not used when configured with 
--with-system-libs
Bug 113141 - fpicker: gtk Save As dialog should show all appropriate formats by 
default
Bug 113803 - Add Tower labels
Bug 113873 - Russian dictionary for integration
Bug 114012 - sd: a11y crash because ctor chain calls back into object before 
ctor is complete
Bug 114423 - sfx2: possible use of dangling reference
Bug 117017 - ARM optimization for armv6/armv7

Perhaps we should label them "3.4 showstopper"
or something.

Also, someone please close Bugs 96705 and 113874,
they have dictionaries under a copyleft license so
we won't be including them into Apache OpenOffice.


Of course, I may have missed some fixes, but this
should cover all the changes up to March 2011.

Also, as was to be expected, the latest commits carry
less and less OOo fixes and more bugs of their own.
Just a sign that, well ... we are diverging. 

cheers,

Pedro.

RE: Request dev help: Info for required crypto export declaration

[Pedro F. Giffuni]

While here,

Can Apache projects rely on Mozilla's nss (MPL)?

I looked for alternatives but I only found the java based
Bouncy Castle:

http://www.bouncycastle.org/

cheers,

Pedro.

--- On Thu, 9/1/11, Dennis E. Hamilton  wrote:

> From: Dennis E. Hamilton 
> Subject: RE: Request dev help: Info for required crypto export declaration
> To: ooo-dev@incubator.apache.org
> Date: Thursday, September 1, 2011, 12:00 AM
> It is simplified and it isn't. 
> But we are doing it out of order.
> 
> Here is the page that I couldn't remember the location of:
> 
> 
> 
>  - Dennis
> 
> -Original Message-
> From: rabas...@gmail.com
> [mailto:rabas...@gmail.com]
> On Behalf Of Rob Weir
> Sent: Wednesday, August 31, 2011 09:31
> To: ooo-dev@incubator.apache.org
> Subject: Re: Request dev help: Info for required crypto
> export declaration
> 
> On Wed, Aug 31, 2011 at 12:29 PM, Dennis E. Hamilton
> 
> wrote:
> > I thought there was a short-circuit/umbrella process
> that doesn't require all of these details.  I thought
> that came up on an old thread, either on the PPMC or in the
> early days of this list.
> >
> > We do need to collect and update the details, but I am
> not so sure we need to file a full-up declaration. 
> There is apparently a simplified procedure and we should
> look for it. (I am not where I can do that right now.)
> >
> 
> Uh... but we need to know the details to know whether we
> can use the
> simplified procedure.
> 
> -Rob
> 
> 
> > -Original Message-
> > From: Mathias Bauer [mailto:mathias_ba...@gmx.net]
> > Sent: Wednesday, August 31, 2011 07:00
> > To: ooo-dev@incubator.apache.org
> > Subject: Re: Request dev help: Info for required
> crypto export declaration
> >
> > Moin,
> >
> > please take my answers with a decent grain of salt,
> I'm not an expert
> > for that area, Matthias Hütsch and Malte Timmermann
> certainly could
> > answer that better, but I don't know if they are
> currently contributing
> > to this list. Hopefully my remarks can help to look at
> the right places.
> >
> > Am 31.08.2011 15:03, schrieb Rob Weir:
> >
> >> There is some paperwork we need to file based on
> OOo use of
> >> cryptography.  Details are on the Apache
> website [1].  I think I can
> >> handle most of the paperwork, provided I can get
> some help, on this
> >> thread, establishing the basic facts.
> >>
> >>
> >> 1) Was something similar every done for
> OpenOffice.org?  Most software
> >> companies are aware of this US export regulation
> and do this
> >> declaration as a matter of routine.  But not
> all open source projects
> >> are as diligent as ASF is.  So it is possible
> that OOo never did this
> >> before.  But if they did, we could reuse much
> of their paperwork.
> >
> > AFAIR Sun did that some time ago, but I'm not 100%
> sure.
> >
> >> 2) We need a list of all uses of cryptographic
> methods in OOo,
> >> including code that we include, but also where we
> enable 3rd party or
> >> OS crypto modules to plugged in.  This
> includes both symmetrical
> >> algorithms (commonly used for encryption) as well
> as asymmetrical
> >> algorithms (for example, public key uses like PGP,
> RSA, TLS, etc.)
> >>
> >> 3) For each method, it looks like we need to state
> whether we authored
> >> the crypto, or name the origin of the code if it
> is a 3rd party.
> >>
> >> The methods I suspect are in OOo are:
> >>
> >> a) For password-protected ODF documents, we use
> the Blowfish block
> >> encryption method.   Where did that
> code come from?
> >
> > It was an own implementation from someone who was
> employed by Sun at
> > that time.
> >
> > In the new 3.4 code we also use AES code from the
> openssl library.
> >
> >> b) What do we support for other document formats,
> such as DOC, OOXML
> >> or legacy StarOffice formats?  Any other
> encryption methods?  If so,
> >> what are they are what was their origin?
> >
> > As none of the former Oracle employed MS filter
> developers is listening
> > here, maybe we could ask Kohei or Caolan from the
> Libre Office crew.
> >
> >> c) We support digital signatures with ODF files as
> well.  What
> >> algorithms are supported?  Is this our
> original code or 3rd party?
> >
> > The code we use is based on the SeaMonkey or nss
> module. I always get
> > confused about them, but in any way the code is
> "external".
> >
> >> d)  Do we support digital signatures with any
> other file formats?
> >
> > No, only our own files format.
> >
> >> e) Any other uses of encryption?
> >>
> >> f) Presumably we places that are at least enabled
> for SSL via OS-level
> >> resolution of https protocol
> URLs.   Is this correct?
> >>
> >> g) But do we have any SSL (TLS) code included in
> our source code?  If
> >> so, what is the origin of this?
> >
> > Open ssl, maybe something in neon, I don't know.
> >
> > Regards,
> > Mathias
> >
> >
> 
> 
>

Re: https://issues.apache.org/ooo/ is now live

[Pedro F. Giffuni]

 I think it works fine, perhaps Ray got confused with the infra JIRA, which, of
course, manages the infrastructure for all projects.

Not that it matters too much, but ... Do we have a bugzilla template expert? It
would be good if we could make it look like the previous one. Perhaps we
can even get the original template somehow.

Pedro.

Re: [Repo][Proposal]After the code is checked in to SVN

[Pedro F. Giffuni]

+1 to (y).

It is good to take advantage that some people here know well
the branches that have to be merged.

It is faster and more practical to clean IP to the merged
codebase than to do several audits.

Also it would be really nice to just finish migrating the
Oracle code that has to be migrated.

Pedro.

--- On Wed, 8/31/11, Eike Rathke wrote:
...
> 
> So, we can choose:
> 
> x) first identify and remove license incompatible code to
> be pointed to
>    clashes when the CWSs will be integrated,
> additionally lookout for
>    new license incompatible code when
> integrating CWSs thereafter, or
> 
> y) first integrate all CWSs, note down new license
> incompatible code the
>    CWS introduces, and after all CWSs are
> integrated start the clean-up
>    of the entire tree. CWSs rarely introduce
> new external code, so new
>    code that would be covered by an
> incompatible license should be an
>    exemption.
> 
> I'd favour y) because we wouldn't have to deal with
> additional merge
> conflicts as would be the case with x).
> 
>   Eike
> 
> -- 
>  PGP/OpenPGP/GnuPG encrypted mail preferred in all private
> communication.
>  Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3  9E96
> 2F1A D073 293C 05FD
>

Re: Commit messages

[Pedro F. Giffuni]

--- On Tue, 8/30/11, Tor Lillqvist  wrote:
...

>> (I don't know who wrote this ... )
>> I'd like to see commit log/messages containing the
>> number of fixed issue referenced and no commit
>> messages without that number.
> 
> So people would not be allowed to improve things without
> first filing issues? Isn't that the kind of bureucracy

"like to see" doesn't involve any type of imposition.

> 
> Also, having an issue number in the commit message is not
> really that helpful, if the commit message is a short
> one-liner, the bug report doesn't describe what the
> changed/added/fixed code actually does either, and
> no useful comments are added.
>

I think the motivation is that modern bug management tools
integrate very well with the VCS. These are just rules of
thumb though .. committers are responsible for keeping
commit messages useful for community (and their own) benefit.

Pedro.

Re: [code] stuck at offapi on unxlngx6.pro

[Pedro F. Giffuni]

--- On Tue, 8/30/11, Stephan Bergmann wrote:

... 
> > 
> > This is an important question. If we need another
> > preprocessor there are options(1), but we need to now
> > why.
> 
> At least for idlc, I think the best solution would be to
> get rid of a C preprocessor completely.  Even if
> de-facto (if not also de-jure) .idl files have always been
> passed through a C preprocessor, so in theory could make use
> of all the C preprocessor's features, this has practically
> always only been used for plain #include <…> or
> #include "…" stuff (plus internal and external header
> guards, #ifndef XXX/#define XXX/.../#endif and #ifndef
> XXX/#include "YYY"/#endif), I think.
>

OK, thanks for explaining. The idea of just ripping of code
that we don't like is rather scary but i this case I guess
it could work at the expense of some robustness.
 
> So, it should be possible---without breaking backwards
> compatibility in practice---to change idlc so that it
> ignores all #… lines except for #include lines, which it
> then handles via a more efficient mechanism than textual
> inclusion.
>

This sounds like a job for embedded ucpp under the
"lexer" mode.[1] It's pretty small and very manageable,
plus we need a lexer anyways. Sorry my C-fu is not good :(.
 
> Would still have to have a look at soltools/cpp, though...
>

This is probably easier to replace since it's a standalone
tool.
In addition to mcpp, the Portable C compiler[2] also
includes a preprocessor that should be comparable to the
one in lcc.

hth,

Pedro.

ps. Repeated here for convenience:
[1] http://code.google.com/p/ucpp/
[2] http://pcc.ludd.ltu.se/

soltools/cpp replacement options (was Re: [code] stuck at offapi on unxlngx6.pro)

[Pedro F. Giffuni]

Hi again;

FWIW, This one looks like an interesting option as it
is made to be embeddable too:

http://code.google.com/p/ucpp/

"ucpp can be compiled as a stand-alone program, or linked to some other code; 
in the latter case, ucpp will output tokens, one at a time, on demand, as an 
integrated lexer."

cheers,

Pedro.

--- On Mon, 8/29/11, Pedro F. Giffuni wrote:
...
> 
> This is an important question. If we need another
> preprocessor there are options(1), but we need to now
> why.
> 
> cheers,
> 
> Pedro.
> 
> (1) http://mcpp.sourceforge.net/
>