Re: [dev] buildbot builds vs standard builds
Hi Stephan, I have been providing MacOSX PPC/Intel builds also FreeBSD ports, so I'm interested in your e-mail. Esp, MacOSX Intel builds, we can compare them directly very easily. I'd like to compare build logs with Hamburg environment and mine. I asked MH about it before and rejected http://www.openoffice.org/issues/show_bug.cgi?id=51332 . I was really helped by Pavel Janik's build logs. As told by Caloan, his chroot enviromnet is really useful. http://blogs.linux.ie/caolan/2006/08/02/sinhala-ooo/ http://people.redhat.com/caolanm/ooocvs/makefc3chroot Martin H: > so I consider the question functional differences as an essential one. Yes. I neve know that "register and user survey" is not supported by my packages. I was told Martin Damboldt about it. No PPC users registerd and participated to user survey. > You know that we > do at other occasion the dicussion "when is an OpenOffice.org build an > original OpenOffice.org (tm) build", so I consider the question > functional differences as an essential one. Non Hamburg build can be a "official build". My 3.0.0 MacOSX Intel package has been released as official. Of course, there are some differences between yours and mine. VirtualBox environment might not be not useful as it may be slower than original one, waste some build time by the emulation. I only know about vmware, and it supports only 2 processors. Building time of OOo is one of the big headache, so we'd like to use a native enviroment. Best, From: Stephan Bergmann Subject: [dev] buildbot builds vs standard builds Date: Wed, 18 Feb 2009 12:00:10 +0100 > 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 > > > > pgpJBZI6EzPs8.pgp Description: PGP signature
Re: [dev] buildbot builds vs standard builds
Andre Schnabel schrieb: Hi Nils, 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 know that there were some issue regarding QA'ing buildbot builds in past. To get an idea what the real problem is, we should collect those issues in detail when they occur to find the root cause for them This is quite like going to the woods and look at each tree seperately to understand, what "the wood" is. yes, this is no fun. but the statement was "namely that buildbot builds (of CWSs) are quite different functionality-wise from the standard builds". I think those trees need a look at. You know that we do at other occasion the dicussion "when is an OpenOffice.org build an original OpenOffice.org (tm) build", so I consider the question functional differences as an essential one. you're right, we also need not to analyse the complete wood. Really, we should investigate into the concrete list of issues before thinking about any additional infrastructure. Sorry, this is the totally wrong way of thinking. hmm, I think we should think carefully about the next steps to do. As Thorsten mention in another mail, we still have different setups of the build environment (setsolar vs configure) if we want to merge both into a common one, we should about the way to go. Having the same setup of the build box available is one step, nonetheless we need to determine what the configure switches are to reflect the current settings of the actual 'setsolar' setup. last time I took a look into configure.in there were about 240 to 250 variables to set. many of them not boolean, but version dependent like the compiler version, so we can potentially have a very huge amount of different environment setup. I think it would help to have at least a raw picture what the dangerous settings of the environment really are. the correct way was: How can we get more people helping in development (here QA) by using existing infrastructure. this is in my understanding not excluding each other. We do not need *additional* infrastructure. that would be my hope also, We just want to use existing buildbots to help with cws testing. yes, lets start working on it, Martin - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] buildbot builds vs standard builds
Nils Fuhrmann wrote: > I know that there were some issue regarding QA'ing buildbot builds in > past. To get an idea what the real problem is, we should collect those > issues in detail when they occur to find the root cause for them (as we > always do). If those issues still are existent, I would await that this > list is already available somewhere (Mechtilde, do you have such list?). > Hi Nils, *, I would expect to *always* have subtle (or not so subtle) differences in the build, *as long* as we don't converge to exactly one build system (whatever that might look, not necessarily buildbots). That would be fixing the root cause, in my book. > Really, we should investigate into the concrete list of issues before > thinking about any additional infrastructure. So if such list of issues > is available, I will ask someone of my team to take a look on it. > In concur with Andre. I guess it's about using the existing infrastructure properly - why not setup a buildbot with the exact HH Linux buildenv (publish that as a VM/VirtualBox image at the same time), and keep it in sync with internal builds (of course, having RelEng build on that very same machine/setup would nicely ensure that this is the case)? Cheers, -- Thorsten - 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 Nils, Original-Nachricht > Von: Nils Fuhrmann > 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 know that there were some issue regarding QA'ing buildbot builds in > past. To get an idea what the real problem is, we should collect those > issues in detail when they occur to find the root cause for them This is quite like going to the woods and look at each tree seperately to understand, what "the wood" is. > (as we > always do). If those issues still are existent, I would await that this > list is already available somewhere (Mechtilde, do you have such list?). There is no full list, as we would need to do several test runs on sun builds, compare those to testruns done on equivalent buildbot builds - identify the differencens ... You will find differences due to: - different configure settings (this is from my experience the biggest part, as complete functional areas might be missing) - differnt compilers - different build environment - different test environment This would need to be done for at least all the major platforms and at least all cat0 tests. This is a total of some weeks for running, analyzing and comparing tests. > > Really, we should investigate into the concrete list of issues before > thinking about any additional infrastructure. Sorry, this is the totally wrong way of thinking. the correct way was: How can we get more people helping in development (here QA) by using existing infrastructure. We do not need *additional* infrastructure. We just want to use existing buildbots to help with cws testing. -- Jetzt 1 Monat kostenlos! GMX FreeDSL - Telefonanschluss + DSL für nur 17,95 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a - 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 Stephan, all, 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 know that there were some issue regarding QA'ing buildbot builds in past. To get an idea what the real problem is, we should collect those issues in detail when they occur to find the root cause for them (as we always do). If those issues still are existent, I would await that this list is already available somewhere (Mechtilde, do you have such list?). 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. Really, we should investigate into the concrete list of issues before thinking about any additional infrastructure. So if such list of issues is available, I will ask someone of my team to take a look on it. Nils -Stephan - 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] comments on CWS ooxml03
Hello, yesterday, a lot of changes have been checked in for childworkspace "ooxml03". Obviously these changes are the result of weeks or even months of "private" work, without giving others the chance to give comments early. As already discussed for childworkspace "ooxml02", the code module "oox" has been introduced to contain filter code for the OOXML file format, and has been designed to be independent from other core modules and application code. This included the requirements to be independent during build and to be independent during runtime. The childworkspace ooxml02 already broke the latter in the first run by becomming dependent from sc, but we found a compromiss by separating filter code contained in sc into an own library. Nevertheless, sc still contains a build dependency to oox (which is part of the compromiss of course). Now, I see that ooxml03 introduces dependencies to svx, and that it has been started to use core classes (vcl Graphic, svx filter code, tools String) inside oox. I strongly disagree to do so. Especially the toiols String class is deprecated and its use in new code is discouraged. In the past, we have prevented this with a lot of effort, by using and extending the OOo API and related helper modules (e.g. comphelper and related). Please consider to rework the changes to ged rid of these dependencies. Regards Daniel - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Get started
Hi, Maximilian Odendahl schrieb: Hi, for Windows, see this how to compile and build the office: http://wiki.services.openoffice.org/wiki/Building_OOo_with_Cygwin_on_Windows In the meantime the section "Getting the source code" is not actual. Now Subversion is used. http://subversion.tigris.org/getting.html http://www.collab.net/downloads/subversion/ If you do not own a cws, you only need the client version. For Windows there is the tool TortoiseSVN, you should use it. http://tortoisesvn.tigris.org/ http://tortoisesvn.net/ kind regards Regina - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] buildbot builds vs standard builds
On Wed, 2009-02-18 at 12:00 +0100, Stephan Bergmann wrote: > I assume that many buildbots use additional configure switches that > influence the functionality of the resulting OOo. ... (I do not know > where to easily look up which buildbot uses which switches, so I did > not bother to check.) Navigating around to see a successful build on a random linux build-bot it should be visible at the top of the configure log section, e.g. looking at a sample line http://buildbot.go-oo.org/buildbot/builders/Ubuntu-7.10-i386/builds/658/steps/Configure/logs/stdio I see just configureswitches='--enable-werror with_jdk_home=/usr/local/jdk1.5.0_12 --with-package-format=deb' for that one. Which would suggest that it is using Sun Java 1.5.0 and no other relevant configure options. So that would be an ideal starting point to example a sample build that comes out of that build-bot with a vanilla one. The default configure options are supposed to mirror the default Hamburg setsolar env as close as is practical (e.g. werror is off by default in configure vs setsolar as there are too many compilers with different warnings in the wider field, and the default it to build the mozilla stuff from the old mozilla source tarball rather than prompt to download the pre-built stuff as there isn't pre-builds available for all archs etc, and on systems where prelink has made libgcc_s.so.1 unusable its automatically dropped from the installs at configure time with a warning) > A third factor might be that different build machines have different > versions of compilers and linkers installed, I would assume that this > has much less influence on the observed variance than the configure > switches, however. I suspect it has quite a degree of influence unfortunately. There has been a quite incredible sequence of weird-ass gccs floating around in the 4.0 to 4.1 range. I don't actually think that its a matter that the build bots configure switches are destroying an otherwise flawless set of builds that would be functionally identical to the Hamburg vanilla set. > 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 > zSun Hamburg infrastructure group. My understanding was that the o3 developer cd was an attempt to provide the same compiler and baseline etc. as used in Hamburg for externals to build OOo against. I never had much success with using it directly, *but* I was able to use that o3 compiler with an old Fedora Core 3 chroot which I've used successfully to generate install sets which pass Hamburg qa without getting caught on irrelevant problems caused by various compiler, binutils, prelink, too-new gtk version, etc problems which absolutely plague efforts to create workspaces which both work on Hamburg test machines with equal results to the baseline build. C. (Of course its not the case that the baseline compiler is some magic compiler free of errors, just that its errors are typically known and the optimization workarounds for the Hamburg compiler get hacked in for that version) - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Get started
Roman, I recently started building on Windows myself. The page Maximillian mentioned ( http://wiki.services.openoffice.org/wiki/Building_OOo_with_Cygwin_on_Windows) is a great resource, and definitely your best friend in getting OOo to build. I made a few changes to it myself to reflect my own experiences. I used VS2008 express (free download) and it built fine (DEV300_M37). Once you get it all building, you will probably want to write a script that ties together the whole process to make it simple. I have one that does the following (let me know if you want that): 1) copies the required 'external' files into the appropriate source directories 2) configures the build 3) bootstraps the build, then begins the build process. Robert 2009/2/18 Frank Schönheit - Sun Microsystems Germany < frank.schoenh...@sun.com> > Hi Roman, > > Max already have you some pointers, but one note on the following: > > > I using > > VisualStidio 2005, so could you help me to get started? > > As far as I know, VS2005's compiler is not supported for the current > code line anymore. You should get an Express edition of Visual Studio > (it's for free, and lacks some features, but those are not essential for > OOo work). > > Ciao > Frank > > > -- > - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - > - Sun Microsystems http://www.sun.com/staroffice - > - OpenOffice.org Base http://dba.openoffice.org - > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.org > For additional commands, e-mail: dev-h...@openoffice.org > >
[dev] buildbot builds vs standard builds
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
Re: [dev] charts and drawing to images
This is discussed on the graphics mailing list d...@graphics.openoffice.org Kind regards, Ingrid Daniel Garcia wrote: Hi all, Description of the problem I am using odfdom in conjunction with my OpenOffice to create a Odf2Xhtml compiler. This compiler will have a template that we have designed as an entry and will generate both the corresponding html and css files. So far I have been able to extract text, tables and images but I am now facing a problem with charts and drawing: 1.- Charts because OpenOffice provides them in a startview metafile format which I am not yet able to convert into JPG or gift 2.- Drawing are not supplied by OpenOffice as any treatable format. What Am I looking for? What I am looking for is a way so that I can get charts and drawing as images (jpg or gift since they will be shown by a browser and all of us know how IEx behaves :)) via any api, preferably java without having an OpenOffice instance running in the background? Why? I would like to offer my client a server application where thy send the document and by magic art they have got the css and html files. What solutions I have looked for but they do not convince me: 1.- To convert the odf document to pdf and then use a java api to extract the images. I have done a small test and it seems to be, pdf viewers are not able to extract charts and drawing. I have not researched further more but... 2.- Tell my client to convert the file to html and then get those charts and drawing as images: that is ok but the generated images are named with a strange name that I can't match with the objects in the openoffice document. For example, if there is a chart called 'graphic 1' the name of the file that the html conversion provides is something that has nothing to do with that. 3.- User the version of above (second) but telling the clients to replace those graphics by the actual charts or drawing. 4.- There is a python application called unoconv that looks interesting but this need to an OpenOffice instance running in the background. What I need 1.- Is there anyone who has dealt with this problem before or is there any tip, url, article, piece of code or whatever that I can follow to solve out this problem please? 2.- Is there any beta API which would help me with this? 3.- Does anyone know if OpenOffice is aware of this problem and there are already projects in place to provide those charts and drawing in a format that others API's can play with it? Thank you very much in advance, Daniel. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Get started
Hi Roman, Max already have you some pointers, but one note on the following: > I using > VisualStidio 2005, so could you help me to get started? As far as I know, VS2005's compiler is not supported for the current code line anymore. You should get an Express edition of Visual Studio (it's for free, and lacks some features, but those are not essential for OOo work). Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Get started
Hi, for Windows, see this how to compile and build the office: http://wiki.services.openoffice.org/wiki/Building_OOo_with_Cygwin_on_Windows After this worked out, I would try to start with easy bugs, probably have look at issues with target OOoLater or the ones which interest you. Here is also a list: http://wiki.services.openoffice.org/wiki/BugBountyProgram Best Max Roman Skalish schrieb: Hi, I have read your Participate in OpenOffice.org and I want started in your projects I have more then 2 year experience in C\C++ programming. But in you site is so match information, links, etc… and it is hard to fund from what started, what sources download… I using VisualStidio 2005, so could you help me to get started? Thanks Roman. -- реклама --- Научись зарабатывать во время финансового кризиса. Пройди Обучение Биржевой Торговли! http://www.forexclub.ua/?utm_source=i.ua_t - 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] Get started
Hi, I have read your Participate in OpenOffice.org and I want started in your projects I have more then 2 year experience in C\C++ programming. But in you site is so match information, links, etc… and it is hard to fund from what started, what sources download… I using VisualStidio 2005, so could you help me to get started? Thanks Roman. -- реклама --- Научись зарабатывать во время финансового кризиса. Пройди Обучение Биржевой Торговли! http://www.forexclub.ua/?utm_source=i.ua_t - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
