Pavel's diary

I spent several hours during the weekend and also today on CWS tools. I have successfully configured CWS environment and cwsquery on Sunday. After m52 was made available for resync, I created my first testing cws pj01 and added two modules to it and three tasks that fixed critical build issues for me and several other people. And finally Martin volunteered to look on the result tomorrow.

I find the mechanism quite inconvenient for me because of the following reasons. CWS tools use several environment variables. On Sunday I was happy that this shell script together with my .cwsrc is enough for running cwsquery -m SRC680 latest:

#!/bin/bash
VERSION=SRC680_m52
export SRC_ROOT="/home/pavel/.ooo/ooo_${VERSION}_src/"
export SOLARENV="${SRC_ROOT}/solenv"
export PATH="$PATH:$SOLARENV/bin"
echo "New shell started with cws environment for $VERSION"
bash

But as soon as I started to use cwscreate and similar tools, it was clear that this is not enough. Unfortunately CWS tools do never tell you which variable is not set, so you have to manually investigate. I'm not building on my development system where I have CVS tunnel running, because it is notebook and all building takes place on different system. Thus my notebook is not ready to configure/compile OpenOffice.org. But for these tools, you need to have proper environment configured.

Other magic issue came when I wanted to change the description of my cws. I had to logout from EIS and log in back again. Otherwise it kept telling me ORA-00936: missing expression as if I'm logged in as quest.

I really like the sarcastic humor of the EIS author. When you want to change the Owner of the cws, you have to enter it in the textfield in the form (there is no help so you do not know if you have to enter OpenOffice.org ID, OpenOffice.org e-mail or ...). Of course I have chosen bad format (OpenOffice.org ID only) and it told me:

Could not update object!
The error message was: ORA-02290: check constraint (CWS.CK_CHILDWORKSPACE_EMAILS) violated
Could not update table
Data could not be saved

Good! There is a constraint on *some* field which check (probably) e-mail validity. It displays the form again. Should you have entered the dates for "Estimated due date" before, you'll see e.g. java.util.GregorianCalendar[time=109398<...600 characters omitted>] instead of simple 2004-09-01 in such fields. Quite unreadable ;-) BTW - entering dates is another matter - I thought that US format referenced in help is 2004/09/01 but this is probably wrong, 2004-09-01 is correct format for dates there.

But all in all: I found out that people behind CWS tools and EIS did an enormous amount of work. Thanks for it! (And be patient with people like me who are ... fill-in yourself). -----

SRC680_m52 has been built by Hamburg RE. Child Workspaces integrated: hr6, oasis2, syssettings01, nsplugin2, cfgruggedised, rowlimit2, jl11, tune03, aw016, eou25b, sb21, swdrawobjapi, jl2.

And another wonderful news: help2 child workspace was nominated so we can expect helpcontent2 to be in some milestone soon! -----

Milestone SRC680_m52 is tagged (not yet announced though). I have finished build of it on GNU/Linux and Solaris/SPARC, build on Windows is still running.

There are several identified/reported issues in this milestone. I hope this list can save you time when you try building it. And please do not laugh when you read ... is now ready and no known build problems are known.

• #i32707# - binfilter: `acquire' undeclared (first use this function). Ken reported that this issue is also present on HEAD. Fix is already mentioned in the issue but is not yet integrated. It seems to be as simple as adding one #include:

  Index: xmloff_SchXMLAutoStylePoolP.cxx
  ===================================================================
  --- xmloff_SchXMLAutoStylePoolP.cxx     (revision 59)
  +++ xmloff_SchXMLAutoStylePoolP.cxx     (revision 60)
  @@ -58,6 +58,9 @@
    *
    *
    ************************************************************************/
  +
  +#include <xmlprmap.hxx>
  +
   // auto strip #include "SchXMLAutoStylePoolP.hxx"
   #include "PropertyMap.hxx"

• #i33258# - configure can't work with Sun WorkShop C compiler because of wrong merge (invalid code). It also doesn't support Sun WorkShop C compiler 5.5 that I use on Solaris.
• #i33459# - set_soenv.in is setting the variable DIRECTX_SUPPORT in the environment file, but e.g. canvas or avmedia (on HEAD) is checking for ENABLE_DIRECTX. For compilation on Windows, you need several files from HEAD!
• #i32042# - desktop project depends on berkeleydb. I committed the fix to 20040815 so it will be integrated with this cws. But this is in milestones from about m46. It takes so long to merge such build critical issues...
• #i32858# - dbaccess: toolbox.hrc: No such file or directory. This is also fixed in 20040815.
• #i32398# - repeated builds in libxml2 result in a build failure. The patch is attached in the issue.
• #i32565# - repeated builds in officecfg result in a build failure. The patch is not attached in the issue, because it is simply about adding missing underscore in $(MISC)$/$(TARGET)_delzip target.
• #i33481# - this issue is multi-project. Several files are affected: autodoc/source/ary/inc/nametreenode.hxx, autodoc/source/ary/store/t_storg.hxx, stoc/source/security/lru_cache.h, ucb/source/inc/regexpmap.tpt. The typename was brought in by gcc34 changes but these changes broke .NET2002 compiler on Windows. We probably need to invent a mechanism to overcome this bug, because we want both .NET2002 and .NET2003 to be supported compilers.
• #i33287# - two files (dp_parceldesc.cxx and dp_sfwk.cxx) in desktop project use the function OUStringToOString without rtl:: prefix.
• #i33509# - nsplugin uses gtk/gtk.h include file, but doesn't add proper include paths in CFLAGS.
• #i33458# - repeated builds in scripting/java fails on Windows. Temporary fix is in the issue - simply remove clean target from dependencies. Scripting project has several other minor/non-build issues (#i33504#).
• #i31666# - solenv/inc/unitools.mk still needs to define several tools for cygwin/tcsh builds on Windows.
• #i33009# - solenv/inc/wnt.mk contains wrong prefixes for options Zc:forScope and GR.
• #i29787# - solenv/bin/guw.pl needs two changes to support options like Zc:forScope (see above #i33009#) and delayload.

Update:

• #i33528# - sc/source/core/data/compressedarray.cxx compilation failure.
• #i30357# - solenv/inc/packtools.mk wrongly assume that rpm and rpmbuild are installed in the same directory.

It seems that we have to invent a mechanism to not propagate those build critical issues between milestones and quickly fix them on HEAD. I proposed this solution on IRC (sorry for my English): with each and every milestone (like this one, SRC680_m52), new really-short-term child workspace named like build_only_fixes_src680_m52 (or similar) will be opened. It will stay opened for short time like three or four days and people will commit only build fixes there so this cws will be QA'ed and integrated just before the next milestone is to be prepared. It has several advantages: build critical fixes will be integrated much faster than now, people will start to use milestones because right now they can't (see the list of issues above) thus OpenOffice.org 2.0 will get much more testing. I'd like to hear your opinions (on IRC, of course ;-). -----

There were several interesting news on OpenOffice.org lists today.

Daniel Boelzle announced new version of boost library integrated into CVS (not yet merged) and calls for testers.

Another interesting news came from dev@oo.o mailing list: Christian Werner announced availability of alpha version of an driver for SQLite. Now what is better? ;-)

Hamburg RE switched over to gcc-3.4.1 with visibility patch. Old compilers are still supported. -----

I finally finished build of SRC680_m51 milestone (see previous entry about child workspaces integrated in this milestone).

My builds (English and Czech) for GNU/Linux and Solaris/SPARC (yes! I finally have wonderful machine that is able to finish the build on Solaris/SPARC pretty fast) are at ftp.linux.cz.

There still are several problems during the build:

• #i32707# - binfilter: `acquire' undeclared (first use this function). Ken reported that this issue is also present on HEAD. Fix is already mentioned in the issue...
• #i32042# - desktop project depends on berkeleydb. I committed the fix to 20040815 so it will be integrated with this cws.
• #i32858# - dbaccess: toolbox.hrc: No such file or directory. This is also fixed in 20040815.
• #i32393# - jvmfwk: pasting "SunInfo" and "::" does not give a valid preprocessing token. This is already fixed but not in m51. It will be hopefully merged soon.
• #i33323# - svx project contains bad paths for include files svdobj.hxx and svdpagv.hxx. This issue is new on this branch.

-----

Milestone 51 of SRC680 was announced today (SRC680_m51). This milestone integrated several workspaces: impress15ea, jmf2, encryption, pbhelp02, hr5, docking3, gt10thaiinput, unotlc, tune05, tbe12. Unfortunately this milestone is not buildable outside StarOffice build environment because of #i33256# (missing module avmedia which seems to be StarOffice only).

There still are several known problems during the build (some of them were also present in previous versions, are fixed in community cws but not yet merged). -----

We have received new build machine for Solaris/SPARC. Sun Microsystem Czech, s.r.o. lend as this machine for providing builds on this platform.

This machine is loaded with Sun Solaris 9:

SunOS sunfire 5.9 Generic_112233-12 sun4u sparc
SUNW,Sun-Fire-V250 Solaris

and Sun ONE Studio Compiler Collection:

cc: Sun C 5.5 2003/03/12

I have installed additional packages from Sunfreeware like wget, make, top, rsync, bison, flex (default version flex-2.5.31 has several issues so I downgraded to 2.5.4a), screen and ncurses, gawk and libiconv, m4. Additional packages were installed from blastwave.org.

Right now, I can successfully build until transex3 project and the build is still continuing. I'll post details when the build is finished. -----

Milestone 50 of SRC680 is ready (SRC680_m50). Even my build is finished and upload to ftp.linux.cz is in progress.

This milestone integrated several workspaces: db2003tk, jl10, impress18ea, enusencoding, os35, icu2003tk, dr19, gcc340fixes01, dr14, aw017, formatpaintbrush02, bff2, jlmsi, fixgh, swobjpos04, autotranslationfix, i18n13, docking2, insight01, grouping, dialogxml1, swqbugfixes04.

There were several problems during the build:

• #i32707# - binfilter: `acquire' undeclared (first use this function)
• #i32042# - desktop project depends on berkeleydb. I committed the fix to 20040815.
• #i32858# - dbaccess: toolbox.hrc: No such file or directory
• #i32393# - jvmfwk: pasting "SunInfo" and "::" does not give a valid preprocessing token. This is already fixed but not in m50.

Enjoy! -----

Replace the table at l10n project with my table of supported languages. Grab all data from the old table and replace it. -----

build-7 is at ftp.linux.cz. It is complete (both GNU/Linux, Microsoft Windows builds and also debug builds).

Update: ftp.linux.cz seems to be down right now (Sun Aug 8 20:44:15 CEST 2004). -----

Three new languages were added to cws_srx645_ooo113fix2:

• #i29222# - Kannada
• #i32628# - Tswana
• #i31351# - Galician

Build-7 will contain them all. -----

Unbelievable bug-report in the KDE project (thanks to Luboš).

I wOnder hOw is it pOssible that such peOple use cOmputers. It is pretty dangerous for them, for their computer and also for other people. -----

During the weekend, I worked on several things. One of them was compiling SRC680_m49 on my GNU/Linux build machine. I found and reported several issues:

• #i32400# - psprint/source/printer/cupsmgr.cxx uses unlink, but doesn't include unistd. I wonder where this issue is, because psprint contains unlink calls also in cws_src680_ooo20040815 and the diff between both trees haven't revealed anything suspect.
• #i32398# - repeated builds in libxml2 fail. Repeated builds also fail in officecfg and wizards (see #i31658# because of zip returning error code 12 when it has nothing to do). You have been warned ;-)
• #i32393# - issue with compiler pasting SunInfo (or OtherInfo) with ::.

-----