Re: [dev] new buildservermaster name termite.services.openoffice.org
Hi Eike, I asked Bernd to adapt the database for old entries, so will work soon. For new builds it works already. Gregor Eike Rathke schrieb: Hi Gregor, On Wednesday, 2010-03-17 13:29:01 +0100, Gregor Hartmann wrote: http://termite.services.openoffice.org Please update also EIS, under CWS Tests the buildbot details still point to the old location. Thanks Eike -- Sun Microsystems GmbH Gregor Hartmann Nagelsweg 55 D-20097 Hamburg Phone: (+49 40)23646 892 http://www.sun.de mailto:gregor.hartm...@sun.com Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht München: HRB 161028 Geschäftsführer: Thomas Schröder - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] new buildservermaster name termite.services.openoffice.org
Hi all, due to restructuring at our host OSUOSL the name of the tinderbox machine changed. The master is available at the new address: http://termite.services.openoffice.org If it does not yet work from your location right now, be patient until it has propagated around the world. Happy using Gregor -- Sun Microsystems GmbH Gregor Hartmann Nagelsweg 55 D-20097 Hamburg Phone: (+49 40)23646 892 http://www.sun.de mailto:gregor.hartm...@sun.com Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht München: HRB 161028 Geschäftsführer: Thomas Schröder - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] buildbots: run autoconf before configure for CWS builds
Hi, since builds on buildbots fail from time to time in the configure step (or afterwards due to a broken configure script) I suggest to run autoconf (in the right version) on each CWS build. The reason is that the configure.in is somewhat sensitive to certain versions of autoconf and that merged configure files almost allways break. As autoconf is run on every master anyways this does not hide errors but eases life for developers. On Master builds autoconf is not run since we want to be sure that the master sources run as is. I will deploy this as soon as possible. Gregor - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] buildbots on solaris sparc fail in smoketest
Hi recently the smoketests on solaris sparc failed for recent milestons of DEV300. This issue has now been fixed by Kurt Zenker and develompment. I now restarted the following CWS builds * jl145 * kso42 * dr74 * svxsplit * native278 * sb118 * vcl108 * kohei03 * rtspare02 NOTE: there were more failed builds but the CWSes had been integrated already or were back to status new. Sorry for any inconvenience Gregor - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] solaris buildbot and stl
Hi fixed the soli buildbot yesterday and the sparc one today. everything should be fine now BTW: investigating with kurt why the smoketest on an m8 times out Cheers Gregor Caola'n McNamara schrieb: DEV300_m68/DEV300_m69 solaris buildbots die in soltools http://buildbot.go-oo.org/buildbot/builders/Solaris-Sparc/builds/1567/steps/Compile/logs/stdio i.e. Error: Could not open include filemap. Error: Could not open include filestring. Error: Could not open include fileiostream etc., seeing as soltools no longer depends on stlport and we now expect there to be a system compiler provided stl available to build the build tools before stlport gets built. Is there anyone able to fix up the buildbot ? C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Re: [qa-dev] Re: [dev] Re: [qa-dev] Re: [dev] How to split VCL testtool out?
Hi Lihua
sorry to hear it doesn't work that easy. The approarch that tbo used was
to copy used files in a directory, this aproach was different.
There is another way which I used earlier to help tbo in finding the
files needed.
Use strace and run the testtool. after some grep you can find out which
files were opened. these are the ones used. but be aware that not all
files used are opened at startup. Condiguration and UNO only open files
on demand. So a complete run would be necessary to show all files.
I used this command for tcsh:
strace -f testtool | grep open | grep installdir | grep -v ENOENT
Using some sed or the like will output a nice script that copies the
used files to a new tree.
Maybe that works better.
best Regards
Gregor
Hi Gregor,
Thank you very much for the script.
I tried, sorry, but it doesn't work.
First, some how, build command dosen't work in a script. So I run this
script manually. And when I got the list, and deleted all the .so files
it contained in the basis3.1/program directory. Testtool.bin shows me
segment error. Finally I even tried to use ldd command to find out all
the depend libs, and copy them back to basis3.1/program directory.
testtool.bin still doesn't work.
Do you have any other ideas? Or like tbo said in
http://qa.openoffice.org/source/browse/qa/qatesttool/tools/standaloneTestTool/?hideattic=0#dirlist
:
DEL: standalone TestTool is dead and won't be alive again due to CWS
sb87/83.
Thank you and best regards,
Lihua
在 2009-10-27二的 13:04 +0100，Gregor Hartmann写道：
Hi,
here is a script that outputs a list of filenames.
- start
cd $SRC_ROOT
cd automation
build --all --show | grep Building module | sed s/Building module //
../ttmodules
cd $SRC_ROOT
cd instsetoo_native
build --all --show | grep Building module | sed s/Building module //
../allmodules
cd $SRC_ROOT
grep -v -f ttmodules -x allmodules modules
xargs -I {} cat $SOLARVER/$INPATH/inc/\{\}/deliver.log modules | cut
-d -f3 | sed s,.*/,, | sort -u
-- end
I won't attach it as I don't know if it will be stripped or not. Please
be careful reassembling the lines.
You need a sourcetree which is completely compiled a shell with set
environment and then source the script. (should work with bash and tcsh
and the like)
After removing the listed files from the installed office the testtool
might still run. I did not try it, so no guarantee at all.
Please let us know if it works.
hth
Gregor
Zhu Lihua schrieb:
Hi Gregor,
It's great that you are back. I'll wait for your script then. Thank you
very much for the effort!
Best regards,
Lihua
在 2009-10-27二的 10:14 +0100，Gregor Hartmann写道：
Hi,
never thought of removing unneeded files but a good startingpoint would
be to remove everything that was built after module automation (which
contains the vcltesttool).
so one would need to get a list of the modules needed and get all files
delevered from the remaining modules. Then remove these files in the
installed office.
One exception is the hid.lst but there might be others like some of the
*.rdb files.
I will try to post a script which gets the filenames later.
Gregor
Andre Schnabel schrieb:
Hi,
Original-Nachricht
Von: Zhu Lihua zhuli...@redoffice.com
I've built the openoffice.org on a loongson machine, include testtool.
I wonder how to split testtool out from the installation set? I need a
stand alone testtool.
There once was a set of scripts in CVS:
http://qa.openoffice.org/source/browse/qa/qatesttool/tools/standaloneTestTool/?hideattic=0
Unfortunately it seems, as standalone testtool is not supported anymore.
(What is somewhat strange, as it is the preferred way to use testtool
even for the QA-team).
Maybe someone at the qa project has an idea.
André
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] buildbot builds vs standard builds
Rene Engelhard schrieb: Thorsten Ziehm wrote: Thorsten Ziehm wrote: I do not see the need to bring the build bots near to the build environment here in Hamburg. The request for build bots was (as I know) to have builds in different environments to find build issues in these different environment. When these environment will be nearly the same, then we miss to find these build breakers. buildbots != tinderbox. Perhaps I am wrong, but build bots are used for this! As I know the You are. results of the build bots are used in EIS to get the state, if a CWS is possible to build. But perhaps I am wrong. No, that's tinderbox. that's tinderbox, but the bots (most of them) send their logfiles to tinderbox master, so its both. so it's as Thorsten said. Gregor Regards, Rene - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org -- Sun Microsystems GmbH Gregor Hartmann Nagelsweg 55 D-20097 Hamburg Phone: (+49 40)23646 892 http://www.sun.de mailto:gregor.hartm...@sun.com Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Wolfgang Engels, Dr. Roland Boemer Vorsitzender des Aufsichtsrates: Martin Haering - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] buildbot builds vs standard builds
Hi, another problem or rather a question is: what are Buildbots meant to be good for? Fom when they were introduced they had two tasks to perform 1. Test the build under as many different system configurations as possible. 2. Produce builds which are suitable for QA. so the Buildbots seem to rather obey rule #1 now. The question is if we want to neglect this task of the bots in favor of #2 or not. Gregor Stephan Bergmann schrieb: During FOSDEM, Mechtilde told me about a problem the QA community is experiencing, namely that buildbot builds (of CWSs) are quite different functionality-wise from the standard builds (of milestones and releases, often done by Sun Hamburg Release Engineering). Those differences are especially apparent in Base, Mechtilde told me. This problem in some cases prevents easy testing of a CWS by the QA community, or even thorough testing of a CWS in real life by replacing a standard OOo build with a buildbot CWS build in (semi-)production use. I would assume there are three factors that cause the variance in functionality. For one, Sun Hamburg uses a setsolar build environment instead of the configure build environment used by everybody else (incl. buildbots); what the configure switches corresponding to the setsolar build environment would look like is more or less directly codified in ooo/trunk/solenv/config/sdev300.ini. For another, even if Sun Hamburg used a configure build environment, I assume that many buildbots use additional configure switches that influence the functionality of the resulting OOo. Like when there is a problem building OOo on a given buildbot, and that problem can be worked around with some configure switch, that switch is simply used. That way, I would not be surprised if different buildbots even used different sets of configure switches. (I do not know where to easily look up which buildbot uses which switches, so I did not bother to check.) A third factor might be that different build machines have different versions of compilers and linkers installed, and different versions of header files that OOo code includes or different versions of system libraries that OOo code links against. (By the way, the Sun Hamburg setsolar environment almost completely hides this by providing a centrally managed baseline build environment independent of the machine one is building on.) I would assume that this has much less influence on the observed variance than the configure switches, however. So, in an ideal world, for all the important platforms for which we provide standard builds we should also provide buildbots that produce builds that are (close to) identical functionality-wise to the standard ones. I would love to see someone pick up on this, presumably from the Sun Hamburg infrastructure group. Niels? Anybody? As I understood Mechtilde, she would be happy to help in QAing the processes of getting the buidbots in shape, like testing whether the resulting builds are good enough for practical purposes. -Stephan - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org -- Sun Microsystems GmbH Gregor Hartmann Nagelsweg 55 D-20097 Hamburg Phone: (+49 40)23646 892 http://www.sun.de mailto:gregor.hartm...@sun.com Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Wolfgang Engels, Dr. Roland Boemer Vorsitzender des Aufsichtsrates: Martin Haering - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] buildbot builds vs standard builds
It needed to have a patch applied. done now. I also forced your build again Gregor Andre Schnabel schrieb: and finally ... Original-Nachricht Von: Andre Schnabel andre.schna...@gmx.net I'll try to get at least some linux builds: http://termite.go-oo.org/buildbot/builders/Ubuntu-7.10-i386/builds/661 this failed as well. André -- Sun Microsystems GmbH Gregor Hartmann Nagelsweg 55 D-20097 Hamburg Phone: (+49 40)23646 892 http://www.sun.de mailto:gregor.hartm...@sun.com Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Wolfgang Engels, Dr. Roland Boemer Vorsitzender des Aufsichtsrates: Martin Haering - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] FW:building problems on XP, need your help :)
\euro_1372.c1 which should look like c:\DOCUME~1\QUCANG~1\LOCALS~1\Temp\euro_1372.c1 I guess. What came to my mind is that you might have started 4NT from within the cygwin shell? Try starting it from your XP Desktop. But thats just a wild guess. Q 2. Why can't I find the directory hid in ooo_OOE680_m6_src\solver\680\wntmsci10.pro\bin\,nor the file hid.lst in it ? the directory should be there after delivering a module which contains HIDs. There has to be an entry in the prj/d.lst file to create the directory like this: mkdir: %COMMON_DEST%\bin%_EXT%\hid and an entry to actually deliver the file(s) similar to this: ..\%COMMON_OUTDIR%\misc\*.hid %COMMON_DEST%\bin%_EXT%\hid\*.hid The file hid.lst will only be there if built in a project *and* delivered. This should be the case only in instsetoo_native In boost there are no HIDs and a hid.lst should not be generated! Usually the hid.lst is only generated when there is the following line in the makefile.mk GEN_HID2=TRUE So ether it was inserted in your build or the guard around the commands actually building it has been removed in solenv/inc/*.mk Hope this helps Gregor Hartmann As I have command dmake demakelog.txt , in the demakelog.txt ,I can find,for example: = Building project boost = /cygdrive/e/ooo_OOE680_m6_src/boost dmake.exe: Executing shell macro: +echo %_cwd dmake.exe: Executing shell macro: +echo %_4ver dmake.exe: Executing shell macro: +$(WRAPCMD) echo $(subst,$/stl, $(SOLARINC)) Making .\wntmsci10.pro\bin\hid.lst : --- Deleting E:\ooo_OOE680_m6_src\boost\wntmsci10.pro\bin\hid.lst 1 file deleted 16,384 bytes freed type e:\ooo_OOE680_m6_src\solver\680\wntmsci10.pro\bin\hid\*.hid | sort -u .\wntmsci10.pro\bin\hid.lst.wntmsci10.pro.tmp E:\ooo_OOE680_m6_src\boost\wntmsci10.pro\bin\hid.lst.wntmsci10.pro.tmp - E:\ooo_OOE680_m6_src\boost\wntmsci10.pro\bin\hid.lst 1 file renamed - Do you guys have any suggestion on my problems? Need your help! :-) Awaiting for your earliest reply! And Thanks in advance!! ^_^ Yours sincerely, Cynthia Qu Beijing Redflag CH2000 Software Co., Ltd. BEIJING, CHINA. TEL：010- -6440 2007-05-15 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] The Crash Reporter
Hi, just one more comment... Am 21.03.06, 11:23:07, schrieb Caolan McNamara [EMAIL PROTECTED] zum Thema [dev] The Crash Reporter: [...] Crash reports submitted to the normal Sun crash reporter database are not visible to non-Sun developers. Especially during the development stage of a distro when e.g. new releases of compilers, or other base technology are being used, distro developers really want to get OOo crash reports directly to them, or to their distribution, which are likely to be specific to them alone. There doesn't seem to be a point in spamming the normal bug database with spurious non-OOo problems, at least in the before ready to ship stage. Its even worse. To be able to get also the sourcecode lines of the stacks sun keeps the original debug information for the binaries delivered. Sun then works on the 'enriched' stacks only. So a crash report which is sent in from a build form a non Sun source cannot be used at all since the debug information is missing. So such crash reports are always spam which has to be sorted out. So That's why there are a few hoops to be jumped through if an outside developer want to enable the crash reporter. [...] Gregor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Proposal to remove hid.lst and use symbolic HelpIDs instead
The file hid.lst contains a matching table from symbolic HelpIDs to numeric HelpIDs. Currently the HID.LST has some drawbacks which could be removed when switching to symbolic HelpIDs instead of numeric ones. There are some places, namely Help and the TestTool which need to match the Numeric IDs to a Symbolic ID. This matching is done using the HID.LST. Apart from this generating Automatic HelpIDs and getting IDs into the HID.LST sometimes leads to confusion because there are some boundary conditions which are not obvious. These Problems should be removed altogether by switching to symbolic HelpIDs. But please read the complete Proposal at http://tools.openoffice.org/files/documents/15/3233/Proposal_symbolic_he lpIDs.html Comment are welcome! Enjoy Gregor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
