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 file. Error: Could not open include file. Error: Could not open include file 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 "" | 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 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
[dev] Re: [qa-dev] Re: [dev] How to split VCL testtool out?
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 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
Re: [dev] How to split VCL testtool out?
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 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
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
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" 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] 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
[dev] Stronger Sun engagement in Buildbot/Tinderbox farm
Hi everybody, Some weeks ago the ESC Meeting found that there are too few and instable BuildBots available to the community. In order to have a useful infrastructure to supply installation sets for various Platforms Sun wants to intensify its engagement in supplying running and usably fast BuildBots to the community. Our goals are to have at least one Bot running for Solaris Space, Solaris Intel, Linux, Windows and soon to come Mac Intel. To get better performance for Windows there will be a dedicated server for that, also increasing the performance of Solaris Intel and Linux builds. To keep them up and running there will be one engineer full time to maintain them. To identify the needs and problems and start solving them I would like to call for an IRC Meeting some time next week. Wednesday at 8am German time might be a good idea. Greatly depends on who wants to attend and what timezones they come from. So this would have to be discussed. The agenda is on the following page. Everyone is welcome to add more topics. http://wiki.services.openoffice.org/wiki/BuildBot_Meeting I would like to to invite at least the following people to the meeting. Everybody else is of course welcome as well. Shaun McDonald Mike Leibowitz Pavel Janik Xu Dehua and/or Bao Honglin Christian Lohmaier Thorsten Ziehm See you there Gregor P.S. set reply to [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] FW:building problems on XP, need your help :)
ler for preprocessing failed > ERROR - couldn't remove > /cygdrive/c/DOCUME~1/QUCANG~1/LOCALS~1/Temp/euro_1372.c1 > ERROR - couldn't remove > /cygdrive/c/DOCUME~1/QUCANG~1/LOCALS~1/Temp/euro_1372.c2 > dmake.exe: Error code 130, while making '..\..\wntmsci10.pro\srs\euro.hid' > '---* tg_merge.mk *---' > ERROR: Error 65280 occurred while making > /cygdrive/e/ooo_OOE680_m6_src/wizards/s > ource/euro > dmake: Error code 129, while making 'build_instsetoo_native' > '---* *---' > * looking at the log there is one thing that looks strange to me. There are pathes like \cygdrive\c\DOCUME~1\QUCANG~1\LOCALS~1\Temp\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, Am 22.03.06, 12:21:58, schrieb Caolan McNamara <[EMAIL PROTECTED]> zum Thema Re: [dev] The Crash Reporter: > Yeah, makes sense of course. In our own case RedHat keeps and provides > debuginfo rpms of extracted debugging data, so theoretically I guess we > would be able to use the same or similiar process to make sense of crash > reporter data from our stripped builds. > Is the "stripped stacktrace" -> "stacktrace with symbols" code used by > the Sun process freely available in any form ? The tool heavily relies on our infrastructure to track the checksums and the setup we have over here so it would make no sense to make it available publicly. But it should not be too hard to build some tooling around addr2line to get the same results. Sorry I can't help Gregor - 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]