Re: Definition of draw:angle in ODF1.2 does not fit to implementation

[Michael Stahl]

On 01/08/12 20:38, Dennis E. Hamilton wrote:
> Hi Armin,
> 
> Thanks for your valuable comment.
> 
> I had thought that the description using "clockwise" was in reference to the 
> page appearance and not the abstract treatment (with "right-hand rule").  
> Perhaps I misunderstand where the origin is understood in the projection onto 
> the page.
> 
> MORE IMPORTANT CONCERN
> 
> I think you raise a more important question concerning changing for ODF 1.3 
> and understanding a transformation between ODF 1.0/1.1/1.2/IS 26300 and ODF 
> 1.3.
> 
> I recommend that there be no breaking change of draw:angle between ODF 
> versions.  It is probably best to deprecate it while clarifying the 
> orientation of the angle-opening rotation and the units of the angle.  I 
> think preventing down-level breakage is impossible without that and the 
> support explanations will be a nightmare otherwise.  It seems to me that the 
> ODF 1.2 description is best corrected in an Errata and the problem made 
> immediately known in an OIC Advisory.  
> 
> To correct the geometry for transformations, I suggest that another, 
> rigorously-defined gradient element be introduced, preferably one from SVG.

there are already the svg:linearGradient and svg:radialGradient elements
in ODF 1.2, for example playing with Calligra Stage 2.4.3 i was able to
produce a ODF presentation document with this, which seems to do fine
without any explicit angle at all:

>>   > svg:x1="65.9558%" svg:x2="39.8039%" svg:y1="24.8957%" svg:y2="70.0815%">
>>> svg:offset="0.473324" svg:stop-color="#00ced1"/>> svg:offset="0.589196" svg:stop-color="#00ff00"/>
>>   
>>   > svg:x1="0%" svg:x2="166.923%" svg:y1="0%" svg:y2="164.085%">
>>> svg:offset="1" svg:stop-color="#00ff00"/>
>>   

unfortunately it seems that OOo derived suites only support the _other_
ODF specific gradient element(s) that have this draw:angle attribute.

i don't actually know anything about graphics, so i'll let Armin judge
whether that SVG stuff in ODF 1.2 is sufficient  :)

> If there is a down-level concern, I would define the new element such that, 
> when it and  are both present, the new element pre-empts 
>  in ODF 1.3 and beyond.  This way, a down-level implementation 
> will presumably process the  and ignore the element introduced 
> in ODF 1.3, since it is not defined down-level.
> 
> Would that break the knot better?

_if_ something new is needed in ODF then that would be my general
approach as well: don't change semantics of existing markup in an
incompatible way, but deprecate it and add new markup as necessary with
improved semantics.

the advantage is that existing products can then write both
representations in a new version, and the deprecated markup can still be
understood by older versions.

>  - Dennis
> 
> -Original Message-
> From: Armin Le Grand [mailto:armin.le.gr...@me.com] 
> Sent: Wednesday, August 01, 2012 02:21
> To: ooo-dev@incubator.apache.org
> Subject: Re: Definition of draw:angle in ODF1.2 does not fit to implementation
> 
>   Hi Dennis,
> 
> On 30.07.2012 22:21, Dennis E. Hamilton wrote:
> [ ... ]
>> (This is anti-clockwise in the standard geometric orientation.  When 
>> projected onto the page, this appears to be clockwise because the origin 
>> tends to be in the upper left corner and the positive-Y direction is 
>> downward, the positve-X direction is rightward.)
> 
> It is consistent throughout all AOO/LO/OOo versions. Unfortunately, it 
> is mathematically wrong oriented (thus, projected on the page, 
> anti-clockwise).
> 
> Thus, when just want to stay compatible and extend/correct the 
> definitions, defining it as integer, 0.1 degrees and mathematically 
> (non-projected to page) clockwise rotation would describe the current 
> behaviour.
> 
> Unfortunately this 'wrong' orientation is problematic. As long as it is 
> only locally used it can simply be mirrored. The problem comes up when 
> working with transformations; when receiving the transformation of an 
> graphic object and decomposing it to extract rotation, that rotation 
> will be mathematically correctly oriented. It has to be since else 
> linear combination of transformations would not work.
> 
> This is not in the environment of gradients, but in general all angles 
> in ODF have this problem (probably for historical reasons, the UIs use 
> the same wrong orientation). Our competitor does not have that error.
> 
> Isn't this correctable for all angles e.g. for ODF1.3 and can be handled 
> by a XML transformation ODF1.2 <-> ODF1.3 by mirroring all angle values 
> easily? If yes, Shouldn't we take the chance to clean this up in ODF1.3?
> 
> [ ... ]
> 
> 

Re: Request for Apache License for CWSs

[Michael Stahl]

On 23/05/12 16:00, Michael Meeks wrote:
> 
> On Wed, 2012-05-23 at 13:54 +0200, Regina Henschel wrote:
>> There are a lot of CWSs in http://hg.services.openoffice.org/. The files 
>> are still under LGPL3. Some of these CWSs are relevant for LO and for 
>> AOO. It it possible to get these CWSs under APL2.0?
> 
>   Right ! so I've been delaying the ask until I have an accurate list,
> but since that's taking a bit of time, here is a (possibly incomplete)
> list of useful CWS' that we have code integrated from:
> 
>   cws ause130
>   cws gnumake4
>   cws writerfilter10
>   cws mav58

these are not yet integrated at ApacheOO AFAIK.

missing from this list is "ause131", or so i thought but upon closer
examination the globalmn.hrc problem has been fixed independently in
LibreOffice so it's not required (but Apache folks probably want it).

oh, CWS "sb140" is definitely missing from the list.

>   cws ooo34gsl01
>   cws ooo34gsl10
>   cws ooo34gslstop1

these three are all actually "ooo34gsl01", just sometimes with typos.
"ooo34gsl01" was committed by myself in ApacheOO SVN, should be in the
3.4.0 release.

>   cws ooo340fixes
>   cws sw34bf06

both also committed by myself in ApacheOO SVN, should be in 3.4.0 release.

>   cws aw084
>   cws calc65
>   cws impress210
>   cws impressdefaults1

these were integrated into OOO340_m1, which was AFAIK never merged
wholesale into LibreOffice (the last milestone merged was DEV300_m106),
so they're already in the initial ApacheOO SVN import.

>   If we can't get them under AL2.0 in time, then we will need to
> incrementally remove and re-write them on a per-file basis I imagine -
> which would be unfortunate but not debilitating.
> 
>   Of course - now that we have some sort of list, further clarity on the
> process by which these LGPLv3, Oracle owned CWS become AL2.0 is much
> appreciated.
> 
>   Michael S. had a few others that had useful features not-yet-merged in
> mind.

yes, there are some nice to have things that are relatively low-hanging,
would be a shame if the effort gone into them were wasted:

"swcoreseparation" CWS contains nice refactoring of sw to remove
dependencies from core code to ui code by mba
https://issues.apache.org/ooo/show_bug.cgi?id=117814

"tl77" CWS contains refactoring of edit engine clipboard code to replace
the binary SfxItemPool-based serialization format with ODF, and
subsequent removal of the un-maintainable SfxItemPool serialization code

"textalignment01" CWS contains a substantial re-work of RTL code by
Oliver-Rainer (that is not finished AFAIR) to make it conform with ODF
(currently we mis-interpret the "start" and "end" alignment values)
https://issues.apache.org/ooo/show_bug.cgi?id=105270
https://bugs.freedesktop.org/show_bug.cgi?id=37128

"accfixes2", "accfixes3", "accstuff", "accia2bridge" CWSes contain
accessibility stuff, see Malte's mail for a description:
http://permalink.gmane.org/gmane.comp.documentfoundation.libreoffice.accessibility/164

regards,
 michael

Re: /usr/bin/openoffice.org

[Michael Stahl]

On 06/01/12 11:54, Andre Fischer wrote:
> Ah, found another one:
> 
> Synaptic on Ubuntu 11.10 has a package "openoffice.org" which installs 
> LibreOffice.  It is not installed by default (the "libreoffice" package 
> is) and also provides the 'explanation'
> 
> 
> This is a transitional package, replacing the OpenOffice.org packaging
> with the LibreOffice packaging.
> 
> It can be safely removed after an upgrade.
> 
> 
> but still, is this OK?

hi Andre,

this is a standard procedure that happens regularly on deb-based
distributions: upstream communities do weird things such as re-brand,
fork, become inactive and resume at a different place with a different
name, etc.;  examples that come to mind include GAIM re-branded to Pidgin,
Debian's Mozilla stuff re-branded IceAnimals, or the git/gnuit conflict.

the approach is that an empty package with the old name which has a
dependency on the real package with the new name is included in the next
release, to ensure a smooth upgrade experience for users (because
otherwise an outdated and unsupported version of the old package would
remain, which is bad from a security point of view).  this "transitional"
package is then usually dropped one release later (though i don't know
what happens exactly on Ubuntu, which supports upgrades between LTS releases).

in this case i guess it's at the discretion of the distributions which of
the 2 successors of the deceased OpenOffice.org they transition to (and
given the lack of a release from Apache OpenOffice it shouldn't surprise
anybody that currently LibreOffice is the more popular transition target).

regards,
 michael

Re: Build braker in drawinglayer

[Michael Stahl]

On 29/12/11 21:40, Armin Le Grand wrote:
>   Hi*,
> 
> Address of bitfield is strange, but can only be a bitfield variable. The 
> only one in the class TextBreakupHelper is mbNoDXArray, and it is only 
> used internally. Address of bitfield implies that it gets somewhere 
> casted or given as pointer/reference to some call, but it gets not. The 
> only thing which I stumbled upon is that it gets not really initialized 
> (see constructor of TextBreakupHelper), so please try:
> 
> ln44: 'mbNoDXArray()' -> 'mbNoDXArray(true)'
> 
> If this helps this is a hint that the compiler tries to make this a 
> function call...

AFAIK this is valid C++ syntax and should initialize the member to 0, cast
to the integral type of the member variable (presumably, bool here).

yet another bug in SunStudio's so-called C++ compiler.

btw, the value would be "false", not "true".

Re: Java 7 and Apache OpenOffice

[Michael Stahl]

On 07/01/12 18:44, drew wrote:
> On Sat, 2012-01-07 at 12:09 -0500, Carl Marcum wrote:
>> On 01/07/2012 07:33 AM, Raphael Bircher wrote:
>>> Hi all
>>>
>>> Is sameone around here with Java 7? I hear that LO 3.4.x has trubble
>>> with Java 7. So this is probabily also a problem at AOO 3.4. Can sameone
>>> test this?
>>
>> I installed OOo-Dev_OOO340m1_Linux_x86-64_install-rpm_en-US from 
>> http://people.apache.org/~arielch/packages/

>> When I try to add a 1.7 jre, I receive a "The folder you selected does 
>> not contain a Java runtime environment" error.
>>
>> I can also confirm this is the same behavior as OOo 3.3.0 I have 
>> installed by download previously.
> 
> IIRC, the fix turned out to be an update to a string resource in the
> code - easy hack - but that comes from reading along on a mailing list,
> third hand information ;-/

i think the problem was that the java.vendor property has changed, because
sadly "Sun Microsystems Inc." does not exist anymore.

now i have no idea why the heck OOo needs to know which JVM it's running
with, but then again the C++ UNO stuff creates vtables out of whole cloth
at runtime, so presumably the public JVM interfaces aren't good enough
either :)

Re: Localized builds

[Michael Stahl]

On 05/01/12 12:06, Jürgen Schmidt wrote:
> I used configure with  --with-lang="en-US de" and got a problem in 
> instsetoo_native to resolve a dependency to module l10n
> 
> The solution is to put a source.config file besides main

> My question is how do others make localized builds without this file?

i'm guessing they don't.

> Any ideas?

for inspiration, my ideas on getting rid of the source_config horror:

http://mail-archives.apache.org/mod_mbox/incubator-ooo-dev/201109.mbox/%3Cj48gg5$ksu$1...@dough.gmane.org%3E

regards,
 michael

Re: [BUILD]solaris build failure for test --enable-gstreamer

[Michael Stahl]

On 06/01/12 13:37, L'oiseau de mer wrote:
> Because Solaris 10 hasn't any gstreamer version enabled , the system's
> gstreamer is 0.8.
> I try to build new gstreamer for AOO and install to a independant area,
> the area include "glib-2.20.5 , libxml-2.7.8 , gstreamer-0.10.24 ,
> gstreamer-plugins-base-0.10.24, gst-plugins-good-0.10.16、liboil-0.3.7"
> And i use /usr/sfw/bin/gcc build them, and it is success.
> 
> Then i build AOO and --enable-gstreamer is passed.
> the compiler for building AOO is SolarisStudio 12.3

AFAIK in Hamburg we never built GStreamer support on Solaris;
i have built it successfully with configure on Solaris 11 early in 2010,
which required some fixes to avmediagst (the fixes are integrated in
DEV300m106).

so in the worst case, leaving out GStreamer on Solaris wouldn't be a
feature regression.

> But when building, it appear the error message:
> 
> =
> Building module avmedia
> =
> 
> Entering /UNIX-LAB/ooo/main/avmedia/source/quicktime
> 
>  Nothing to build for GUIBASE=unx
> 
> Entering /UNIX-LAB/ooo/main/avmedia/source/gstreamer
> 
> Compiling: avmediagst/source/gstreamer/gstplayer.cxx
> "/UNIX-LAB/ooo/main/avmedia/source/gstreamer/gstplayer.hxx", line 164:
> Error: Formal argument atomic of type int* in call to
> g_atomic_int_get(int*) is being passed const int*.
> "/UNIX-LAB/ooo/main/avmedia/source/gstreamer/gstplayer.cxx", line 196:
> Error: Formal argument atomic of type void** in call to
> g_atomic_pointer_get(void**) is being passed _GstElement**.
> "/UNIX-LAB/ooo/main/avmedia/source/gstreamer/gstplayer.cxx", line 933:
> Error: Formal argument atomic of type void** in call to
> g_atomic_pointer_get(void**) is being passed avmedia::gst::Window**.
> "/UNIX-LAB/ooo/main/avmedia/source/gstreamer/gstplayer.cxx", line 939:
> Error: Formal argument atomic of type void** in call to
> g_atomic_pointer_get(void**) is being passed avmedia::gst::Window**.
> "/UNIX-LAB/ooo/main/avmedia/source/gstreamer/gstplayer.cxx", line 939:
> Error: Formal argument atomic of type void** in call to
> g_atomic_pointer_get(void**) is being passed avmedia::gst::Window**.
> 
> ==
> 
> So,is this compiler's problem or my build gstreamer lib has problem ?
> Can anyone help me?Thanks.

i didn't encounter the problems you have, guess you are using an older
version of glib.

in glib 2.30 the signature looks like this, which shouldn't cause this
problem:

   gpointer g_atomic_pointer_get(volatile void  *atomic);

Re: OO34: where has the command-line API for conversion gone?

[Michael Stahl]

On 07/01/12 01:11, Ariel Constenla-Haile wrote:
> Hi *,
> 
> On Fri, Jan 06, 2012 at 06:02:54PM -0500, Rob Weir wrote:
>> cc'ing ooo-dev --- Could this be related to the removal of glibc?
>>
>> -Rob
>>
>> On Fri, Jan 6, 2012 at 3:54 AM, filtered  wrote:
>>> Former versions of OpenOffice supported command-line conversions using the
>>> --convertTo
>>> option. In OO 3.4 there does to be no command line API at all. Where has it
>>> gone?
>>> Why was it removed? What is the proper way doing command-line conversions
>>> using OO 3.4? Don't point me to LibreOffice since several LibreOffice
>>> filters have issues.
> 
> are you sure you used that command line option in a vanilla
> OpenOffice.org (as downloaded from http://www.openoffice.org)?
> 
> Looking at the Mercurial history
> http://hg.services.openoffice.org/OOO340/log/c904c1944462/desktop/source/app/cmdlinehelp.cxx
> that option *never* existed before - at least not in vanilla
> OpenOffice.org.
> 
> Regards

it seems the option is actually "--convert-to" and only exists in LO.

maybe it was in the ooo-build patches and thus in some Linux distro builds
of OOo.

regards,
 michael

Re: [BUILD]solaris build failed again.

[Michael Stahl]

On 19/12/11 20:18, tora - Takamichi Akiyama wrote:
> Additionally, try using the same version of compiler as the release 
> engineering team used.
> http://wiki.services.openoffice.org/wiki/Compiler_versions_used_by_port_maintainers_and_release_engineers
> 
> Generally speaking, the latest version of compiler might now work well 
> with the source code of OpenOffice.org since the code is developed with 
> a specific version of compiler.

i've heard rumours that SunStudio 12U2 had problems compiling boost stuff,
but since you were apparently successful with the latest release these
problems have perhaps been fixed.

btw, since apparently nobody has ever built LO on Solaris i've deprecated
SunStudio there a couple of days ago (there was rejoicing):

http://cgit.freedesktop.org/libreoffice/core/commit/?id=514cefbcb7b800f8ddd2aa595502f4fe8403882f

> E.g. One source code line would be treated:
> (version x.0) Warning: xxx is ambiguous and considered as an error
> (version x.1) Error: xxx is ambiguous
> 
> Migration of compiler version is tough work...
> 
> Tora

Re: gnumake4 integration (was: Re: [Code] strategy for "child works spaces")

[Michael Stahl]

On 17/12/11 06:27, Ariel Constenla-Haile wrote:
> This way we can use branches/gbuild to create
> further feature branches for gbuild conversion that can not be done on
> trunk directly (here I can imagine the desktop module, for example).

errm, yes, converting the desktop module on master (not on a branch)
turned out to be quite a disaster at LO, so... branches are good :)

Re: Help! JunitTest_framework_unoapi.mk:28: *** Malformed target-specific variable definition. Stop.

[Michael Stahl]

On 16/12/11 18:24, Mathias Bauer wrote:
> On 16.12.2011 03:43, Zhe Liu wrote:
>> Hi All,
>> I always break because of the error when build on Windows XP. I
>> mentioned before, nobody responsed on it.  I did a little search and
>> found someone also encountered the problem.  I still have no clue how
>> to resolve it.
>>
>> JunitTest_framework_unoapi.mk:28: *** Malformed target-specific
>> variable definition.  Stop.
>>
> 
> What version of GNU Make do you use? 3.82 has a bug that let GNU Make 
> spit out this error even if the variable definition is OK (and is parsed 
> without problems by 3.81).

AFAIR this is a problem that only happens on Cygwin (i speculate the
problem is triggered by the CLASSPATH that contains jar files with mixed
path notation, containing a colon).

getting a make that works well on windows is surprisingly difficult :-/

Re: ucpp sal dependency (was Re: OpenOffice nightly)

[Michael Stahl]

On 13/12/11 17:01, Jürgen Schmidt wrote:

>> BTW: another fix for the current problem would be converting ucpp to
>> gbuild.
> 
> i would love to do that, do you know if it's already possible to use 
> gbuild to apply our patch process and trigger a build on the patched 
> sources?

not yet :(

such an effort was not started during OOo times.

there has been some work on this in LO but we don't yet build any external
by default with gbuild...

well, you could always use a CustomTarget to do it, but i guess it is very
cumbersome that way...

Re: Native support of the SVG graphic format in Apache OpenOffice.org

[Michael Stahl]

On 04/12/11 21:27, Ariel Constenla-Haile wrote:
> Last build breaker I've seen has been found by Andrew, in ucpp. You can
> see it in a clean build, if you do build --all in ucpp.
> On the other hand, I've experienced some random crashes with cygwin's
> make, again unrelated to source code changes.

cygwin ships GNU make 3.81, which suffers from bug 20033, which is
triggered by some of the gbuild stuff if built with -jN for N>1

(ironically i think what triggers it is the response-file stuff that
writes command lines that are "too long" to temp files, which is only
needed on Windows anyway...)

iirc GNU make 3.82 has some performance regression (it stats files
unnecessarily), which is barely noticed on Unix but makes it rather slow
on Windows.

somebody from the LO community built this binary, which is said to be both
fast and crash-free, perhaps you should try it out:

http://dev-www.libreoffice.org/bin/cygwin/make

regards,
 michael

Re: GPL'd dictionaries (was Re: ftp.services.openoffice.org?)

[Michael Stahl]

On 24.11.2011 21:18, Mathias Bauer wrote:
> We don't need to change the dic files, we just take them as they are

ha! third party stuff that doesn't need to be patched!
how un-usual a concept...

Re: [Code] strategy for "child works spaces"

[Michael Stahl]

hi Ariel,

On 23.11.2011 17:16, Ariel Constenla-Haile wrote:
> On Wed, Nov 23, 2011 at 08:08:21AM -0800, Pedro Giffuni wrote:
>> FWIW, Michael Stahl had these CWSs in the pipeline, I hope
>> he or someone else finds the time to merge them into some
>> branch:
>  
> 
>> gnumake4
> 
> 
> I started working in this one. I took the apply-per-commmit approach
> (I did one big diff but was very error prone). They are ca. 180 commits,
> may be I'll finish by next Monday dedicating 2 hrs per day.

uhm, i kind of already have re-based that onto OOO340m1 some time in
August, and am sitting on 150 or so patches that are basically just
waiting for the 3.4 branch off so they can go into trunk.  well i guess
they need to be re-based again because of the changes to the build system
in AOOo.

if you are impatient :) then i can mail them to you or something, no need
to re-invent the wheel here (but somehow i get the feeling that AOOo is
all about re-inventing wheels...)

regards,
 michael

Re: [CODE]: 118605 remove epm?

[Michael Stahl]

On 22.11.2011 11:57, Jürgen Schmidt wrote:
> I stumbled over problems using a downloaded epm 4.2 
> (http://www.epmhome.org), build and install it on a Fedora 16 system 
> (rpm based).
> 
> The epm call failed to build the rpm packages. It seems that epm 
> triggers /bin/rpm with some parameters that are not accepted. I don't 
> understand why at the moment.

/bin/rpm on a recent Fedora can not build packages, it can only do the
things necessary on a running system: install etc.; there is an extra
package "rpm-build" with a /usr/bin/rpmbuild program that is used to build
packages.

IIRC i once changed configure to complain if you have a /bin/rpm that
cannot build and no rpmbuild, perhaps that check bitrotted...

[ i have no idea why we use a "patched" epm, or whether an unpatched epm
would work ]

regards,
 michael

meaningless BuildIds (was: Re: [Mac OS X, Intel] some issue with Apple remote)

[Michael Stahl]

On 10.11.2011 11:39, Uwe Altmann wrote:
> Raphaels Build 340m1 build 9584 (would really be nice if this text could
> be copied from the "about"-box)

this is a number that has become utterly meaningless: it was updated for
every weekly milestone build in a certain office in Hamburg that is now
empty.  in LO the about dialog displays the git hash(es) of the built
source instead, probably AOOo should do the same with the SVN revision.

regards,
 michael

Re: Ohloh

[Michael Stahl]

On 30.10.2011 20:19, Mathias Bauer wrote:
> Am 30.10.2011 19:23, schrieb Eike Rathke:
> 
>> Hi,
>>
>> Whoever had the brilliant idea to make Ohloh's source code repository
>> entry for OOo https://www.ohloh.net/p/openoffice point to the AOOo
>> repository instead trashed over 10 years worth of 1s commits of 100s
>> developers. Congratulations.
> 
> As most of them were tracked as commits from our former release
> engineers and so are misleading anyway, perhaps its not such a big loss. :-)

indeed, because of the CVS and SVN approach to merge tracking authorship
was not properly recorded for the most part of OOo history, so the loss is
not big.

but still, apparently Eike disagrees with that; it would have been nice to
ask first before making this change.

at least the historic data is still available at the LO project, the
history there still begins with Heiner's initial CVS import:
https://www.ohloh.net/p/libreoffice/

the change seems especially pointless since there already was an Apache
OOo project at Ohloh:  https://www.ohloh.net/p/apacheoffice/

it seems to me that there is some kind of counting error at the new
OpenOffice.org project: a comparison with AOOo shows that it counts every
commit twice.

also, another deficiency of most SCM systems that makes Ohloh statistics
unreliable is that they only track the committer, but not the author of a
commit, which is not necessarily the same person (git gets this right).

hmm, now Ohloh claims that i am the #1 contributor to OpenOffice.org, how
ridiculous is that...

regards,
 michael

Re: Clarification on treatment of "weak copyleft" components

[Michael Stahl]

On 20.10.2011 23:27, Sam Ruby wrote:
> On Tue, Oct 18, 2011 at 12:08 PM, Rob Weir  wrote:

>> Now, for our SVN, we need to host the actual source of the MPL
>> components, since we need to build the binaries on the platforms that
>> we support.  And in several cases we have patches the original source.
>>  Is this a problem?
> 
> That normally is highly discouraged / not allowed.  Why can't the
> patches be contributed back to the original projects?

reasons why patches to external libraries exist include:

1) to add missing features/fix bugs.
   these should usually be submitable to upstream;
   reasons why they exist anyway:
   a) the patch was submitted and accepted,
  but OOo does not use the new release yet
   b) the patch was submitted but upstream is unresponsive
   c) the patch was submitted but upstream has NACKed it
   d) the patch was never submitted because upstream is dead
   e) the patch was never submitted upstream due to lack of time

2) to get it to build in our build system.
   quite often some C/C++ library does not come with a build system that
   works with MSVC on windows (and also OS/2), so we patch in some
   dmakefile to get it to build (the dmake build system requires the
   makefile to be in the same directory as the source files, hence the
   patch), and perhaps a config header.
   of course it does not make sense to upstream these patches.

3) the patch is actually taken from upstream, and backported to an older
   version.  this may happen for critical bugfixes (esp. security), when
   there was not enough time to evaluate and test a full update to a new
   upstream version.

a big problem in managing patches is that up until about 2 years ago, the
build system could only apply a single patch to an unpacked tarball.
so there are perhaps still some big patches left that contain fixes for
various distinct problems from various different categories.  of course,
once you have a 10k-line patch like that it becomes all the more difficult
to figure out what the heck it does.

regards,
 michael

Re: Legacy OOo SVN

[Michael Stahl]

On 15.10.2011 19:49, Rob Weir wrote:
> On Sat, Oct 15, 2011 at 1:09 PM, Pedro Giffuni  wrote:
>>
>> --- On Fri, 10/14/11, Rob Weir  wrote:
>> ...
>>> I want to make sure we're not duplicating effort here.
>>> I've been working with Pedro to take the legacy OOo SVN
>>> repository (pre Hg) and get it onto Apache-Extras.
>>> I'm doing this via svnsync, a slow
>>> process, but it will preserve the revision history.

sounds good; there are even still some non-integrated CWSes in there, but
probably these are by now so outdated that they aren't of much interest.

>> In more than week, at the current rate, but still it's
>> worth it. I am not sure if support for MySpell and
>> Xalan is still buried there somewhere but in theory
>> there is some stuff there that may have been otherwise
>> lost during the Hg migration.
>>
>>> I'm told that before SVN the project used CVS.  Is it
>>> worth backing that up as well?
>>
>> I have no idea where the CVS stuff may be available but
>> apache-extras doesn't support CVS and it's probably not
>> worth the try anyways.
> 
> It is probably not useful for the project, at least directly.  But I
> was contacted by someone off list who said it might be good to have a
> back up as a reference, for IP reasons.  This kind of make sense.  It
> shows the provenance of the code, and it also establish an earlier
> data (back to 2000, right?) for publication of the code.  This is
> useful as prior art.

keep in mind that the CVS repo is pretty darn enormous, Heiner said
something about 90G:

http://mail-archives.apache.org/mod_mbox/incubator-ooo-dev/201106.mbox/%3c4e05d910.5070...@web.de%3E

> What are our options if we wanted to back up the CVS, and preserve the
> revision history?   Apache-Extras doesn't do CVS.

hmm... converting to something non-CVS is probably not an option, because
that would lose information (given the nature of CVS any large repo is a
huge mess...).

perhaps mirror it with CVSup, make a tarball and upload that somewhere...

probably nobody really wants to actually look at it, it's more of an
"insurance" thing, right?

regards,
 michael

Re: FreeBSD build failute in libxslt

[Michael Stahl]

On 14.10.2011 00:44, Pedro Giffuni wrote:
> Hi;
> 
> FreeBSD has a tinderbox that checks all the ports and
> OpenOffice 3.4-RC appears broken in configure:
> 
> http://pointyhat.freebsd.org/errorlogs/amd64-9-full-logs/openoffice.org-3.4.20110409.log
> 
> building manually I get this:
> 
> 
> /bin/sh ../libtool --tag=CC   --mode=link gcc  -g -O2 -Wall  
> -Wl,--version-script=./libxslt.syms -version-info 2:26:1 
> -Wl,-rpath,'$ORIGIN:$ORIGIN/../ure-link/lib' -Wl,-noinhibit-exec -o 
> libxslt.la -rpath /usr/local/lib attrvt.lo xslt.lo xsltlocale.lo xsltutils.lo 
> pattern.lo templates.lo variables.lo keys.lo numbers.lo extensions.lo 
> extra.lo functions.lo namespaces.lo imports.lo attributes.lo documents.lo 
> preproc.lo transform.lo security.lo 
> -L/usr/ports/editors/openoffice.org-3-RC/work/OOO340_m1/solver/340/unxfbsdx.pro/lib
>  -lxml2 -lm  
> libtool: link: gcc -shared  .libs/attrvt.o .libs/xslt.o .libs/xsltlocale.o 
> .libs/xsltutils.o .libs/pattern.o .libs/templates.o .libs/variables.o 
> .libs/keys.o .libs/numbers.o .libs/extensions.o .libs/extra.o 
> .libs/functions.o .libs/namespaces.o .libs/imports.o .libs/attributes.o 
> .libs/documents.o .libs/preproc.o .libs/transform.o .libs/security.o   
> -L/usr/ports/editors/openoffice.org-3-RC/work/OOO340_m1/solver/340/unxfbsdx.pro/lib
>  -lxml2 -lm  -Wl,--version-script=./libxslt.syms -Wl,-rpath 
> -Wl,\$ORIGIN:\$ORIGIN/../ure-link/lib -Wl,-noinhibit-exec   -Wl,-soname 
> -Wl,libxslt.so.1 -o .libs/libxslt.so.1
> /usr/bin/ld: cannot find -lxml2

if your build is configured to use the internal libxml2, then the libxml2
module should deliver a patched xml2-config script into the solver bin
directory, which should (when called by the internal libxslt configure
script) put the solver lib directory onto the linker search path (looks
like that is the case here with
"-L/usr/ports/editors/openoffice.org-3-RC/work/OOO340_m1/solver/340/unxfbsdx.pro/lib
-lxml2").

if you build --with-system-libxml, then the xml2-config from your system
should be found instead.

on MacOSX OOo does not build the internal libxml2/libxslt but instead uses
the system libraries; perhaps it could make sense to do the same on FreeBSD?

regards,
 michael

Re: Hosting OpenGrok?

[Michael Stahl]

On 15.10.2011 22:13, Gavin McDonald wrote:
> Hi All,
> 
> We already use Atlassians Fisheye tool on an external copy of our repo. This
> has
> excellent tools including the code search facilities you need.

it looks like an interesting tool in its own right, but...

> The ViewVC search facility has been investigated and discounted at this time
> due to DoS and other concerns.
> 
> OpenGrok would be yet another tool introduced to the ASF and ultimately
> another
> one infra would need to support for install and for any future upgrades. We
> have many
> requests for tool X from project Y and we just can't say yes to them all.

the killer feature of OpenGrok is that it can search for definitions.

for example try this:

> http://svn.services.openoffice.org/opengrok/search?q=&defs=sal_uInt32&refs=&path=&hist=&project=%2FCurrent+%28trunk%29

not perfect (in fact the results here surprise me a bit), but very useful.

> At this time I would urge the project to use the Fisheye instance, let me
> know if you
> have any questions about it.

i have a question: how do i search for definitions with this thing?

regards,
 michael

Re: GStreamer avmedia plugin as copyleft?

[Michael Stahl]

On 05.10.2011 09:42, Jürgen Schmidt wrote:
> On Wed, Oct 5, 2011 at 4:53 AM, Pedro Giffuni  wrote:
> 
>>
>> --- On Tue, 10/4/11, Ariel Constenla-Haile wrote:
>> ...
>>>
>>> it seems you miss my point here.
>>> If you disable building and shipping GStreamer because it
>>> links against copy-left system libs, then you should
>>> remove the VCL plugins too (AFAIK gtk is LGPL, I'm not
>>> sure about Qt/KDE).
>>>
>>
>> Oh .. indeed GTK++ and Qt are LGPL, but one of our mentors
>> said in the early days of this list that those could be
>> considered part of the system, so we can side step them ...
>> for now.
>>
>> This was a subject I didn't want to bring in just yet, but
>> if it does happen that linking them is an issue, there are
>> replacements.
>>
>>
> replacements? Really, what do you have in mind?

how about the venerable X Athena Widgets (Xaw)?

licensed under MIT X11, not contaminated with evil copyleft code, so it
should meet even the ASF's high licensing standards.

http://www.efalk.org/Widgets/Xaw.gif

i think there is even a 3D variant of it...

for a more modern look perhaps Motif could be considered, but
unfortunately there don't seem to be any permissively licensed variants
thereof (Lesstif is also contaminated with that eeevil copyleft stuff, and
"OpenMotif" isn't even open source!).

SCNR,
 michael

[Repo] HG repo with CWSes archived

[Michael Stahl]

hi all,

as a backup/archive of the historic OOo code i've put up a HG repo
containing OOO340 + all HG CWSes, with bookmarks.

https://bitbucket.org/mst/ooo340


PS:
note that unfortunately HG does not push/pull/clone/bundle bookmarks by
default, so if you want the bookmarks in your local clone something
explicit is needed:

hg pull -B ab78 -B accfixes2 -B accfixes3 -B accia2bridge -B accstuff -B
ause130 -B ause131 -B automationdev300m106 -B automationdev300m106ext -B
automationooo340m0 -B aw080 -B boost142 -B calc67 -B calc68 -B calc69 -B
calcdatatables -B calcishmakkica -B calcphonetic -B callcatcher -B
cbosdo04 -B cbosdo06 -B cmcfixes79 -B container_controls -B contextmenu1
-B contl10n01 -B dockingwindows2 -B dr81 -B extbxctrls -B findbar02 -B
fs34c -B fs35a -B fwk168 -B gnumake4 -B gtk3 -B hb23 -B hccalc01 -B
hcshared30 -B headeradd -B hr77 -B hsqldb19 -B impress212 -B impresshtmlex
-B impressmedia01 -B jl155 -B jl166 -B jsc342 -B kde4enable -B
koheichart02 -B kso47 -B kso50 -B l10ntooling20 -B ldorder01 -B lihuivba01
-B loadodf -B loadofd -B macmetallicremote2009 -B master -B mav58 -B
mba34issues01 -B mbacodecleanup -B mh8tz -B mib20 -B mingwport35 -B
native356 -B native372 -B native373 -B new_itemsets2 -B notes12 -B oj22 -B
ooo340fixes -B ooo34gsl02 -B ooxml07 -B ooxml11 -B os138 -B os148 -B
perfbenchmarker01 -B quicklookplugin01 -B rtftok01 -B sb140 -B sb143 -B
sb144 -B sd2gbuild -B sdf2 -B sdk350 -B setsolar01 -B slidesorter1 -B
sw34bf06 -B swbookmarkfixes01 -B swcoreseparation -B swrefactordlusage02
-B swundo4 -B textalignment01 -B tkr37 -B tkr41 -B tl77 -B tml11 -B
tmp_otf02 -B toolsfixes -B tora01 -B vbasupportdev300_HG -B vcl122 -B
writercompare01 https://bitbucket.org/mst/ooo340


-- 
"Only wimps use tape backup: _real_ men just upload their important
 stuff on ftp, and let the rest of the world mirror it." -- Linus Torvalds

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

[Michael Stahl]

On 30.09.2011 21:24, Mathias Bauer wrote:
> On 28.09.2011 17:32, Pedro F. Giffuni wrote:

> Another advantage of unpacking the tarballs: the patches will become
> *real* patches that just contain changes of the original source code.
> Often the patches nowadays contain additional files that we just need to
> build the stuff in OOo (e.g. dmake makefiles) - they could be checked in
> as regular files.
> 
> Currently keeping them as regular files is awkward because then they
> need to be copied to the place the tarballs are unpacked to.

but this is just because dmake can only build source files in the same
directory; imagine a more flexible gbuild external build target where the
makefiles are in the source tree while the tarball gets unpacked in the
workdir...

> Regards,
> Mathias
> 

EIS CWS data

[Michael Stahl]

EIS seems to be dead.

some months ago somebody (and i'm too lazy to dig up who to thank)
uploaded a dump of the CWS data here, guess that's all we have now:

http://dl.dropbox.com/u/1792694/cws.ods

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

[Michael Stahl]

On 28.09.2011 21:52, Pedro F. Giffuni wrote:
> Is OOo on a opengrok anywhere? It would be good to see where
> such headers are used.

this one still seems to work:

http://svn.services.openoffice.org/opengrok

there is also this one, but of course it has a rather different source
tree so such questions can probably not be answered definitely for AOOo:

http://opengrok.libreoffice.org/

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

[Michael Stahl]

On 28.09.2011 17:32, Pedro F. Giffuni wrote:
> 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.

if we didn't have many thousands of lines of patches to rebase, then
upgrading to less outdated versions wouldn't be such a PITA.

sadly in many cases upstreaming patches was never sufficiently high on the
priority list to actually get done...

-- 
"Dealing with failure is easy: Work hard to improve.
 Success is also easy to handle: You've solved the wrong problem.
 Work hard to improve." -- Alan Perlis

Re: [patch] Removal of Windows build requirement on unicows.dll - issue 88652

[Michael Stahl]

On 27.09.2011 22:22, Rob Weir wrote:
> On Tue, Sep 27, 2011 at 4:08 PM, Dennis E. Hamilton 
>  wrote:
>> What is the oldest Windows OS version that Apache OOo 3.4(-dev) will
>> be supported on?  How does that compare with the oldest Windows OS
>> version that the last stable release (3.3.0?) of OpenOffice.org is
>> supported on?  (If there is a JRE dependency, that is another variant
>> to consider.)

AFAIK OOo 3.x Windows baseline is NT 5.0 (Windows 2000);
AFAIK this OS version is no longer supported by the vendor.

> I'd recommend supporting Windows XP and beyond.   XP is officially 
> supported by Microsoft until April 2014.   I'm certainly not making any
> effort to maintain or test support for earlier versions.  Of course,
> that doesn't prevent anyone else from testing and patching to support
> earlier versions.

no objection from me to raising the baseline to WindowsXP; IMHO trying to
support an OS that the vendor doesn't support any more doesn't make sense.

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

[Michael Stahl]

[this mail has managed to hide in a draft folder for weeks...]

On 01.09.2011 23:01, Robert Burrell Donkin wrote:
> On Thu, Sep 1, 2011 at 9:35 PM, Dennis E. Hamilton 
>  wrote:
>> Technically, this was to have been resolved before the code was put
>> up on SVN.  We need to audit specifically for this rather quickly,
>> and including the places that Rob also identified (import-export
>> filters and http TLS)..
> 
> I definitely recommend a full crypto audit but IIRC it's not
> necessary before sending the initial notification.
> 
> AIUI (from [1] and [2]) all that's needed is a list of the 
> cryptographic libraries used by OOo. If the results of the full
> audit differ then we can just update the details and send an updated 
> notification.

looking through the external modules the following are obviously crypto
related:

xmlsec1-1.2.14.tar.gz
openssl-0.9.8o.tar.gz
nss-3.12.6-with-nspr-4.8.4.tar.gz
seamonkey-1.1.14.source.tar.gz

(Seamonkey also contains NSS but i guess we don't ship this but the one
from the "nss" module)

the internal implementation of Blowfish (and also RC4 it seems) is in
these files:

sal/inc/rtl/cipher.h
sal/rtl/source/cipher.c

hope that should get us started...

-- 
 State?
 There is no state :-)
 Haskell separates Church and state.

Re: AOOo can't save passwort protected file

[Michael Stahl]

On 17.09.2011 22:32, Pedro F. Giffuni wrote:
> 
> 
> --- 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

where the heck did you get that idea?

http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#1280

> version OOo carries has known security issues I suggest
> we kill the configure option to avoid hazards to our users.

indeed the version shipped by OOo is outdated (3.12.6); newest one on the
FTP server is:

https://ftp.mozilla.org/pub/mozilla.org/security/nss/releases/NSS_3_12_11_RTM/src/

(of course the OOo internal OpenSSL is similarly out of date...)

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

but can Google Chromium read Mozilla address books?

AFAIK that is all that OOo uses Mozilla for...

> 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: Build AOOo on Mac OS X 10.7

[Michael Stahl]

On 22.09.2011 08:49, Chao Huang wrote:
> hi, all
> 
> On Mac OS X 10.7, I'm trying to build AOOo in following steps as I did
> on Mac OS 10.6/10.5 :

>4) there will be a break with error message (due to the restriction
> of gcc version 4.0 in configure)
>checking for gcc... /usr/bin/gcc
>checking the GNU gcc compiler version... configure: error:
> You need to use the gcc-4.0 compiler (gcc 4.2.1 won't work with the
> MacOSX10.4u.sdk) - set CC accordingly
> 
> It seems like that there is only gcc-4.2.1 in Mac OS X 10.7 with Xcode
> 4.1. The "MacOSX10.4u.sdk" is not supported by Mac OS X 10.7. There
> are only "MacOSX10.6.sdk" and "MacOSX10.7.sdk" under dir
> "/Developer/SDKs".
>$ ls /usr/bin/gcc*
>/usr/bin/gcc   /usr/bin/gcc-4.2

it is apparently possible to download and install the OS X 10.4 SDK even
on OS X 10.7.

http://catacombae.blogspot.com/2011/07/installing-xcode-326-in-mac-os-x-lion.html

> I'm going to remove the gcc-4.0 restriction and restart building.

there was a discussion some time ago on a different mailing list on this
topic; it should give you some ideas about the advantages and
disadvantages of doing this:

http://thread.gmane.org/gmane.comp.documentfoundation.libreoffice.devel/14099

> Is there anyone who built out AOOo successfully on Mac OS X 10.7
> (Intel) ? Thanks!

haven't heard of anybody doing that.

regards,
 michael

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

[Michael Stahl]

On 10.09.2011 20:31, Eike Rathke wrote:
> On Saturday, 2011-09-10 20:19:54 +0200, 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
> 
> Nice, will you apply and commit them?

have now committed all patches from the following CWSes:

- ooo340fixes
- mingwport35
- jsc341
- mh8tz (well, a single hunk of a single patch, the rest seemed obsolete)
- tkr41
- sw34bf06
- fs34c
- slidesorter1
- calc69
- automationooo340m0

the following CWSes have a 3.4 target but seem to be empty:

- tkr40
- jl167
- os152
- svg101

the following CWSes have a 3.4 target and are not integrated:

- jl166: this ugly critter contains lots of duplicate patches, and when
you finally manage to apply it the darn thing breaks the smoketest.
somebody who knows the basic interpreter should take a look at it.

- mba34issues01: somebody said that he would do this one;
  Mathias, how long do we have to wait...  :)

Re: why are there huge disparities for Ext modules at 2 pages

[Michael Stahl]

On 16.09.2011 08:15, Shao Zhi Zhao wrote:
> hi,
> 
> And there are 110 item at http://hg.services.openoffice.org/binaries/.

these are the files for _all_ historic versions of OOo.  the external
tarballs sometimes get updated, so you should see multiple versions of the
same library here, as well as libraries that are not used any more in the
most recent OOo version.

> if migration to AOOo,what is the real list?

the real list is the stuff that is referenced from the file "ooo.lst", in
the top-level of the source, as that is what is actually used in the build.

> At http://wiki.services.openoffice.org/wiki/External/Modules
> the count is 60 for the external modules.
> 
> In the section of Classification of OOo external source tarballs
> at the
> http://wiki.services.openoffice.org/w/index.php?title=ApacheMigration&printable=yes&printable=yes#TODO
> 
> there are 79 items.
> 
> why are there so much differences?

probably because the older page was not properly maintained and is out of
date.

regards,
 michael

Re: [PROPOSAL] turn off mail address mangling at Gmane

[Michael Stahl]

On 13.09.2011 11:29, Michael Stahl wrote:
> On 13.09.2011 02:57, NoOp wrote:
>> On 09/09/2011 02:25 AM, Michael Stahl wrote:
>>> On 05.09.2011 13:20, Michael Stahl wrote:
>>>> thus i propose to disable the address mangling at Gmane.
>>>>
>>>> If there are no objections to the above proposal within 72 hours then
>>>> I will invoke Lazy Consensus and proceed to implement the above
>>>> proposal.
>>>
>>> looks like nobody objected, so we have lazy consensus on this.
>>> i'll try to fix it now.
>>
>> Still there:
>> http://gmane.org/info.php?group=gmane.comp.apache.incubator.ooo.devel
> 
> my experience is that gmane stuff takes ~1 week, so we should be patient :)

via NNTP the addresses are now unmangled.

Re: [WINDOWS-BUILD] Can't successfully build the module of comphelper!

[Michael Stahl]

On 15.09.2011 07:33, 陈京东 wrote:

> Before building the module of comphelper, everything is ok! but when 
> compiling comphelper and generating the file - icomphelp.lib, an error 
> occurs, like this:
> 
> [ build LNK ] Library/icomphelp.lib

first, if you have a build problem it always helps to copy the complete
failed command, not just the abbreviated version.
i.e. try "cd comphelper && make -r"

> mktemp: unknown option -- -
> Usage: mktemp [-V] | [-dqtu] [-p prefix] [template]

that is unusual.

the relevant lines from solenv/gbuild/platform/windows.mk:

> gb_TMPDIR:=$(if $(TMPDIR),$(shell cygpath -m $(TMPDIR)),$(shell cygpath -m 
> /tmp))
> gb_MKTEMP := mktemp --tmpdir=$(gb_TMPDIR) gbuild.XX

what is the value of $TMPDIR in your environment, or, if it is not set,
what is the output of "cygpath -m /tmp" ?

it should not contain any spaces, that has always caused problems.

another reason for problems could be that your mktemp is not GNU mktemp,
or is some outdated version.
but if you have a recent Cygwin installed that should be used.

what is the output of "which mktemp" and "mktemp --version" ?

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

[Michael Stahl]

On 14.09.2011 17:23, Pedro F. Giffuni wrote:
> 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?)

perhaps. but see below :)

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

if it's not in a C standard at least 20 years old then usually MSVC
doesn't have it.

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

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.

Re: [PROPOSAL] turn off mail address mangling at Gmane

[Michael Stahl]

On 13.09.2011 02:57, NoOp wrote:
> On 09/09/2011 02:25 AM, Michael Stahl wrote:
>> On 05.09.2011 13:20, Michael Stahl wrote:
>>> thus i propose to disable the address mangling at Gmane.
>>>
>>> If there are no objections to the above proposal within 72 hours then
>>> I will invoke Lazy Consensus and proceed to implement the above
>>> proposal.
>>
>> looks like nobody objected, so we have lazy consensus on this.
>> i'll try to fix it now.
> 
> Still there:
> http://gmane.org/info.php?group=gmane.comp.apache.incubator.ooo.devel
> <http://gmane.org/info.php?group=gmane.comp.apache.incubator.ooo.devel&edit=t>
> 
> Encodeencrypt
> 
> If you've already submited the 'edit', sometimes it takes awhile for
> Lars to get around to making the change(s). If so, you can prod
> gmane.org on gmane.org/gmane.discuss.

my experience is that gmane stuff takes ~1 week, so we should be patient :)

Re: Umbrella projects

[Michael Stahl]

On 12.09.2011 18:08, Rob Weir wrote:
> But I'll propose a simpler solution.  We should make it easy to
> nominate and approve releases of language packs and full installs
> based on already approved source releases.  All we need is some
> indication from an expert that a given translation was ready.  This
> might be from a PPMC member, a Committer, or a number of Users on the
> user list who have tried a pre-release language pack snapshot.  We
> need to rely on expertise here, expertise outside of the PPMC.  But
> once we decide to spin a new release, I don't think why this is not
> most easily done by a vote on ooo-dev.  And I'd feel much better if
> the same volunteers who are building the core installs also built the
> 110 language versions.  It makes zero sense to have 330 different
> people doing this (110 languages x 3 platforms).  There is too much
> scope for error.

+1

at OOo it worked like this: Hamburg releng did localized builds for all
languages, then the NL communities did QA and (hopefully) approved the
release, possibly at a later time than the en_US release.  builds that
aren't approved aren't available for download by end users.

so the actual binary code in all the localized installation sets was the
same, just the UI resources and such differed.

regards,
 michael

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

[Michael Stahl]

On 10.09.2011 17:46, Eike Rathke wrote:
> Hi,
> 
> On Friday, 2011-09-09 15:40:06 +0200, Eike Rathke wrote:
> 
>> 2. Lookup 12fa3ee3d107 in calc68 with
>>$ hg log | less
>>* Verify that no OOO340 masterfix is above that revision, if there
>>  are lookup the topmost masterfix.
>> *  Next changeset on top in calc68 is af32685ae575
> 
> There is one problem with this approach if the CWS was rebased to
> a milestone and already had changes, they are lumped together in one
> merge changeset, recognizable by having two parents, for example in
> ooo34gsl01

i don't completely understand your problem, but here's how i have done it:

> for CWS in $(hg bookmarks | awk '{print $1}'); do hg export -o 
> "/tmp/hg-cws/${CWS}_%n_%h.patch" $(hg out -q --no-merges --template " -r 
> {node}" -r ${CWS} /home/ooo/OOO340); done

running this against a HG repo containing all CWSes bookmarked and a HG
repo containing only OOO340 results in >1900 patches totalling about 1G.

of course the merges cannot be converted so you'll have to re-do the
merge conflict resolution while applying the patches :(

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

regards,
 michael

Re: Re : change UI font size

[Michael Stahl]

On 09.09.2011 23:18, the mad doctor kaeding wrote:
> Making: libsotlx.so
> .../unxlngx6.pro/slo/ucbstorage.o: In function `Reference':
> /sources/new/openoffice/OOO330_m20/solver/330/unxlngx6.pro/inc/com/sun/star/uno/Reference.hxx:140:
> undefined reference to `non-virtual thunk to
> utl::OOutputStreamWrapper::acquire()'
> /usr/bin/ld: ../unxlngx6.pro/slo/ucbstorage.o: relocation
> R_X86_64_PC32 against undefined symbol `non-virtual thunk to
> utl::OOutputStreamWrapper::acquire()' can not be used when making a
> shared object; recompile with -fPIC
> /usr/bin/ld: final link failed: Bad value
> collect2: ld returned 1 exit status
> dmake: Error code 1, while making '../unxlngx6.pro/lib/libsotlx.so'
> 
> There are about a dozen such failures.  I worked around them, but am
> reporting them to you anyway.  I realize that noone is reading this
> message, but don't worry:  I am unsubscribing today.  Good luck.

what version of the code are you building?

these were known problems with the head of the OOO340 HG repo, but these
problems should be fixed in current ApacheOOo SVN; it builds with GCC
4.6 for me.

Re: [PROPOSAL] turn off mail address mangling at Gmane

[Michael Stahl]

On 05.09.2011 13:20, Michael Stahl wrote:
> 
> hi all,
> 
> the ooo-dev list is available at gmane.org for NNTP access and via a web
> frontend [0].
> 
> currently accessing this list via Gmane presents users not with the real
> mail addresses of posters, but with mangled mail addresses, for example
> .

funnily posting this through Gmane resulted in it de-mangling my example ;)

> thus i propose to disable the address mangling at Gmane.
> 
> If there are no objections to the above proposal within 72 hours then
> I will invoke Lazy Consensus and proceed to implement the above
> proposal.

looks like nobody objected, so we have lazy consensus on this.
i'll try to fix it now.

regards,
 michael

-- 
"I once asked an older coworker and Solaris guru what happened with the
 Unix-haters list.  He told me that it stopped being quite so funny
 once Windows NT came along." -- the gnat on slashdot.org

Re: [LINUX-BUILD] Developer Education -- Building on Linux event starts now

[Michael Stahl]

On 07.09.2011 21:08, Pavel Janík wrote:
>> it seems Eike has already committed your suggestion :)
>>
>> well, i don't care that much either way... as long as we can get a
>> working --with-lang build :)
> 
> Yup. And that should be done now.
> 
> Right now, we have to test if need source_config file and then we should be 
> done with the first step.

AFAIK source_config is the only way to get build.pl to look outside the
"main" repository/directory, so it is necessary.

given that we now have a more fixed directory layout with the SVN repo,
i guess it should be possible to hardcode the path to the "extras"
directory and have configure put something in the environment or just
make build.pl respect gb_REPOS which already exists, then we can finally
get rid of this source_config nonsense.

Re: [LINUX-BUILD] Developer Education -- Building on Linux event starts now

[Michael Stahl]

On 07.09.2011 20:49, Michael Stahl wrote:
> On 07.09.2011 20:19, Pavel Janík wrote:

> now, which way do you prefer?

it seems Eike has already committed your suggestion :)

well, i don't care that much either way... as long as we can get a
working --with-lang build :)

> regards,
>  michael

Re: [LINUX-BUILD] Developer Education -- Building on Linux event starts now

[Michael Stahl]

On 07.09.2011 20:19, Pavel Janík wrote:
> Hi,
> 
>> sorry, apparently i was writing in too much of a hurry earlier today to
>> mention that i had already committed my (partial) fix to SVN.
>>
>> it's almost the same as yours, except i've taught gbuild to live without
>> RepositoryFixes.mk (empty one is kind of pointless), and the
>> Repository.mk is in extras/l10n.
> 
> Repo*mk should be in extras because extras is a repository holding only one 
> module - l10n. This repository is needed only when --with-lang is specified.

is extras a repository?

i thought extras was supposed to be a container for repositories, each
of which is optional (independent of other ones), and l10n is the only
such repository currently existing.

vaguely remember some mails about this, e.g.:

http://mail-archives.apache.org/mod_mbox/incubator-ooo-dev/201108.mbox/%3c4e4aa8f9.3040...@gmx-topmail.de%3E

only problem is that build.pl/source_config may be too inflexible to do
it this way, but gbuild can  :)

so what we have currently is that build.pl thinks that extras is a
repository, while gbuild thinks that extras/l10n is a repository.

> - Repository.mk file should be moved level up from l10n to extras
> 
> - your change reverted (../l10n.. brought back, *Fixes* removal is OK)
> 
> - this patch applied:
> 
> Index: trunk/main/solenv/inc/settings.mk
> ===
> --- trunk/main/solenv/inc/settings.mk (revision 1166296)
> +++ trunk/main/solenv/inc/settings.mk (working copy)
> @@ -810,7 +810,7 @@
>  
>  .EXPORT : SOLARBINDIR
>  
> -L10N_MODULE*=$(SOURCE_ROOT_DIR)/l10n/l10n
> +L10N_MODULE*=$(SOURCE_ROOT_DIR)/extras/l10n
>  ALT_L10N_MODULE*=$(SOLARSRC)$/l10n_so
>  
>  .IF "$(WITH_LANG)"!=""
> Index: trunk/main/set_soenv.in
> ===
> --- trunk/main/set_soenv.in   (revision 1166296)
> +++ trunk/main/set_soenv.in   (working copy)
> @@ -1502,7 +1502,7 @@
>  
>  if ('@WITH_LANG@' ne "")
>  {
> -$gb_REPOS .= " ".$SOURCE_ROOT_DIR."/extras/l10n";
> +$gb_REPOS .= " ".$SOURCE_ROOT_DIR."/extras";
>  $BUILD_TYPE = "@BUILD_TYPE@ L10N";
>  }

that would work as well of course :)

now, which way do you prefer?

regards,
 michael

Re: [LINUX-BUILD] Developer Education -- Building on Linux event starts now

[Michael Stahl]

On 07.09.2011 13:49, eric b wrote:
> Hi Michael,
> 
> 
> thanks for your feedback :)

hi Eric,

sorry, apparently i was writing in too much of a hurry earlier today to
mention that i had already committed my (partial) fix to SVN.

it's almost the same as yours, except i've taught gbuild to live without
RepositoryFixes.mk (empty one is kind of pointless), and the
Repository.mk is in extras/l10n.

> On my side, I'm testing something who seems to work, but I need  
> confirmation (build in progress on Windows). The idea was triggered  
> by Fabien Dobat remark (a student trying to build with me), because  
> of a bad  gb_REPOS
> 
> then I found two issues, one in set_soenv.in and one in solenv/inc/ 
> settings.mk

and i've completely overlooked settings.mk; guess my build will be only
partially localized then :)

> If I add the files and the instructions Pavel Janik told me, I got a  
> build who started, and a l10n directory found (remains a strange  
> issue in comphelper though).
> 
> 
> See:  http://ftp.educoo.org/home/ericb/patches/apache_ooo/sources_trunk/

are you a Committer?

if yes. please commit the following from your patch (the rest should be
in SVN already):

Index: main/solenv/inc/settings.mk
===
--- main/solenv/inc/settings.mk (revision 1166043)
+++ main/solenv/inc/settings.mk (working copy)
@@ -810,7 +810,7 @@

 .EXPORT : SOLARBINDIR

-L10N_MODULE*=$(SOURCE_ROOT_DIR)/l10n/l10n
+L10N_MODULE*=$(SOURCE_ROOT_DIR)/extras/l10n
 ALT_L10N_MODULE*=$(SOLARSRC)$/l10n_so

 .IF "$(WITH_LANG)"!=""


> 1) put and apply the patch from the same location (as the same level  
> as main and extras
> 2) copy source_config
> 3) copy the Repository*.mk inside extras
> 
> Thanks to Pavel Janik for his help and his patience  :-)

sorry for having duplicated your work :)

> Eric

Re: [code] [PUSHED] build on Linux 64 bits (Fedora 15)

[Michael Stahl]

On 01.09.2011 23:25, Ariel Constenla-Haile wrote:
> * enabling the OpenGL transitions:
> 
> Compiling: slideshow/source/engine/OGLTrans/OGLTrans_TransitionerImpl.cxx
> slideshow/source/engine/OGLTrans/OGLTrans_TransitionerImpl.cxx: In member 
> function 'bool {anonymous}::OGLTransitionerImpl::createWindow(Window*)':
> slideshow/source/engine/OGLTrans/OGLTrans_TransitionerImpl.cxx:490:28: error: 
> 'FALSE' was not declared in this scope
> slideshow/source/engine/OGLTrans/OGLTrans_TransitionerImpl.cxx:496:28: error: 
> 'FALSE' was not declared in this scope
> slideshow/source/engine/OGLTrans/OGLTrans_TransitionerImpl.cxx:520:68: error: 
> 'FALSE' was not declared in this scope
> slideshow/source/engine/OGLTrans/OGLTrans_TransitionerImpl.cxx:546:34: error: 
> 'TRUE' was not declared in this scope
> slideshow/source/engine/OGLTrans/OGLTrans_TransitionerImpl.cxx:548:36: error: 
> 'FALSE' was not declared in this scope
> dmake:  Error code 1, while making 
> '../../../unxlngx6.pro/slo/OGLTrans_TransitionerImpl.obj'
> 
> seems the code missed the removal of the old tool's types.

have pushed your patch for this

> * enabling dbus:
> 
> [ build CXX ] vcl/unx/gtk/window/gtkframe
> vcl/unx/gtk/window/gtkframe.cxx:67:28: fatal error: dbus/dbus-glib.h: No such 
> file or directory

have pushed your patch for this

by the way (should have asked this before), can you confirm that you
have the copyright for the patches?

(actually they're probably too small to be copyrighted, but just to be
sure...)

regards,
 michael

Re: [LINUX-BUILD] Developer Education -- Building on Linux event starts now

[Michael Stahl]

On 07.09.2011 09:13, eric b wrote:

> B) More important :
> 
> * l10n causes a big breakage, and you must avoid using --with-lang= 
> 
> If ever a workaround exists, we should put it online, urgently.
> 
> Have people building Apache OpenOffice.org is extremely important,  
> and I'm ready to help the one interested.

tried to fix this now, please try if you can get a --with-lang build.

(haven't tested myself, my build will take some hours and i'll be away
now...)

oh, guess you need a "source_config" in the "ooo" directory (which
contains "main"/"extras") containing:


[repositories]
main=active
extras=active


(btw, if only somebody please removed this source_config nonsense...)

> C) Design issue :
> 
> Last but not least, we have Oracle logo at launch, in the  
> splashscreen, and I'd like to know whether there is a plan for a new  
> Design ? Ben Bois, our Designer (he did OOo4Kids and OOoLight  
> design), is ok to help for new colors, and so on.

of course the Oracle branding will have to be removed.

> On my side, I know well this part of code, and I could even replace  
> the .bmp with a .png file at launch in the splashscreen. Better : we  
> (including me) could mentor a student to make it ?

any efforts in this direction are appreciated, so go for it :)

regards,
 michael

Re: Who wants to build OpenOffice?

[Michael Stahl]

On 06.09.2011 14:47, Rob Weir wrote:

> 4) apt-get build-dep openoffice.org was insufficient.  I received
> configure errors after that and had to install many packages in
> addition

well, it's a start :)

> 5) I'm not at that machine right now to look up the details, but I had
> to copy down what appeared to be a mingw-compiled file from the
> website and put it into the externals directory.  I didn't see that
> called out in the instructions

that's one way of doing it; the other is to install a MinGW cross
compiler, which is nowadays available for all major Linux distros.

e.g. on Fedora 'yum install mingw32-gcc-c++'

but i think you have to tell configure about it explicitly:

./configure --with-mingwin=i686-pc-mingw32-g++

Re: Bugzilla e-mail is bouncing and other e-mail issues

[Michael Stahl]

On 05.09.2011 16:12, Eike Rathke wrote:
> Hi,
> 
> On Monday, 2011-09-05 08:51:46 +0100, Mark Thomas wrote:

>> 1. These accounts need to be switched to ASF mailing lists. Please
>> identify the required changes and open a Jira ticket with the
>> infrastructure team to implement the changes.
> 
> I propose the issues@*.openoffice.org lists are bundled in one single
> ooo-iss...@incubator.apache.org instead.
> 
> In active times, the volume on the general all-bugs list was unbearable
> and even on some issues@*.oo.o lists was very high, especially for the
> main applications and l10n project, so at the end maybe 5 or
> 6 additional ooo-issues-*@i.a.o will be needed where people can
> subscribe to their area of interest.

agree that a single list is sufficient for now.

>> 3. The assigned to field is set to just about anything other than
>> ooo-dev@incubator.a.o. In the main ASF Bugzilla instance, this field is
>> hard-coded to the relevant project's dev list and is read-only. This
>> ensures that any updates to any issue are sent to the dev list. ASF
>> policy requires that all issue tracker updates are sent to a project
>> mailing list (usually dev@ or issues@) so that the community is aware of
>> updates to the issues. Please decide how you want to handle this and
>> then open a Jira ticket with the infrastructure team to make the changes.
> 
> Any opinions on creating one ooo-issues@i.a.o for now and maybe
> additional ones later as needed?

a certain Joe has already done this back in June:

> http://mail-archives.apache.org/mod_mbox/incubator-general/201106.mbox/%3c868065.36930...@web161423.mail.bf1.yahoo.com%3E

guess it just needs hooking up to bugzilla.

[PROPOSAL] turn off mail address mangling at Gmane

[Michael Stahl]

hi all,

the ooo-dev list is available at gmane.org for NNTP access and via a web
frontend [0].

currently accessing this list via Gmane presents users not with the real
mail addresses of posters, but with mangled mail addresses, for example
.
when replying to such an address, the gmane.org mail server will forward
the mail to the real (unmangled) address only after the sender has
answered a confirmation mail.
this makes it difficult for spammers to scrape the real mail addresses.

as has been discussed in a thread[1] on ooo-dev recently this mangling
is annoying.

as Gary Lee pointed out[2], the Apache mail archive itself already makes
the raw content of mails including real mail addresses available to web
scrapers, for example [3].

thus i propose to disable the address mangling at Gmane.

If there are no objections to the above proposal within 72 hours then
I will invoke Lazy Consensus and proceed to implement the above
proposal.

regards,
 michael

PS: amazingly, if you look at the gmane.org homepage right now, ooo-dev
is the 5th most active list today.

[0] http://dir.gmane.org/gmane.comp.apache.incubator.ooo.devel

[1]
http://mail-archives.apache.org/mod_mbox/incubator-ooo-dev/201108.mbox/%3C002101cc6020$aba79b90$02f6d2b0$@acm.org%3E

[2]
http://mail-archives.apache.org/mod_mbox/incubator-ooo-dev/201108.mbox/%3Cj345us$gmt$1...@dough.gmane.org%3E

[3]
http://mail-archives.apache.org/mod_mbox/incubator-ooo-dev/201108.mbox/raw/%3C002101cc6020$aba79b90$02f6d2b0$@acm.org%3E

Re: Who wants to build OpenOffice?

[Michael Stahl]

On 01.09.2011 10:33, Marc-Oliver Straub wrote:
> RedHat Enterprise Linux 5.6 64-bit, gcc 4.1.2
> 
> ../configure --disable-mozilla --without-junit
> 
> checking whether to enable RandR support... checking for XRANDR... no
> checking X11/extensions/Xrandr.h usability... no
> checking X11/extensions/Xrandr.h presence... yes
> configure: WARNING: X11/extensions/Xrandr.h: present but cannot be compiled
> configure: WARNING: X11/extensions/Xrandr.h: check for missing 
> prerequisite headers?
> configure: WARNING: X11/extensions/Xrandr.h: see the Autoconf documentation
> configure: WARNING: X11/extensions/Xrandr.h: section "Present But 
> Cannot Be Compiled"
> configure: WARNING: X11/extensions/Xrandr.h: proceeding with the 
> compiler's result
> checking for X11/extensions/Xrandr.h... no
> configure: error: X11/extensions/Xrandr.h could not be found. X11 dev 
> missing?
> 
> Adding --disable-randr to the configure flags succeeds.

you'd need to look at the config.log to see why it couldn't use the
Xrandr.h.

perhaps some package is missing that we don't explicitly check for.

> However, I see the following error in the configure output:
> The variable COMMON_BUILD_TOOLS is set to: $SRC_ROOT/external/common
> Use of uninitialized value in string eq at ./set_soenv line 1987.
> The variable TMPDIRis set to: /tmp

seems to be this test:
   if ( $ENV{"TMPDIR"} eq "" ) {
  ToFile( "TMPDIR",  "/tmp",   "e" );
   } else {
  ToFile( "TMPDIR",  "$ENV{'TMPDIR'}", "e" );
   }

perhaps somebody who knows Perl could rewrite this so it doesn't give a
spurious warning...

-- 
PCMCIA - People Can't Memorize Computer Industry Acronyms

Re: Who wants to build OpenOffice?

[Michael Stahl]

On 31.08.2011 02:32, Dennis E. Hamilton wrote:
> I'll bite.  I've got a Dell XPS 9100 running Windows 7 x64 with 1.6TB
> free on the HD (only 7200RPM though, keeps my Windows Experience
> Index at 5.9 - everything else in 7.7-7.8), 18GB DDR3 RAM, and Intel
> i7X980 processor.  I've got a few more TB on a LAN-based server; I
> suspect compiling from an SVN Working Copy there is probably not a
> smart idea, though I could try that someday.

in Hamburg we have a lot of experience with building OOo over network
filesystems.

this works very well for any real UNIX system over NFS (takes maybe 2-3x
longer than a build on local storage), but with Windows it's a complete
non-starter; IIRC over the native Samba protocol (or whatever it's
called) it takes something like 50x longer (yes, 50 times), and via
various Windows NFS clients it was faster but never worked reliably.

for this reason we had infrastructure to do automated builds on Windows
by copying the whole source tree over the net via rsync (which is fast
even on Windows), then building on the local storage, then rsync the
build output back.

> I already have an SVN Working copy on the local HD.  I am certain
> there are tools I don't have.  I am also running Visual C++ 2010 (not
> 2008) Express Edition on this box, so that will provide an
> interesting challenge.  Microsoft SDK v7.1 is installed but I don't
> seem to have the 64-bit compiler.

i don't believe we have a working windows 64-bit build yet, so you
should use 32-bit compiler anyway.

> Many dots remain to be connected, I'm certain.
> 
> - Dennis
> 
> Just for laughs, I also have the Subsystem for Unix Applications
> (SUA) set up, but building a Posix native for Windows (and XServer)
> is probably an even greater stretch.  I intend that for confirming
> that command-line tools and libraries I build for Windows are also
> portable to *nix to a first approximation.

for the Windows build we currently require Cygwin; perhaps it would be
possible to build with this Microsoft UNIX thing instead, but i don't
think anybody has tried it.

> Oh, and I have virtual PC and have OpenBSD in one of the VMs.  I
> could also make another Windows XP VM if necessary, perhaps with
> Visual C++ 2008 Express Edition.

be aware that building in a VM takes quite a bit longer.

regards,
 michael

-- 
"This isn't about what is," said Mr Nancy.  "It's about what people
 _think_ is.  It's all imaginary anyway.  That's why it's important.
 People only fight about imaginary things." -- Neil Gaiman, American Gods

Re: Commit messages

[Michael Stahl]

On 30.08.2011 17:53, Tor Lillqvist wrote:
>>> 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 that gave OOo a bad
> reputation among people who then created LibreOffice?

i also think that requiring an issue id and thus an issue in the
bugtracker for every commit is overkill.

there are lots of trivial problems that always pop up (especially
considering that we support many different platforms, and it's not
really possible to test all of them before every commit).

on the other hand, if there already is an issue for whatever is fixed by
a commit, then that commit should be required to contain the issue id.

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

indeed, that sometimes bothered me in the past as well.

if a bug fix isn't totally obvious, then there should be a comment
somewhere, whether in the code, the commit message, or the issue
referred to by the commit message, as to what went wrong and why this is
the right fix.

> --tml

regards,
 michael

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

[Michael Stahl]

On 30.08.2011 08:47, Stephan Bergmann wrote:
> On Aug 29, 2011, at 9:26 PM, Pedro F. Giffuni wrote:
>>> any reason why we build our own preprocessors and don't use the C
>>> toolchain preprocessor that is already required to build OOo?
>>> 
>> 
>> 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.
> 
> 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.

that's the question i never dared to ask ;)

i hate cpp:  it is an automated copy-paste mechanism to do things for
which a real programming language provides a module system.
let's get rid of it where possible.

then we can also remove the ugly external header guards clutter.

> Would still have to have a look at soltools/cpp, though...
> 
> -Stephan

regards,
 michael

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

[Michael Stahl]

On 29.08.2011 18:55, Jürgen Schmidt wrote:
> On Mon, Aug 29, 2011 at 6:31 PM, Stephan Bergmann <
> stephan.bergmann.second...@googlemail.com> wrote:

>> By the way, the source code at idlc/source/preproc appears to be copied
>> from LCC code (see ) and then
>> erroneously decorated with the OOo license header.  This needs to be
>> addressed.  Similarly, the code at soltools/cpp appears to be a second copy
>> of that code, with the same memcpy error, but at least without the erroneous
>> OOo license headers.
>>
> 
> oh the good old preproc code from Horst (i am sure some of you know who
> Horst is -> it's an insider joke from the early days and before OOo was
> born).
> 
> With the cleanup of this license headers we can try to remove the code in
> one place and reuse it.

any reason why we build our own preprocessors and don't use the C
toolchain preprocessor that is already required to build OOo?

Re: SVN and bringing the total end-to-end OOo project under Configuration Management

[Michael Stahl]

On 29.08.2011 16:40, Terry Ellison wrote:
> Thanks for comments. Rob.  I was hoping to get your and others thoughts 
> on this TLD structure issue:  Where do we plug the wiki, the forums, the 
> other website services into our svn hierarchy (where =the relevant 
> service):
> * incubator/ooo/site/trunk/
> or
> * incubator/ooo/site//trunk
> or where?
> 
> There's no clear slot in our current TLD structure.  I've put my 
> responses on the rest below.

i don't understand at all why "site" contains "trunk", does anybody
really want to branch it?

> On 29/08/11 14:59, Rob Weir wrote:

>> 2) Our customizations occur in a branch
> Tried this before on projects.  It really doesn't work.  There are 
> ~2,500 files of which we update about 20-30 with a single patch file.  
> If we do it the way you suggest, we would have a huge bulk of revisions 
> every phpBB release.  It's a lot easier to keep the build script and the 
> patch file under CM and then we only have two files to update every 
> release.

perhaps a patch tracking tool like "quilt" would be appropriate?

http://savannah.nongnu.org/projects/quilt/

it allows to have not just a single big patch but multiple patches, each
one containing one "logical change".

then the patches and quilt metadata can be put into SVN.

(i have been using a versioned HG Mercurial Queue against the OOo repo,
which is quite similar in approach...)

regards,
 michael

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

[Michael Stahl]

On 29.08.2011 15:27, Rob Weir wrote:
> I sent this note out a week ago.  We discussed and generally agreed to
> this proposal.  I certainly did not see any objections. But this plan
> appears to have been generally ignored.
> 
> In particular, we now have unrelated changes intermingled with the
> addition of missing files from Hg.  This means that there is no
> revision in SVN that is identical to the Hg tip. This is unfortunate.
> It will make some approaches to merging more difficult.

indeed.  oops.

unfortunately your proposal contained more items than i could remember :-/

but i guess we can take the initial import as the base revision, there
shouldn't be that many changes to the dozen or so missing files.

> Let's review this list again, and try better to coordinate going
> forward.  If anyone has improvements on the list, please feel free to
> comment.  But's let get on the same page.

for the most part the items 2 to 5 can be done in parallel, right?

guess item 6 also (restricted to CWSes with target 3.4)

regards,
 michael

SVN clients: svn, git-svn

[Michael Stahl]

hi all,

i've checked out the Apache OOo trunk yesterday and committed some
changes required to build it on my system.

the official SVN client (version 1.6.17) likes to store every file that
is checked out in uncompressed form, which takes a lot of space.

>  > du -sh trunk/
> 4,2G  trunk/

fortunately you don't have to use the official SVN client; there are
unofficial clients that are a bit more comfortable, notably HgSubversion
and git-svn.

e.g. install git-svn on Fedora:

su -c 'yum install git-svn'

check out the OOo repo like this:

> git svn clone --username=myapacheid --stdlayout --revision 1162287:HEAD  
> https://svn-master.apache.org/repos/asf/incubator/ooo/

notes:

1. set up --username correctly!

2. if the revision range isn't specified then git-svn will spend a
_very_ long time looking at all revisions.

3. do not use svn.apache.org, but svn-master.apache.org. (see below)

because git uses data compression this takes much less space (but the
repacking does takes some time):

>  > du -sh ooo/
> 2,3G  ooo/

now you can commit to the local git repository (but don't merge! git-svn
can't handle that).

if you want to update from the SVN server use "git svn rebase", which
will also rebase your work on top of the SVN HEAD (conflict resolution
may be required).

to push changes to the SVN server use "git svn dcommit"


Q: so why not use svn.apache.org but svn-master.apache.org?

this is because svn.apache.org may go to either the master server or a
mirror; when i used svn.a.o and "git svn dcommit" to push my changes,
there was always an error and after every commit i had to manually call
"git svn rebase" and then dcommit again (most annoying).  the reason is
that the mirror synchronization is not instantaneous, and so git-svn
gets stale data from the mirror server.
see also:
http://web.archiveorange.com/archive/v/WwUr9JnfRyrEj8hOH5jY

regards,
 michael

Re: svn commit: r1162610 - in /incubator/ooo/trunk/main: binfilter/bf_sfx2/source/doc/ binfilter/bf_starmath/source/ binfilter/bf_svtools/source/misc/ chart2/source/view/main/ slideshow/source/engine/

[Michael Stahl]

On 29.08.2011 10:44, Mathias Bauer wrote:
> On 29.08.2011 10:35, Michael Stahl wrote:
> 
>>> Is it wise to fix the code for gcc 4.6 *now*? Every fix might introduce
>>> new bugs and gcc 4.6 is not the "standard" compiler nowadays (AFAIK).
>>
>> please note that i will have a difficult time contributing if i can't
>> build the code :)
> 
> Which distribution comes with gcc 4.6 as default?

Fedora 15, for one.

Re: svn commit: r1162609 - in /incubator/ooo/trunk/main: autodoc/inc/ary/idl/ basegfx/source/polygon/ chart2/source/controller/main/ dbaccess/source/core/dataaccess/ hwpfilter/source/ libwpd/ moz/ moz

[Michael Stahl]

On 29.08.2011 02:27, Eike Rathke wrote:
> Hi Michael,
> 
> On Sunday, 2011-08-28 23:23:03 -, m...@apache.org wrote:
> 
>> URL: http://svn.apache.org/viewvc?rev=1162609&view=rev
> 
>> --- incubator/ooo/trunk/main/autodoc/inc/ary/idl/i_ce2s.hxx (original)
>> +++ incubator/ooo/trunk/main/autodoc/inc/ary/idl/i_ce2s.hxx Sun Aug 28 
>> 23:23:03 2011
>> @@ -50,6 +50,7 @@ class Ce_2s
>>  {
>>public:
>>  // LIFECYCLE
>> +explicit Ce_2s () { }
>>  virtual ~Ce_2s();
>>  
>>  static DYN Ce_2s *  Create_(
> 
> I took a different approach without introducing that ctor:
> https://svn.apache.org/viewvc/incubator/ooo/trunk/main/autodoc/source/ary/idl/i_ce.cxx?r1=1162288&r2=1162554&pathrev=1162554&diff_format=h
> 
> IMHO holding a const dummy just to be able to return a const reference
> if the factory didn't yet create an instance is nonsense.

indeed you are right; i just failed to remove this from the patch that i
had laying around for weeks (and i had not actually looked at the use
site back then which indeed was nonsense).

Re: svn commit: r1162610 - in /incubator/ooo/trunk/main: binfilter/bf_sfx2/source/doc/ binfilter/bf_starmath/source/ binfilter/bf_svtools/source/misc/ chart2/source/view/main/ slideshow/source/engine/

[Michael Stahl]

On 29.08.2011 09:36, Mathias Bauer wrote:
> On 29.08.2011 02:36, Eike Rathke wrote:
>> Hi Michael,
>>
>> On Sunday, 2011-08-28 23:34:31 -, m...@apache.org wrote:
>>
>>> URL: http://svn.apache.org/viewvc?rev=1162610&view=rev
>>> Log:
>>> unotools: OOutputStreamWrapper:
>>>
>>>   remove invocation of DECLARE_UNO3_AGG_DEFAULTS
>>>   (symbols are somehow not exported with GCC 4.6, and it seems to be
>>>   unnecessary)
>>
>> The "somehow" may be related to the -fPIC vs -fpic I mentioned in an
>> earlier mail.

i vaguely remember having tried this many weeks ago, but it didn't seem
to help.  perhaps i tried it on the wrong file...

presumably it should make a difference on x86_64.

>> Simply removing the DECLARE_UNO3_AGG_DEFAULTS(...) removes
>> forwarding of acquire() and release() calls to the baseclass, I don't
>> think that's correct. See comphelper/inc/comphelper/uno3.hxx

but OOutputStreamWrapper is derived from ::cppu::WeakImplHelper1, which
implements the acquire()/release() methods itself (public).  so client
code should simply call these base class methods and the manual
forwarding done by the macro seems entirely superfluous to me.  (there
are certainly already hundreds of classes that derive from
WeakImplHelper* but don't override acquire()/release().)

> Is it wise to fix the code for gcc 4.6 *now*? Every fix might introduce 
> new bugs and gcc 4.6 is not the "standard" compiler nowadays (AFAIK).

please note that i will have a difficult time contributing if i can't
build the code :)

> Regards,
> Mathias

regards,
 michael

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

[Michael Stahl]

On 28.08.2011 19:12, Eike Rathke wrote:
> Fourth, now I'm stuck at module offapi where idlc bails out with completely
> senseless messages:
> 
> Entering /build/aooo/main/offapi/com/sun/star/sdb
> 
> Compiling: Forms.idl
> ../../../../com/sun/star/ucb/Content.idl(296) : Illegal syntax following 
> service member declaration: syntax error, unexpected IDL_IDENTIFIER
> ../../../../com/sun/star/ucb/Content.idl(311) : Statement can not be parsed: 
> property
> ../../../../com/sun/star/ucb/Content.idl(313) : Statement can not be parsed: 
> syntax error, unexpected '-', expecting ';'
> 
> and 100s more after that. Content.idl line 296 and following are in the
> middle of comments, apparently idlc attempts to parse those as idl
> definitions. Currently I have no idea why.

i have had the exact same problem trying to build OOO340m1 on my Fedora
box.  for now i've just worked around the problem by removing the big
100s-line comment in Content.idl, then invoking "build" in offapi, then
putting the comment back.  strangely it only happens when building files
that include Content.idl, not with Content.idl itself.

guess it's some bug in idlc, or perhaps a compiler bug (gcc 4.6.0 here).

regards,
 michael

Re: Update on SVN dump load

[Michael Stahl]

On 25.08.2011 23:08, Michael Stahl wrote:
> On 25.08.2011 22:17, eric b wrote:
>> As promised, an update : I verified all the issues Pavel encountered  
>> in dictionnaries and readlincense_oo , excepted that I'm stuck (means  
>> build broken) in comphelper, due to a too old gnumake (3.80, need :  
>> 3.81)
>>
>> So we can consider the build is definitively broken on Mac OS X 10.4.  
>> Will restart a build on Linux later.
> 
> that's not a build breaker, your installation is just outdated :)

sorry, of course it breaks the build, what i meant to say is that it
can't and won't be fixed in the OOo code.

Re: Update on SVN dump load

[Michael Stahl]

On 25.08.2011 22:17, eric b wrote:
> As promised, an update : I verified all the issues Pavel encountered  
> in dictionnaries and readlincense_oo , excepted that I'm stuck (means  
> build broken) in comphelper, due to a too old gnumake (3.80, need :  
> 3.81)
> 
> So we can consider the build is definitively broken on Mac OS X 10.4.  
> Will restart a build on Linux later.

that's not a build breaker, your installation is just outdated :)

the new build system requires at least GNU make 3.81.

the release 3.81 suffers from bug 20033 which causes GNU make to
segfault occasionally when building with >1 jobs; it's fixed in 3.82, so
get that if you need a new one anyway.

> dmake:  Error: -- `THIRDPARTYLICENSEREADME.html' not found, and can't  
> be made

known missing file

(and the others also...)

btw on linux GStreamer stuff doesn't build, i sent a patch for this on
this list long time ago...

perhaps it would make sense to wait with the building until the already
known issues are fixed :)

regards,
 michael

Gmane address encryption (was: Re: [What?] Why and How did this reach my inbox?)

[Michael Stahl]

On 24.08.2011 22:39, Larry Gusaas wrote:
> 
> On 2011-08-24 11:42 AM  Michael Stahl wrote:
>> On 23.08.2011 21:25, Dennis E. Hamilton wrote:
>>> How about the mangling of the To address?  When I get one of
>>> these, I cannot use any rules because the To address that my mail
>>> client sees is not that of ooo-dev but some hacked-up pseudo
>>> gmane address.
>> when signing up a mailing list at Gmane there is a checkbox whether
>> the mail addresses (as seen by Gmane users) should be mangled or
>> not; this feature is intended to prevent address harvesting and
>> thus deter spammers.
> Can that feature be changed? Is it necessary?

it seems there is a form on the Gmane site where the list information
can be edited, including the mangling (it is called "encryption").

but before changing it we should ensure that posters on this list are
not concerned about potentially getting more spam.

(haven't checked whether any of the various other sites that archive
this list expose the mail addresses to scraping by spammers)

> None of the OOo or LibreOffice lists that I follow with Gmane have
> mangled addresses. Nor do the other lists I follow.

of the LO lists that i look at occasionally only the main development
list seems to have the mangling enabled, the other ones not.

regards,
 michael

Re: [What?] Why and How did this reach my inbox?

[Michael Stahl]

On 23.08.2011 21:25, Dennis E. Hamilton wrote:
> How about the mangling of the To address?  When I get one of these, I
> cannot use any rules because the To address that my mail client sees
> is not that of ooo-dev but some hacked-up pseudo gmane address.

when signing up a mailing list at Gmane there is a checkbox whether the
mail addresses (as seen by Gmane users) should be mangled or not; this
feature is intended to prevent address harvesting and thus deter spammers.

> I have a different question.
> 
> According to the information on GMANE, it takes someone who claims to
> be an administrator to offer up a mailing list for aggregation
> there.
> 
> Who did that and where was it discussed here?  I suspect I may have
> seen an off-hand mention but I had no idea what the consequences were
> at that point.

guilty party here.

i plead mitigating circumstances: i did it with good intentions.

i thought signing up our mailing lists with Gmane would annoy the heck
out of Dennis Hamilton.  errr, no, wait a minute, my memory is playing
tricks on me again...

ah, now i remember: i did it to make our project more accessible to the
wider FOSS community and encourage some participation.  yeah, that was it.

and in my defense, digging through my cache i found that on this list
some 78 messages have been posted via Gmane, from 6 distinct authors.

> Finally, wholesale harvesting of someone's e-mail list raises serious
> netiquette issues far beyond concerns for top posting, CC additions,
> etc.  When did we consider what we expect of that and also what does
> it not being on Apache infrastructure raise as a concern?

it's a public mailing list.  what concerns would be raised by additional
mirroring?

> - Dennis

regards,
 michael

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

[Michael Stahl]

On 21.08.2011 19:43, Mathias Bauer wrote:
> As there is a lot to do, we need to coordinate. If we had an issue
> tracker, we could submit tasks an let people assign themselves to the
> tasks. But for the time being we have to do it differently.

we could use the OOo bugzilla, the ooo-dev list or the wiki (well, one
of the many wikis).

> As Eike and I already successfully made a Linux build without most of
> the external copy-left components, we should get these patches in early.
> Then we can work on my task list in the OOo wiki and perhaps some more
> tasks we will find on our way through the code.
> 
>> 6) Then I think we can open it up to integrating CWS's, fixing bugs, etc.
> 
> We should integrate only those cws that have been created to become part
> of OOo 3.4. http://eis.services.openoffice.org tells me 12 candidates:
> svg101, os152, calc69, tkr41, tkr40, sw34bf06, ooo340fixes, native373,
> mba34issues01, fs34c, calc68, automationooo340m0. Only candidates, not more.

i found these (haven't actually looked at them, probably some of these
are empty):

nominated 3.4:

impress212
ooo34gsl01
jl167
calc67
ooo34gsl02
calc68
native373

approved 3.4:

jsc341

readyforQA 3.4:

mh8tz
sw34bf06
mingwport35
tkr41

new 3.4 and on >m100:

slidesorter1
jl166
fs34c
ooo340fixes
tkr40
mba34issues01
os152
calc69
svg101

automationooo340m0 (only for 3.4 branch?)

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

[Michael Stahl]

On 21.08.2011 19:25, Marcus (OOo) wrote:
> Am 08/21/2011 06:48 PM, schrieb Rob Weir:
>> 1) Initially, only changes are made to make SVN to more perfectly
>> match the Hg tip.  We know there are 10 or so files that need to be
>> checked in, with attention to EOL style.  And there was a suggestion
>> to update the memo of the initial checkin.   Let's get that work done,
>> and then tag that revision with a memorable label, before we make any
>> other changes.  (Should also give a tag to the current Hg tip)
> 
> +1

+1

>> 2) Registration of any cryptographic code in OOo (required for US
>> Export regulations, not sure if this was previously required when OOo
>> was hosted in Germany).
> 
> OOo was already hosted in the US, so IMHO need for any additional things.

what is the deadline for this?
hope it is not "ASAP" and it does not have to block the other work...

>> 3) Then do what is necessary to enable anyone who wishes to build to
>> do so.  So confirm we can build, add files, etc., if they are missing.
>>   Get instructions onto the website, or links to instructions.
>> Everything we do after this is easier if we first enable more people
>> to work with the code.
> 
> +1

yes; i've already sent a couple of patches to get it to build on my
Fedora box many weeks ago...

>> 5) Identification and removal of any code that does not have a
>> compatible license
>>
>> 6) Then I think we can open it up to integrating CWS's, fixing bugs, etc.
>>
>>
>> Does this make sense?  I'm open to variations on this, but I think we
>> need to stage the work somewhat like the above.
> 
> If we cannot do AOO 3.4 as a kind of exceptional release then we have to 
> do 5) before the release.

is it possible to do 5) and 6) in parallel?

then several people can work on different things.

> Furthermore, we really have to think when exactly we need to branch, so 
> that we have the first branch for a AOO 3.4 release and the endless 
> trunk "branch". IMHO we should do it at latest before 6).
> 
> Please don't put everything new into the same branch!
> 
> We had OOo 3.4 already in Beta mode and I don't recommend to open up 
> this again for our first release. We should finish the work for the 
> nearly finished codeline, learn how the things are working and take this 
> into account when preparing for the next release.

"when to branch for 3.4 release" is a very good question.

one thing i really don't want to do with SVN is to merge that release
branch back into the trunk (we used to do that with our OOO330 HG
repository, but that was HG... sigh...).

so this would mean to do the licensing cleanup before creating the 3.4
release branch (otherwise we'd have to do it twice).

also, the CWSes that are targeted at 3.4 should be integrated before the
branch-off.

then there are some CWSes that aren't targeted at 3.4, but could be
integrated now.

the obvious option is that these cannot be integrated until the release
branch is created.  this is definitely the risk-minimizing option.

another option would be to look if we consider some of these "low-risk"
enough to re-target them to 3.4.

regards,
 michael

-- 
"Beware of the Turing tar-pit in which everything is possible
 but nothing of interest is easy." -- Alan Perlis

Re: A point on the OOo code

[Michael Stahl]

On 19.08.2011 08:21, eric b wrote:

Hi,


My starting point was : I'm used to the OOo source code, but I do not
know how to retrieve an old cws. In fact, I don't know at all what do ..

We suppose that I currently got an hg blob, containing until DEV300_m93
(which is sufficient for my needs / tests). Add that I know how to
extract a milestone, compile it, and create diffs.


Q1 : is it possible to explain a dummy like me :

- how to download the current code (the OOo milestone we'll take as
starting point), using svn (only the instruction with the right URL is
ok for me)

Note : even if the tree is not complete, but what is the command, or
what will be the command ?


don't know (AFAIK code is not yet imported?)


Q2 : how to connect the hg code to the svn one ?


what do you mean by "connect"?
how to migrate the not-yet-integrated code in CWSes?


Q3 : how to retrieve an old cws and extract the diff ? I read the wiki,
and found nothing usefull on the mercurial side, and be able to retrieve
something in the history is essential.


i always do something like "hg log | less" and then search for the CWS 
name; the first commit that is found is usually the merge commit that 
integrates the CWS into the master.


you can get all the changes that were made in the CWS by doing a "hg 
diff" of this commit against the parent that corresponds to the master 
(in almost all cases this is the first parent).


for example for sb111 the integration merge is 019ac597e5e0.

the -c option to diff uses the first parent as base revision, so you can 
get all of the changes introduced by the CWS by "hg diff -c 019ac597e5e0".


if it's the second parent then i guess you would need something like "hg 
diff -r $second_parent_id -r $child_id".


if you want to see the individual commits that were introduced by the 
CWS then it's a bit more complicated; at OOo we have always used the 
convention to put the CWS name into the commit message, so the easiest 
way is to just search in the log for the CWS name, that should find all 
commits.


there are also GUI tools that make this kind of thing more convenient; 
i've only used "hgview" so far, it's a bit slow on our big repo and eats 
lots of RAM but it is very useful.

http://www.logilab.org/project/hgview


Action Item : I'm volunteer to make a summary and add the information on
the Apache OpenOffice.org wiki.


Thanks in advance for any help !
Eric

Re: How to rebuild types.rdb ?

[Michael Stahl]

On 18.08.2011 13:52, eric b wrote:

Hi Stephan,

Le 18 août 11 à 09:51, Stephan Bergmann a écrit :



incl. combining the data files to a few big ones, was done in CWS
sb111, see
.




Yes thanks, I read, it, but I can't check for sb111 cws ? hg seems to be
down, or at least not accessible. Do you have a diff available ?


well it was integrated a long time ago (for 3.3 release IIRC), so the 
CWS has been deleted from the HG server.


you'll have to dig into the main DEV300/OOO340 HG history, search the 
log for the CWS name.


regards,
 michael

Re: [Repo][Proposal] OOO340 SVN Dump file import

[Michael Stahl]

On 18.08.2011 10:31, Mathias Bauer wrote:

Hi Michael,

On 17.08.2011 23:15, Michael Stahl wrote:



- some EOL changes in a bunch of files that are probably either harmless
or an improvement


We should decide how to deal with it, as it might make merging from cws
harder. As my favorite approach for bringing over the cws still is to
create patches (either one per cws or one for every change set in the
cws), we could create a diff from the svn repo, apply it to the hg
OOO340m1 repo and create the patches against this version.


that's a good point.

but doesn't patch have an option to ignore whitespace differences?

git-apply seems to have various options including --ignore-whitespace.


- also missing: Repository.mk from the l10n toplevel
don't actually know if we need that; probably not until the l10n
module is converted to gbuild, and in any case i guess it could live
inside the l10n module directory as well.


Whereever it is, it's enough that we have brought it over.


well we haven't, but that's not a big problem given that the entire 
actual content is this line:


$(eval $(call gb_Helper_register_repository,LOCDIR))


Regards,
Mathias

Re: openoffice.org domains transferred to ASF

[Michael Stahl]

On 18.08.2011 03:01, Kazunari Hirano wrote:

Hi Shane,

Do you have a full list which has http://ja.openoffice.org ?
:)
I would like to see the full list of openoffice.org domains transferred to ASF.


presumably that is covered by http://openoffice.org, as it is a sub-domain?


Thanks,
khirano

On Thu, Aug 18, 2011 at 3:55 AM, Shane Curcuru  wrote:



The list of domains includes:

http://openoffice.org

Re: [Repo][Proposal] OOO340 SVN Dump file import

[Michael Stahl]

On 16.08.2011 20:41, Rob Weir wrote:

During local svn import I received several error messages like this:

"svn: Inconsistent line ending style"

The following files gave this error:

/ooo/trunk/core/dictionaries/de_DE/README_hyph_de_DE.txt
/ooo/trunk/core/dictionaries/de_CH/README_hyph_de_CH.txt
/ooo/trunk/core/dictionaries/de_AT/README_hyph_de_AT.txt
/ooo/trunk/core/gettext/gettext-0.18.1.1.patch
/ooo/trunk/core/apache-commons/patches/codec.patch
/ooo/trunk/core/libcroco/libcroco-0.6.2.patch
/ooo/trunk/core/graphite/graphite-2.3.1.patch

> /ooo/trunk/core/filter/source/xslt/odf2xhtml/export/common/body.xsl
> 
/ooo/trunk/core/filter/source/xslt/odf2xhtml/export/common/styles/style_mapping_css.xsl

> /ooo/trunk/core/solenv/bin/cwstouched.pl
> /ooo/trunk/core/readlicense_oo/html/THIRDPARTYLICENSEREADME.html
> /ooo/trunk/core/writerfilter/source/doctok/escher.html

guess these just need proper consistent EOL.

> /ooo/trunk/core/testautomation/writer/optional/input/import/mactext.txt

this one is called "mactext", maybe it wants mac EOL.
there is a "dostext.txt" "wintext.txt" "unixtext.txt" in the same dir.


/ooo/trunk/core/hwpfilter/source/hwpeq.cpp


this one has comments with Korean characters in some annoying encoding.
perhaps we should just remove the offending comments for now.


/ooo/trunk/core/writerfilter/source/odiapi/qname/resource/office2003/WordprocessingML
Schemas/xsdlib.xsd
/ooo/trunk/core/writerfilter/source/odiapi/qname/resource/office2003/WordprocessingML
Schemas/wordnetaux.xsd


seem to be UTF-16 LE encoded


Whereas previously I tried to fix these files with dos2unix, this time
I simply omitted them from the import.   The automated "one size fits
all" approach did not seem right since some of these files, e.g., the
mactext.txt, appear to be intentionally using weird EOL conventions.

We'll need to resolve these cases individually and add them to the new
repository, eventually.  In some cases we might decide to treat them
as binary files, in other cases we could dos2unix them, in other cases
we'll need to convert the character encoding from UTF-16 to UTF-8.
But we can figure that out later.

You can download the new dump file from:  www.robweir.com/ooo-dump-new.gz

md5sum of the unzipped ooo-dump file is:   a6651e98b1a92f5158a08921e85a7a3a

-Rob


had a look at it:

- unsurprisingly the files you listed are missing

- some EOL changes in a bunch of files that are probably either harmless 
or an improvement


- similar number of executable files
  (why the heck are there 8425 of these???)

- also missing: Repository.mk from the l10n toplevel
  don't actually know if we need that; probably not until the l10n 
module is converted to gbuild, and in any case i guess it could live 
inside the l10n module directory as well.


regards,
 michael

Re: [Repo][Proposal] OOO340 SVN Dump file import

[Michael Stahl]

On 15.08.2011 18:46, Rob Weir wrote:

We've been discussing for two months now how to get Hg over to SVN.
There have been several suggestions for how the CWS's and complete
revision history could be migrated over, but little progress has been
made.  Either the proposals didn't work, or no volunteers stepped
forward to implement them.

The alternative proposal was to just check in the tip of the trunk,
without history, and then migrate Hg to Apache-Extras.org, where Hg is
supported.  I've made some progress on this proposal.


very good!


Here's what I did.  I'd like some review, to make sure I didn't screw
anything up. I am neither an Hg nor a SVN expert.  But I do have a big
harddrive.

I used Subversion command-line client, version
1.6.17-SlikSvn-tag-1.6.17@1130896-WIN32.

I first brought down OOo, both the trunk and the language stuff, into
separate directories:

hg clone http://hg.services.openoffice.org/OOO340
hg clone http://hg.services.openoffice.org/master_l10n/OOO340/

I then moved these into a common directory structure, as Ingrid had
earlier suggested:

ooo/trunk/core --- all the OOO340 stuff
ooo/trunk/l10n -- all the language stuff

I removed the .Hg directories before proceeding, so I had a clean local copy.

I then created a local SVN repository, enabled auto-props to get the
proper EOL treatment and imported the project:

svn import c:\merged file:///c:/svn-repo/ -m "initial import"


a potential issue when doing the import on windows is that the execute 
bit of the files may get lost (i think windows filesystems don't support 
that natively).


this could perhaps work by using Cygwin tools (Hg and SVN), because 
Cygwin has to emulate it somehow anyway.


or of course it could be fixed later, there shouldn't be many files that 
need it...


regards,
 michael

Re: [Repo][Proposal] OOO340 SVN Dump file import

[Michael Stahl]

On 15.08.2011 23:27, Mathias Bauer wrote:

On 15.08.2011 22:53, Rob Weir wrote:

The quota is 4GB per project.  I'm not sure what the overhead from Hg
is, but the file system size, uncompressed, is around 1.8 GB.  And
that is just the tip of the trunk.


hg stores compressed and according to latest estimations we should be
able to keep the repo under 4 GB if we pull all cws into one repo.


OOO340 HG repo with all 102 CWSes takes 2.8G
OOO340l10n HG repo takes 198M


Regards,
Mathias

[legal] ICLA paragraph 7

[Michael Stahl]

hi Apache mentors,

i've got a question as to what extent an ICLA from the copyright holder 
is required for code contributions.


a volunteer who is currently working in GSoC over at LibreOffice (who 
has not signed an Apache ICLA) has given me permission to contribute a 
bunch of makefiles that he wrote, with no licensing restriction.


now the ICLA contains this paragraph:


7. Should You wish to submit work that is not Your original creation,
   You may submit it to the Foundation separately from any
   Contribution, identifying the complete details of its source and of
   any license or other restriction (including, but not limited to,
   related patents, trademarks, and license agreements) of which you
   are personally aware, and conspicuously marking the work as
   "Submitted on behalf of a third-party: [named here]".


so it seems to me that an ICLA from the copyright holder is not an 
absolute requirement to contribute to Apache.


is there any restriction in scope or otherwise for this paragraph?

what exactly are the process requirements?

my assumption is that the Committer must ask the potential contributor 
whether they actually hold the copyright.


i guess "submit it separately" means that it must be its own SVN commit, 
not mixed with anything the Committer wrote him/herself.


is it sufficient to put something like this into the SVN commit message:
"Submitted on behalf of a third party: [author name]; no licensing 
restrictions"


is it necessary to ask on the mailing list in every instance?

in this case we are talking about ~30 new files, totalling ~2000 lines
(of which ~1000 are the boilerplate licensing headers...).

regards,
 michael

Re: [Repo] SVN ETA? (was Re: Request for comments: Community Wiki Services web page.)

[Michael Stahl]

On 10.08.2011 20:10, Mathias Bauer wrote:

On 10.08.2011 19:13, Dennis E. Hamilton wrote:



[Nosing around OpenOffice.org I could find no source repositories,
although release tarballs are stated to be available.  I probably
don't know where to look.]


look here:
http://hg.services.openoffice.org/


(I see that LibreOffice has gotten down to one, but that doesn't help
here and I'm not sure what that means in any case.)


I think that you are confusing things here. If you are talking about the
"one git" effort from LibreOffice: for historical or other reaons
LibreOffice always had more than one repository for their code base
(IIRC even more than five), while OOo always only had one until we


in my LO checkout (from before migration) i've got 18 repositories...

there seems to be a script in the top-level that can run git commands 
across all repositories (guess otherwise this kind of setup would be 
completely unusable).



separated the l10n stuff. As having more than one repository is a major
PITA for developers if you need them all for even the smalles build,
they decided to go back to one repository.


there still seem to be 5 repos left (but 3 of them are said to be 
optional: binfilter, dictionaries and translations).


but in any case, LO uses a different model than what OOo used:
- at OOo, we used to have one repo per open feature branch (CWS);
  only very recently have we actually split up the master repo by module
- at LO, all feature branches live in the same repo,
  but they have always split up their code modules across several repos


As we want to be able to work on each of the cws later, we must be able
to identify each "tip" change set of all cws in this repo. This can be
done by keeping each cws in a separate branch or by bookmarking its tip
change set. The latter is easier to achieve by scripting, the former
probably would make it easier to work with the cws later. IIRC ease of
scripting won.


the problem with HG named branches is that they are part of the commit 
metadata, so it's not possible to retroactively introduce them (without 
some effort), while bookmarks are trivial to add.


otherwise, good summary :)


Regards,
Mathias


regards,
 michael

Re: binfilter (was RE: OOO340 to svn)

[Michael Stahl]

On 06.08.2011 19:45, Dennis E. Hamilton wrote:

With regard to consumption versus production, I agree that it is easy
to stop supporting production when no native consumers are likely to
be available any longer and the OpenOffice.org document model evolves
to support expanded functionality of further ODF specifications.


the export filters in binfilter were to be disabled for OOo 3.4 anyway, 
which should already be the case in OOo 3.4 beta.



So if we propose to retire binfilters, we need some way to make it
clear that is happening and what the workarounds are for someone who
finds themselves in need.  And we definitely need to keep it in a
form where someone could revive it at a later time, even if only part
of some sort of document-forensics and -recovery/conversion effort
rather than integrated into future releases.


yes, needs to be added to the release notes.
it will of course be retrievable as part of the first AOOo source 
release, and from SVN.



This is not the last time we will need to deal with this (and the
same fate could eventually befall the native format currently
supported by OpenOffice.org.)


you mean OpenOffice.org XML format?
it's implemented in the "xof" library as a rather simple wrapper around 
the ODF import/export filter, mostly mangling namespaces and tweaking 
some attributes, and shouldn't cause much maintenance effort.



Also, if there are available specifications, whatever their quality,
we probably need to see to their preservation as well.


for the binary SO formats it wouldn't surprise me if the specification 
were the source code (but that was far before my time, so i wouldn't 
know if a real spec exists...).

all the other old formats are foreign anyway.


- Dennis


another reason why i'd favor removing binfilter ASAP is that i suspect 
most of these old filters were written in a less hostile time, so who 
knows what security issues the code may have...

good thing binfilter is not installed by default nowadays.

regards,
 michael

--
"It's very hard to review carefully this kind of boilerplate code.
 Because it's really, really dull.  You basically can't pay people
 enough to carefully review dull code.  We've tried.  It does not work.
 There's some kind of very strong mental habit that causes people to
 just kind of gloss over the repeated bits.  [...]  So avoiding
 boilerplate is key, and ML is very good at that." -- Yaron Minsky

Re: An example of what's wrong up with the wiki

[Michael Stahl]

On 07.08.2011 18:30, Rob Weir wrote:

As mentioned before I'm concerned with the concentration of power on
the wiki, with a few moderators/admins having arbitrary power over
content, even though they have not signed the iCLA, are not committers
and have not been appointed by the PPMC.  So there is arbitrary
authority, with no accountability.  Having a system like this
abdicates the PPMC's responsibility for providing oversight to our
Apache-hosted project websites.

I posted a new FAQ on the wiki today.  This was to demonstrate that
anyone could post anything on the wiki, under any license.

The post was quickly taken down and my account was permanently
blocked.  This was done by someone who is not a PPMC member. In fact
this was a person who recently announced that he was leaving the
project because they had no time to participate.  But evidently there
is no process for removing someone's super-user permissions once they
claim to have left the project.   There was no discussion on the
ooo-dev or ooo-private about the content removal.  Nor was there any
discussion of the account ban.  It was just done.


i can't figure out how to look at what exactly you added to the wiki, 
but if you really added a demand of payment in livestock to the page 
then i consider such handling of obvious attempts at vandalism entirely 
appropriate, and i am happy that we have somebody who looks after these 
things.



This is not how Commit Then Review works at Apache.   This proves my
point that we need to have all wiki users with permissions over other
users to be Committers.  Only committers should have the ability to
revert content made by other committers.  And this should only be done
with discussion.


in general i'd agree that being a Committer is an advantage for 
administrative duties, but of course it depends on finding enough 
Committers with sufficient time available to react to Wiki vandalism and 
spam in a timely manner; in the current situation i'm happy that Clayton 
is still watching it a bit, and he certainly has the experience to do a 
good job.


oh, and consider that currently the Wiki is still on Oracle/OOo 
infrastructure, not on Apache, so i guess if there really is a Committer 
requirement it does not currently apply.



-Rob


regards,
 michael

Re: OOO340 to svn

[Michael Stahl]

On 26.07.2011 13:51, florent andré wrote:

Hi there,

I actually run a script [1] on my local laptop and online svn serveur
that import the OOO340 hg to an svn trunk folder.

For now, it's work pretty well - get all history from OO340 - with good
commit log e.g. :
---
Added:
ooo/trunk/trunk/xmloff/source/text/XMLTextColumnsContext.cxx
Modified:
ooo/trunk/trunk/xmloff/source/text/XMLTextPropertySetContext.cxx
ooo/trunk/trunk/xmloff/source/text/makefile.mk
Log:
changeset: 41:196d10f76091
user: mib
date: Thu Sep 21 09:48:30 2000 +
text column import


But, as it simulate all svn commit, it's a little bit long...
Actually on 45/276930 revision.


well, the first 263206 revisions are the easy ones, because they're 
linear :)


btw, what script are you using?

what will it do with merge revisions?


If the process goes well to the end, what could be the next step ?
Restart this script on the apache svn or extract some kind of svn dump
from my svn-serveur and import it ?


presumably it ought to be possible and easiest to import an SVN dump, 
but i'm no SVN expert...


regards,
 michael

Re: Legality of ooo-archive apache git repository

[Michael Stahl]

On 26.07.2011 04:50, Sam Ruby wrote:

On Mon, Jul 25, 2011 at 4:58 PM, florent andré
  wrote:

Question around this idea is (Quoting Rob Weir) :
" it would be from the IP perspective.  This is more than
getting an updated SGA from Oracle. It is also about incompatible
licensed code.  We can only carry that in our SVN repository
temporarily, until we graduate.  So having it exist long-term in a
read-only git archive is something we'd want to understand better."

Your insights will be really helpful here as it's more than a month ago from
incubation now, an the option here seems the best compromise we had for now.


 From a legal perspective, there is no difference between svn, git, or
even hg for that matter.  This is for the PPMC to decide, in
conjunction with infrastructure.


good to know.


What purpose would there be to retaining a "long-term...archive" of
"incompatible licensed code" on Apache Infrastructure?  I fully
understand the short term need during incubation, but what is the
intended purpose of this code post graduation?


as i've already explained in the "single repository status" thread, 
nobody knows how to convert the full branchy history as it currently 
exists in HG to SVN; any conversion to SVN that i can imagine (with 
reasonable effort) would lose some history data.


the value of such a read-only HG/git repo would be that future 
maintainers of the OOo code base have the full history available.


regards,
 michael

Re: ICU

[Michael Stahl]

On 20.07.2011 13:41, Eike Rathke wrote:

The most problematic is the RPATH for URE patch, but I have no idea
anyway how to proceed with libstdc++.so.6 and libgcc_s.so.1 that so far
were distributed with the URE and are LGPL. If we don't, then the patch
would be moot.


that is an interesting point: we currently ship binaries of C++ runtime 
libraries in the installation sets.
i know that we do this for Linux and Windows, don't know about other 
platforms; presumably relicensing GCC or MSVC runtime under Apache 
license is not an option.


i guess we can probably drop the GCC libraries nowadays, because 
libstdc++ doesn't change its ABI as much as it used to, so everybody 
should have a good enough one on their system.


i wonder what would happen if we drop MSVC runtime?

Re: single repository status

[Michael Stahl]

On 20.07.2011 12:05, Eike Rathke wrote:

Hi Michael,

On Tuesday, 2011-07-19 23:26:48 +0200, Michael Stahl wrote:


unfortunately it seems none of the tools that convert from HG or
git to SVN can create SVN branches with SVN mergeinfo (necessary in
order to be able to merge the branches back into the trunk).

there are some tools to convert from git that can create SVN
branches, but they leave out the SVN mergeinfo; apparently the
intent is to maintain a read-only mirror...


I didn't dug deeper into this, but conversion from hg to git should
be pretty straight forward and then there's git-svn, would that be
viable to import branches as well?


well, i've already got a git repo with 104 open CWS branches on my
laptop for 2 weeks now...
(which, by the way, i've already made good use of, because git diff has
a very useful option --name-status, making discovery of added files on
CWS branches much easier)

but it seems that git-svn isn't going to help for the branching/merging:

http://www.kernel.org/pub/software/scm/git/docs/git-svn.html


MERGE TRACKING

While git svn can track copy history (including branches and tags)
for repositories adopting a standard layout, it cannot yet represent
merge history that happened inside git back upstream to SVN users.
Therefore it is advised that users keep history as linear as
possible inside git to ease compatibility with SVN (see the CAVEATS
section below).


also, funnily, it has a --mergeinfo parameter which allows the caller to
specify SVN mergeinfo, but it can't compute it itself...

what i guess we could do is to use git-svn to merge and/or rebase the
open CWSes and push the result (as a linear history) to SVN.

there is also a HgSubversion extension that has similar functionality
and restrictions:

http://mercurial.selenic.com/wiki/HgSubversion


The important point to note is that hgsubversion cannot push merge
changesets to a svn repository.


i think the problem is that Hg/git/otherDSCMs and SVN have fundamentally 
different data models for representing branching/merging; the fact that 
so far nobody has come up with a conversion tool that handles merges 
well suggests to me that it's not an easy problem to solve.


regards,
 michael

Re: Debian build

[Michael Stahl]

On 20.07.2011 12:16, Eike Rathke wrote:

Hi imacat,

On Tuesday, 2011-07-19 12:17:44 +0800, imacat wrote:


 As far as I know, the current OpenOffice.org HG source does not
build on Debian.


There was at least one breakage in avmedia/source/gstreamer, but with
the copyleft patch to configure that isn't built anymore and the build
didn't break anywhere.


about gstreamer breakage, see patch attached to my mail:

http://mail-archives.apache.org/mod_mbox/incubator-ooo-dev/201106.mbox/%3Citn50l$igl$1...@dough.gmane.org%3E

regards,
 michael

Re: single repository status

[Michael Stahl]

On 14.07.2011 18:03, Michael Stahl wrote:

On 09.07.2011 07:57, Greg Stein wrote:

Once the tags are properly marked, then we can start testing the
conversion to Subversion. Please note, however: the hg conversion
script does *not* process tags. We will have to write that. We will
also have to somehow manage construction of branches. We may also have
to update the conversion tool to properly handle the "merge"
changesets that Hg records.


after looking at the HG convert svn_sink a little, this looks rather
difficult to me.

well, tags should be easy.

but how to reconstruct the branching is kind of unclear to me.
the first ~260k changesets are linear and were initially taken from SVN,
so that shouldn't be a problem.
but then there are lots of HG merge changesets.


unfortunately it seems none of the tools that convert from HG or git to 
SVN can create SVN branches with SVN mergeinfo (necessary in order to be 
able to merge the branches back into the trunk).


there are some tools to convert from git that can create SVN branches, 
but they leave out the SVN mergeinfo; apparently the intent is to 
maintain a read-only mirror...



in the HG repo there is sort of a "master" history that is basically a
sequence of CWS integration merge changesets, with the occasional
masterfix thrown in.
but this is not explicit: these are all just merges with 2 parents, and
it's not guaranteed which of these 2 is the CWS and which the master.
basically the requirement is to convert one of the thousands of paths
through this DAG from the common ancestor revision ~260k to revision
c904c1944462 (OOO340 head) into a SVN trunk.


to be more specific, the last revision from OOo SVN was the tag 
"last_svn_milestone" (263206  d0058b5891eb)
(which is not actually a common ancestor, as some CWSes are based on 
older milestones)


the following merge commits are those on the DEV300 master/"trunk" where 
i've noticed the "follow the first parent" heuristic would fail, and the 
second parent (after the arrow) should be taken instead.


90552a19cdc4 -> dae1ffc5c15d
9572400cd241 -> ce1b12199f72
c33f611c4373 -> 5d0c069f2570
13b3d2dae916 -> 62bf02dff30b
37dc1e423a1e -> 664c5f3a9291


basically we have these options for converting to SVN:

1. convert full history
   requires writing tool to create SVN branches and mergeinfo

2. convert trunk only, using follow-first-parent heuristic
   with hacks where we want to follow second parent instead

3. no history in SVN, just check in OOO340 tip

option 1. seems to be too much effort to me, and would have to be 
implemented by a real SVN wizard.


option 2. requires some effort, but should be doable; we still lose all 
CWS internal history though (e.g. CWS undoapi becomes a single 57,788 
line changeset against 562 files).


after thinking about it for a while, a trunk-only history in SVN doesn't 
seem to be all that useful to me (you need to go over the network to 
access something incomplete...).


far more useful would be to have a read-only HG/git repository available 
that contains the _full_ history and all open CWS branches, which can be 
cloned and examined off-line.


opinions?

regards,
 michael

Re: *Solaris support

[Michael Stahl]

On 15.07.2011 05:20, Dennis E. Hamilton wrote:

It seems like the first thing for you or someone working with you to
do is find a way to build a release on Solaris from the source code.
Since 3.3.0 was built for both Solaris x86 and Sparc, you should be
able to determine what it takes for that distribution (with
integration of all of the localizations).

The distributions and the source code is available
at.
Look at the src_* files at the end.  Notice the significant size of
the source code.

Rebuilding an existing stable build is the easiest way to confirm
that you have it working.


actually usually it's a better idea to build the current development
version; especially since in contrast to OOo 3.3 we now have 2 build
systems (because we're in the middle of the migration), you really want
to know that _both_ work for your platform.


You'll need to roam around the Developers information, including
information about the build
environment:.  (I can't
vouch for how current any of this is.)


don't trust anything on tools.openoffice.org; it's generally out of
date; the Wiki tends to have more current stuff, look at the Building
Guide (see Mathias' mail).

lastly, let me express my puzzlement at the surprising popularity of our 
Solaris port :)


if there are really people who want to maintain that, then i'd suggest 
looking into building it with GCC instead of SunStudio, which is not 
currently possible, but would probably ease the maintenance burden in 
the long run.


regards,
 michael

Re: single repository status

[Michael Stahl]

On 09.07.2011 07:57, Greg Stein wrote:

Hi all,

I borrowed some space on some ASF equipment and used the
'fetch-all-cws.sh' script to pull down all of the CWS repositories (in
addition to the OOO340 and master_l10n/OOO340 repositories). This
consumed 77 Gb of disk space.

The fetch-all-cws.sh script has been updated with all my fixes to make
this happen, and the cws-list.txt file has been updated to reflect all
CWSs that have actual content beyond OOO340.

I have updated single-hg.sh to do a basic combination of the
repositories. This produces a 2.7 Gb repository.

However! The single-hg script does not apply any tags/bookmarks for
the heads introduced by the pulls from the CWS repositories.
Originally, I thought to apply bookmarks, but ... meh. We can just
apply tags. It isn't like we are going to push to the repository and
need the bookmark to float with the changes. So the next step is to
update single-hg to apply the appropriate tags. At that point, I will
publish a bundle so that most people can skip all the above steps and
start playing with the repository that will feed into the next step
(convert to svn).

Once the tags are properly marked, then we can start testing the
conversion to Subversion. Please note, however: the hg conversion
script does *not* process tags. We will have to write that. We will
also have to somehow manage construction of branches. We may also have
to update the conversion tool to properly handle the "merge"
changesets that Hg records.


after looking at the HG convert svn_sink a little, this looks rather 
difficult to me.


well, tags should be easy.

but how to reconstruct the branching is kind of unclear to me.
the first ~260k changesets are linear and were initially taken from SVN, 
so that shouldn't be a problem.

but then there are lots of HG merge changesets.

in the HG repo there is sort of a "master" history that is basically a 
sequence of CWS integration merge changesets, with the occasional 
masterfix thrown in.
but this is not explicit: these are all just merges with 2 parents, and 
it's not guaranteed which of these 2 is the CWS and which the master.
basically the requirement is to convert one of the thousands of paths 
through this DAG from the common ancestor revision ~260k to revision 
c904c1944462 (OOO340 head) into a SVN trunk.



In the single repository that I constructed, there are 102 heads. I
believe these will become branches.


well, they should...
these don't have a common ancestor from the "trunk" history; generally 
they contain several merges from the master into the CWS as well.

it was also quite common practice to merge one CWS into another.

i don't know SVN implementation of branching/merging that well, and i 
have no idea how this history should look like in SVN, or whether it's 
even expressible.


one thing we could do in any case is just not convert the CWSes; put up 
a read-only HG or git repo with all CWSes somewhere, then use that to 
rebase the CWS onto OOO340, then apply a patch to a SVN branch based on 
OOO340, then merge with SVN trunk.



We will need a script to take the single repository as input, and run
the conversion process. I think there will multiple inputs to that
process, so there will be additional input files to coordinate and
drive the conversion. All of this should be placed into the tools/dev/
directory. Help is wanted!

Cheers,
-g


--
'I have had at least two students tell me (in the words of one) that
 "you seduced me, you made me think computing and programming was
 sooo elegant and sooo beautiful, and now I am stuck with C++."'
 -- Matthias Felleisen

Re: fetch-all-cws.sh

[Michael Stahl]

On 07.07.2011 12:00, Michael Stahl wrote:

On 06.07.2011 18:35, Herbert Duerr wrote:



i've started converting yesterday evening, and maybe it'll be finished
today (on my 3 year old laptop...)


conversion finished after ~75hours; it seems to have slowed down over 
time, especially the last 20k commits that include merges changing 40k 
files turned from CPU bound to IO bound, and took a long time...


seems to have worked, result is a 5.7GB git repo with 104 branches.


I'd clarify step one to "convert OOO340 repo to a bare git repo via
hg-fast-export.sh". After all these steps please don't forget git
pack-refs and git repack (e.g. with "-a -d -f --window=200
--depth=1000") to get a nice and tight repository.


git pack-refs didn't seem to do anything.

git repack with your options ran for 6 hours and shrank the repo to ... 
5.7GB.


any idea what i'm doing wrong?

Re: Try to build OOo , but meet error......

[Michael Stahl]

On 09.07.2011 06:19, L'oiseau de mer wrote:

if without setting CC and CXX, configure will use gcc and appear ld error.
if CC=cc and CXX=CC , configure will appear :
checking for cc... /opt/solstudio12.2/bin//cc
checking the SunStudio C/C++ compiler version... configure: error:
found version "5.11", use version 5.5, 5.7, 5.8 or 5.9 of the
SunStudio C/C++ compiler

and i also try to use sunstudio11:but it has other error


AFAIK we used only SunStudio 12.0 release to build OOo; you should have 
the least problems with this version.
SunStudio 12 update releases had some kind of problem with boost or 
something.



ube: error: Assert has been violated at
'/set/venus/builds.intel-S2/nightly.Thu/intel-S2/lang/ube/graphs/src/scregion.c
305'.
cc: ube failed for ../../../js/src/jsinterp.c


this looks like a compiler bug...


and then i enter vcl directory,run gmake -r:



CC: Warning: Option -xMMD passed to ld, if ld is invoked, ignored otherwise
CC: Warning: Option -xMF passed to ld, if ld is invoked, ignored otherwise


aha, interesting: this version does not understand the options we use in 
gbuild to write dependency files.


Google finds this, which says that these are only supported since 
SunStudio 12:

http://192.9.162.65/sunstudio/support/Ccompare.html

this means that older versions of SunStudio won't work currently for OOo.

Re: fetch-all-cws.sh (was: Building a single Hg repository)

[Michael Stahl]

On 06.07.2011 19:12, Greg Stein wrote:

On Wed, Jul 6, 2011 at 07:50, Michael Stahl  wrote:

On 05.07.2011 11:16, Herbert Duerr wrote:



If the goal is to just merge the outstanding CWSs into trunk I'd suggest
to stay with hg, merge all good CWSs into trunk and start the apache-ooo
SVN repository from that trunk.

If the goal is to preserve the trunk and CWSs of the old-OOo project
then the idea to provide it as a read-only git repository is great,


We only have one canonical repository at Apache, and that is
Subversion. We should not be planning to create a Git repository...
the read-only Git "repositories" are just mirrors of portions of the
Subversion repository.


i thought you and/or Mathias were working on the SVN conversion already.

who knows, perhaps there will be trouble converting from HG to SVN, and 
going via git as an intermediate step is easier?

it's good to have options :)

regards,
 michael

--
"PL/I and Ada started out with all the bloat, were very daunting
 languages, and got bad reputations (deservedly).  But C++ has shown
 that if you slowly bloat up a language over a period of years people
 don't seem to mind as much." -- James Hague, 1992

Re: fetch-all-cws.sh

[Michael Stahl]

On 06.07.2011 18:35, Herbert Duerr wrote:

 > there is another tool, a HG extension called hg-git, which can
 > convert HG bookmarks to git branches.
 > http://hg-git.github.com/

Great find! I was already brushing up my python and mercurial internals
skills to extend hg-fast-export's export_commit() for our one big
hg-repo with one hg-branch and many hg-bookmarks. I'm glad that cup passed.

 > so my current plan is this:
 > 1. convert OOO340 repo to git via hg-fast-export.sh
 > 2. pull all CWSes into OOO340 repo and create bookmarks
 > 3. use hg-git to push all of them into the converted git repo

Sounds good!


unfortunately it won't work :(

problem is that hg-fast-export.sh and hg-git don't quite agree what a 
converted git repo should look like.
i've actually tried it out with a trivial repo and 2 branches and 
surprisingly it actually worked, but then i tried it on a real repo (the 
hg-git one), just take some arbitrary changeset and convert up to that 
with hg-fast-export.sh, then hg-git push of the rest fails...


next thing i tried is to convert the whole thing via hg-git push, but 
unfortunately they weren't lying when they used the word "slow".
after a couple of hours it had converted one percent of the changesets, 
and the progress predicted an ETA of >8 days.


so then i've taken a deeper look at the hg-fast-export code, and it 
seems surprisingly easy to hack it to do something with HG bookmarks.


basically a HG bookmark points at a single revision, and is thus quite 
similar to a git "ref".
the hg-fast-export writes a header for every changeset, with a branch 
name: "commit refs/heads/$branchname"


so i'm detecting all the HG heads that are marked by bookmarks, and just 
use the bookmark name as the branch name.

also, a bookmark for the head that corresponds to OOO340 is necessary.

then invoke it like this:

mkdir git
cd git
git init
hg-fast-export.sh -r ../hg -M dummy

the "-M dummy" sets the default branch, so all changesets that are _not_ 
heads end up on the "dummy" branch, and for every head/bookmark a branch 
pointing to that head is created.

the "dummy" branch/ref can be deleted after conversion.

i don't understand git very well, but i hope this should work :)

the tool already errors out if there is more than one head without a 
branch/bookmark.


the attached patch just adds 3 lines of actual code plus some parameter 
shuffling.
(a case that may not be handled properly is if there is a HG branch and 
a HG bookmark with the same name, but we don't have HG branches at all...)


i've started converting yesterday evening, and maybe it'll be finished 
today (on my 3 year old laptop...)



I'd clarify step one to "convert OOO340 repo to a bare git repo via
hg-fast-export.sh". After all these steps please don't forget git
pack-refs and git repack (e.g. with "-a -d -f --window=200
--depth=1000") to get a nice and tight repository.

Herbert
diff --git a/hg-fast-export.py b/hg-fast-export.py
index 519b556..6a66a24 100755
--- a/hg-fast-export.py
+++ b/hg-fast-export.py
@@ -149,7 +149,7 @@ def sanitize_name(name,what="branch"):
 sys.stderr.write('Warning: sanitized %s [%s] to [%s]\n' % (what,name,n))
   return n
 
-def export_commit(ui,repo,revision,old_marks,max,count,authors,sob,brmap):
+def 
export_commit(ui,repo,revision,old_marks,max,count,bookmarks,authors,sob,brmap):
   def get_branchname(name):
 if brmap.has_key(name):
   return brmap[name]
@@ -157,7 +157,7 @@ def 
export_commit(ui,repo,revision,old_marks,max,count,authors,sob,brmap):
 brmap[name]=n
 return n
 
-  
(revnode,_,user,(time,timezone),files,desc,branch,_)=get_changeset(ui,repo,revision,authors)
+  
(revnode,_,user,(time,timezone),files,desc,branch,_)=get_changeset(ui,repo,revision,bookmarks,authors)
 
   branch=get_branchname(branch)
 
@@ -257,7 +257,7 @@ def load_authors(filename):
   sys.stderr.write('Loaded %d authors\n' % l)
   return cache
 
-def verify_heads(ui,repo,cache,force):
+def verify_heads(ui,repo,cache,bookmarks,force):
   branches=repo.branchtags()
   l=[(-repo.changelog.rev(n), n, t) for t, n in branches.items()]
   l.sort()
@@ -275,7 +275,7 @@ def verify_heads(ui,repo,cache,force):
   # verify that branch has exactly one head
   t={}
   for h in repo.heads():
-(_,_,_,_,_,_,branch,_)=get_changeset(ui,repo,h)
+(_,_,_,_,_,_,branch,_)=get_changeset(ui,repo,h,bookmarks)
 if t.get(branch,False):
   sys.stderr.write('Error: repository has at least one unnamed head: hg 
r%s\n' %
   repo.changelog.rev(h))
@@ -294,7 +294,9 @@ def 
hg2git(repourl,m,marksfile,mappingfile,headsfile,tipfile,authors={},sob=Fals
 
   ui,repo=setup_repo(repourl)
 
-  if not verify_heads(ui,repo,heads_cache,force):
+  bookmarks = dict([(repo._bookmarks[bm], bm) for bm in repo._bookmarks])
+
+  if not verify_heads(ui,repo,heads_cache,bookmarks,force):
 return 1
 
   try:
@@ -308,14 +310,14 @@ def 
hg2git(repourl,m,marksfile,mappingfile,headsfile,tipfile,authors={},sob=Fals
 max=tip
 

Re: fetch-all-cws.sh (was: Building a single Hg repository)

[Michael Stahl]

On 05.07.2011 11:16, Herbert Duerr wrote:

On 05.07.2011, Rob Weir wrote:

Is the Hg ==> Git conversion easier/cleaner than the conversion to SVN?


Yes. Having the CWSs in SVN would only increase the size of the
repository considerably without providing benefits after they get
merged. Speaking of merges in SVN we regularly had the problem that a
file was renamed in one CWS and changed in another CWS and the result
was that the change got lost. HG or GIT handle this scenario much more
gracefully, so there was less risk to do big merges.


indeed, which led to effectively forbidding moving files in SVN...
i hope SVN has learned to signal a merge conflict for this nowadays?


I notice that Apache Infrastructure does support *read-only* Git
repositories:

http://git.apache.org/

Would it be any simpler to move the enter Oracle-hosted project,
including all CWS's to a read-only Git, and then create a dump of just
the integrated trunk (with history) for the project's SVN repository?
Then, we'll have ongoing access to the CWS's in Git until such point
as they are ready to be integrated. In other words, treat the Git
version as a read-only archive.


If the goal is to just merge the outstanding CWSs into trunk I'd suggest
to stay with hg, merge all good CWSs into trunk and start the apache-ooo
SVN repository from that trunk.

If the goal is to preserve the trunk and CWSs of the old-OOo project
then the idea to provide it as a read-only git repository is great,
especially since it would work in the current infrastructure. With
http://repo.or.cz/w/fast-export.git the conversion could be easy.
Unfortunately that tool hasn't been extended to handle hg-bookmarks yet
but it handles hg-branches just fine. So if someone more experienced
with HG can rewrite the latest fetch-all-cws script posted here from
hg-bookmarks to its hg-branches equivalent we would be only one step
away from such a "status-quo" repository. I guess the resulting bare
repo would only consume about 1.5GB for everything.


this is a very interesting idea, so i've tried to figure out how to do 
this...


found this article most helpful:
http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/

unfortunately, (in contrast to HG bookmarks) it doesn't seem to be 
possible to retroactively move HG commits onto a HG named branch.
for a HG named branch the branch is part of the commit metadata, so this 
would need modifying the existing commits, and i've not found a tool 
that can do this (the HG convert extension allows for renaming branches, 
but in this case we'd need to move _some_ commits from the default 
branch to a CWS branch, and i can't see how that could be done).


there is another tool, a HG extension called hg-git, which can convert 
HG bookmarks to git branches.

http://hg-git.github.com/

so my current plan is this:
1. convert OOO340 repo to git via hg-fast-export.sh
2. pull all CWSes into OOO340 repo and create bookmarks
3. use hg-git to push all of them into the converted git repo

it would also be possible to use hg-git to convert the whole HG repo 
with bookmarks in one step; don't know which is the better way, and the 
hg-git homepage mentions the word "slow" somewhere, while we have 
"hg-fast-export.sh", so i'll try this route first :)



For a more complete history we could then also add the >1000 CWSs from
the svn period. I found that having the individual instead of the big
merge-hunks was invaluable for understanding the status of some code.
Even with these many CWSs the result will probably stay under 2.0GB.


hmm... could be useful :)

--
"The 'sound' banker, alas! is not one who sees danger and avoids it,
 but one who, when he is ruined, is ruined in a conventional and
 orthodox way along with his fellows so that no one can really
 blame him." -- John Maynard Keynes

Re: Uh oh: OpenOffice.org XML Namespaces and Sun Mediatypes

[Michael Stahl]

On 04.07.2011 22:01, Dennis E. Hamilton wrote:

PS: I hadn't thought of the Java and .Net ways of disambiguating the
names of externally-bindable enties and the canonical structure of
class paths.  Do we have any concern for org.openoffice. ... .mumble
in that context?


the UNO API still uses the classic "com.sun.star." namespace for reasons 
of backward compatibility; changing that would break every extension and 
macro, and require a huge conflict-inducing change to the OOo code...


--
"Our enemies are innovative and resourceful, and so are we. They never
 stop thinking about new ways to harm our country and our people,
 and neither do we." -- George W. Bush

Re: Try to build OOo , but meet error......

[Michael Stahl]

On 04.07.2011 16:17, Eike Rathke wrote:

Hi L'oiseau,

On Friday, 2011-07-01 08:07:38 +0800, L'oiseau de mer wrote:



export CC=/opt/solstudio12.2/bin/cc
export CXX=/opt/solstudio12.2/bin/CC


Try without setting CC and CXX, configure should find them as
/opt/solstudio12.2/bin is in your $PATH, or if that doesn't help try
setting CC=cc and CXX=CC without paths. Some configure checks may rely
on the executable name only, without path.


actually i think i've built successfully with such variables.
(but surprisingly found it necessary to put the sunstudio bin dir on the 
PATH as well...)



[ build LNK ] Library/libdesktop_detectorsi.so
usage: CC [ options ] files.  Use 'CC -flags' for details
/usr/gnu/bin/cp: cannot stat
`/UNIX-LAB/OOO340-c904c1944462/solver/340/unxsoli4.pro/workdir/LinkTarget/Library/libdesktop_detectorsi.so':
No such file or directory
===
Maybe is SunCC's option is different with gcc, i want to find this
Makefile and modify CFLAGS,


the error message doesn't tell much.
(cd vcl && gmake -r)
should give the full command that failed.

regards,
 michael

Re: fetch-all-cws.sh (was: Building a single Hg repository)

[Michael Stahl]

On 04.07.2011 16:21, Mathias Bauer wrote:

On 01.07.2011 22:58, Michael Stahl wrote:


i think i wrote that all CWSes as HG repos take ~100 GB, but actually i
now think i remembered wrong and the number was more like ~150 GB.
(i did this originally in 2 steps, and i remembered only the second step...)
(and if it weren't so late now i'd even dig out my external hd and run
du...)


I used the "branchmirror" Mercurial extension from Björn to fetch all
CWS, based on the OOO340 master repository.

There are 185 cws, on a Linux system with hard links their hg repos
consume ~80 GB. 66 of the cws are empty, 2 of them are obsolete.


i forgot to mention: on Saturday i've actually run "du" myself (which 
took 20 minutes on the USB disk...), and in fact it's 100GB, so my first 
guess was right.


(guess the fact that yours is smaller is caused by me having used DEV300 
and you OOO340, so some CWSes that are empty for you have content for me)



This leaves us 117 cws to investigate.

In case the list of empty or obsolete cws is important, I could post it
here.


what do you mean by "obsolete"?
the "integrated"/"deleted" ones seem to be removed from the server, and 
i've commented out the "cancelled" ones.


the empty ones can be checked via "hg incoming".

take a look at the cws-list.txt in the SVN repo.
if you see something that shouldn't be migrated, you can comment it out...

--
Life is complex. It has real and imaginary components.

Re: fetch-all-cws.sh (was: Building a single Hg repository)

[Michael Stahl]

On 01.07.2011 18:47, Herbert Duerr wrote:

On 01.07.2011 13:42, Greg Stein wrote:

[...] Please look at
tools/dev/fetch-all-cws.sh. Each of these CWS repositories (on Mac OS)
are consuming 600 Mb *minimum*. I've fetched a dozen, and a couple are
over 2 Gb each, and another over 1 Gb. And this is with the clone/pull
technique.


Because of the disk space demands I think an approach with one
repository with one branch per CWS would be better for the initial
import. In hg there are more opportunities for this approach (using
NamedBranched, UnnamedBranches, MultipleHeads, LocalBranches or
Bookmarks) than I as git-fan would care to know. Please see the attached
file where I hacked together a script that imports the CWSs into one
repository with multiple bookmarks.


of course, mirroring all the separate repos is only an intermediate 
step, with the goal that constructing the single repo doesn't need to go 
over the slow net.



I don't have enough space on my laptop to do a complete trial run. I'm
hoping that somebody can figure out how to reduce the disk footprint,
or determine that we just have to suck it up. And it would be nice to
understand what that target size will be, for all 250 CWS
repositories.


As Michael mentioned it's much less than the 250, as only about 15
CWSses (see http://goo.gl/gczAH for details) are marked as fully tested
and but not-yet integrated.
 From these the ones targeted at the stabilization branch (calc67,
calc68, ooo34gsl01, ooo34gsl02, writerfilter10, native373, jl167) are
more important than the ones targeted for trunk (sb140, sb143, hsqldb19,
hr77, ause131, sd2gbuild).

There are a few more very good CWSses which were not yet officially
approved in the old OOo system. E.g. CWS aw080 Armin mentioned. If Armin
can confirm that this CWS is ready we should pull it in too.

Once we have a better picture of what is ready or not cws-list.txt needs
to be updated.


i think the goal is to migrate all open CWSes, because perhaps there's 
still something useful in there, and we don't have time to investigate 
every CWS now.



We have a script. It is time to make it work.


Please see the attached file. I'm afraid to check it in as the related
single-hg.sh is not yet updated accordingly and also because I'm more of
a HG victim than a HG power-user ;-)

Please note that you either have to use HG>=1.8 or enable its bookmark
extension before you run the attached script.


i've not used bookmarks or anything like that either, but it looks like 
it could work, except i think we may need to prevent it from creating 
wrong bookmarks in case no changes are to be pulled (it seems in this 
case, the hg bookmark -r tip would create a bookmark $cws which points 
at the previously pulled cws, instead of doing nothing; "tip" is always 
the head that was pulled last into the repo).


just tried it out, and it took 80 minutes to produce a 2.6 GB repo with 
178 bookmarks.

indeed a lot of bookmarks are duplicated, as described above.

tweaked it a bit, see attachment.

regards,
 michael

--
"Simply, I'd say that porting [Linux] is impossible."
 -- Linus Torvalds (26. 08. 1991)


fetch-all-cws.sh
Description: application/shellscript

Re: fetch-all-cws.sh (was: Building a single Hg repository)

[Michael Stahl]

On 02.07.2011 04:14, Greg Stein wrote:

On Fri, Jul 1, 2011 at 17:18, Greg Stein  wrote:

On Fri, Jul 1, 2011 at 16:58, Michael Stahl  wrote:
...

but actually i think that a lot of these 250 CWSes will not contain a
changeset that is not in the master already; a lot of developers create new
CWS and then (have to) work on something else for some weeks...

so i have adapted the fetch script to skip empty CWSes.


Saw that. Great!


I used that code to figure out which are empty, and then commented
those out from the cws-list.txt file. I think it is best to keep the
code in there, regardless. Somebody may want run it in the future.

When I was working on this, however, I noticed we were not attempting
to fetch the cws_l10n repositories. So I fixed the filter, but
Mercurial said those repositories are not related to DEV300. What is
going on there, and what do we need to fix? Should we be fetching the
cws_l10n/* repositories? And if so... how do we integrate that into
our single repository, and then into our svn repository?


these need to be pulled into the l10n repository, not the main repository:
http://hg.services.openoffice.org/master_l10n/OOO340/

and i'd expect almost all of these to be empty.

the l10n repo contains a single top-level module.

we could integrate these in SVN in 2 ways:
1. like we did in the old times, as a top-level module next to all
   the other ones:
ooo/trunk/{hundreds of modules}
ooo/trunk/l10n

2. under a separate root:
ooo/trunk/{hundreds of modules}
ooo-l10n/trunk/l10n

1. has the advantage that everything can be branched/tagged in one 
operation, while 2. has the advantage that it's easier for developers 
that only build en-US to not waste disk space/build time (the build 
system is already prepared to have it "optional").


(of course there are other ways we could split up the modules, like e.g. 
have a separate Apache URE product upon which Apache OOo can depend, but 
that's not something we should discuss now...)


--
"Inexact sciences like economics advance funeral by funeral."
 -- Paul Samuelson

Re: fetch-all-cws.sh (was: Building a single Hg repository)

[Michael Stahl]

On 01.07.2011 13:42, Greg Stein wrote:

On Wed, Jun 29, 2011 at 05:04, Michael Stahl  wrote:

...
in principle the size of a CWS is on the same order as the master, because
it's just another HG repository.

but HG supports hardlinks between repositories (in newer versions even on
win32), so you can "hg clone" the master on the same filesystem and then
pull in the CWS, and it will be _much_ faster and take _much_ less
additional space


This is the approach that I took. Please look at
tools/dev/fetch-all-cws.sh. Each of these CWS repositories (on Mac OS)
are consuming 600 Mb *minimum*. I've fetched a dozen, and a couple are
over 2 Gb each, and another over 1 Gb. And this is with the clone/pull
technique.


indeed, i get similar numbers.
a clone with hardlinks is 34 MB on my filesystem.
a CWS with a single changeset takes 670MB.
reason is that for every commit, 2 files that store changelogs and 
manifests are modified, and together these are >600 MB in our repo.



I don't have enough space on my laptop to do a complete trial run. I'm
hoping that somebody can figure out how to reduce the disk footprint,
or determine that we just have to suck it up. And it would be nice to
understand what that target size will be, for all 250 CWS
repositories.


i think i wrote that all CWSes as HG repos take ~100 GB, but actually i 
now think i remembered wrong and the number was more like ~150 GB.

(i did this originally in 2 steps, and i remembered only the second step...)
(and if it weren't so late now i'd even dig out my external hd and run 
du...)


of course the filesystem used could make a difference here.

but actually i think that a lot of these 250 CWSes will not contain a 
changeset that is not in the master already; a lot of developers create 
new CWS and then (have to) work on something else for some weeks...


so i have adapted the fetch script to skip empty CWSes.


A possible alternative to pulling N repositories, then combining them
in a second step, is to attempt to bring them all into a single
repository, one at a time. This is a little more scary for me, not
knowing Hg, to understand how restartable and repeatable this process
will be in the face of errors. Either starting from scratch, or (I
believe an important feature) if it needs to be resumed after some
minor failure (eg. network failure).


this would of course take much less space, but then it would be 
necessary to mark the newly pulled head immediately to know which CWS it 
corresponds to.



We have a script. It is time to make it work.

Michael: you say that some CWS repositories are useless. If so, then
please update tools/dev/cws-list.txt to comment-out those CWS's with
some explanation for future readers. No need for us to attempt to
process them if they're bogus.


i have checked the status in EIS, and it seems like the repos for almost 
all integrated/deleted CWSes have already been automatically removed 
from the server.
found a couple that were in a state "cancelled", which i didn't even 
know existed, sounds like we don't need those, so i've commented them out.


of course some CWSes contain stuff that's not useful, but i don't know 
which these are :)


--
"Fools ignore complexity.  Pragmatists suffer it.  Some can avoid it.
 Geniuses remove it." -- Alan J. Perlis

Re: Naming of trunk and feature branches

[Michael Stahl]

On 29.06.2011 15:03, Greg Stein wrote:

Branches can be named whatever we'd like. My own preference would be
to call this: /branches/3.4.x

The "OOO" is awfully redundant, and the last digit ("0") doesn't make
sense since we would be releasing patches from the branch such as
3.4.1. The "3.4.x" naming is used by many products, and it has worked
out very well.


it wouldn't be a surprise to me if the reason for the "OOO340" name 
would be that it has to be exactly 3 letters followed by exactly 3 
digits, or otherwise some tooling breaks.


for example, the 2.4.x CVS release branch was called OOH680 (what the 
heck does that mean?)


indeed, why not "3.4.x"

--
Q: How many Prolog programmers to change a lightbulb?
A: no.