Re: [VOTE] New Apache OpenOffice PMC Chair
On 12/08/2017 07:53 PM, Marcus wrote: > [...] > Luckily we have 2 volunteers: Carl and Peter. Therefore please vote by > replying to this thread. > > [ ] Carl Marcum (cmarcum) > [ ] Peter Kovacs (petko) > [ ] Abstain (I cannot/won't choose between them) +1 for Peter Kovacs (petko) Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [Discussion] Switch to Git?
On 09/18/2017 06:30 PM, Damjan Jovanovic wrote: > On Mon, Sep 18, 2017 at 7:44 PM, Herbert Duerr <h...@apache.org> wrote: >> On 09/17/2017 04:04 PM, Andrea Pescetti wrote: >>> On 14/09/2017 Dave Fisher wrote: >>>> does SVN vs. GIT prevent new developers from volunteering? >>> >>> I think this is the key question, even though there are many good points >>> also in what others replied. >>> >>> We currently have a couple semi-official GIT mirrors: one on Github in >>> the ASF organization page and the internal one Herbert pointed out. I >>> also remember that Herbert once presented a big GIT repository he had >>> built with all the available history of the OpenOffice code, but I don't >>> know if it is available somewhere. >> >> I had that 2GB blob on my Apache homepage for a couple of years. When >> that home was migrated to the newer locations it was apparently dropped. >> Unless someone mirrored the blob it is currently not available anymore. >> If anyone is really interested in that ancient history I can probably >> resurrect it unless 2+GB blobs are no longer allowed in committer's home >> directories. >> >> > That would be great. I need the old repository to regression test an old > bug in Base. However, is it legal to have commits from the pre-ASLv2 era? The related presentation is still available at [1], and I found my blob of the historic repos in [2]. Enjoy! [1] http://home.apache.org/~hdu/HistOOory_Presentation.pdf [2] https://dev-www.libreoffice.org/extern/HistOOory_v0.9.zip >>> I believe that the interested developers (including me, at times) use >>> the git-svn tool when convenient. I think that this is enough to allow >>> the local workflow improvements Damjan was requesting. Or do you see >>> reasons not to use it? >> >> OpenOffice is only a small part of the Apache subversion repository that >> contains many more projects. Most revisions in that repo are not for OOo >> and git-svn apparently has a hard time with this. It is possible but not >> much fun. >> >> > Excellent insight. Never thought of that. git-svn is almost unusable then. I think that it could be possible to improve git-svn in cases such as the multi-project Apache svn-repository, but that scenario + devs in an svn-project using git as their main repo tool is unusual enough that it is not worth too much optimization effort. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [Discussion] Switch to Git?
On 09/17/2017 04:04 PM, Andrea Pescetti wrote: > On 14/09/2017 Dave Fisher wrote: >> does SVN vs. GIT prevent new developers from volunteering? > > I think this is the key question, even though there are many good points > also in what others replied. > > We currently have a couple semi-official GIT mirrors: one on Github in > the ASF organization page and the internal one Herbert pointed out. I > also remember that Herbert once presented a big GIT repository he had > built with all the available history of the OpenOffice code, but I don't > know if it is available somewhere. I had that 2GB blob on my Apache homepage for a couple of years. When that home was migrated to the newer locations it was apparently dropped. Unless someone mirrored the blob it is currently not available anymore. If anyone is really interested in that ancient history I can probably resurrect it unless 2+GB blobs are no longer allowed in committer's home directories. > I believe that the interested developers (including me, at times) use > the git-svn tool when convenient. I think that this is enough to allow > the local workflow improvements Damjan was requesting. Or do you see > reasons not to use it? OpenOffice is only a small part of the Apache subversion repository that contains many more projects. Most revisions in that repo are not for OOo and git-svn apparently has a hard time with this. It is possible but not much fun. > As for the new developers, most new developers are probably familiar > with the "pull request" convention. This is not supported by either of > the current repositories, mostly due to ASF policy. Last time I checked, > Infra was still discussing how we can allow pull requests in a way that > complies with the policy and I have no idea whether this is resolved. > Once we have official support from Infra and a friendly pull request > system, this might indeed improve the approach for new developers. Agreed. The workflow with pull request is so much nicer than handling patches... Best regards, Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [Discussion] Switch to Git?
Hi, FWIW we already have an official git mirror of our svn repository. Do a git clone git://git.apache.org/openoffice.git to check it out. Such a repo is currently read-only of course until the project switches officially to git. Herbert On 09/14/2017 11:10 AM, Damjan Jovanovic wrote: > Hi > > Can we please switch to using Git instead of Subversion for AOO's source? > > I don't know how much justification you want/need. Git is huge nowdays, by > far the most popular VCS worldwide, the one most developers know and IDEs > support (https://rhodecode.com/insights/version-control-systems-2016). It > would help us with local branches for testing and experimenting offline, > git bisect for regression testing, it's efficient with large projects, it > would integrate with GitHub better, etc. > > What do people think? > > Damjan - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [VOTE] Recommend Marcus Lange (marcus) as the New Vice President for Apache OpenOffice
On 09/15/2016 03:35 PM, Dennis E. Hamilton wrote: > RESOLUTION: That Marcus Lange (marcus) be recommended to the > Apache Software Foundation Board to serve as Vice President > for Apache OpenOffice. +1, approve Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [VOTE] Dennis Hamilton as new AOO Chair.
On 2015-08-16 08:57, jan i wrote: This is a call for a formal vote among the 1 candidate for the AOO Chair role. [...] +1, I want Dennis Hamilton as new Chair Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [BUILDBOT] - FreeBSD nightly (openoffice-fbsd-nightly)
Hi Gavin, thanks for looking into this! On 2015-05-06 13:46, Gavin McDonald wrote: So the build got further, both configure and buildstrap passed. Now we get libtextcat errors , see: http://ci.apache.org/builders/openoffice-fbsd-nightly/builds/328/steps/build%20--all/logs/stdio http://ci.apache.org/builders/openoffice-fbsd-nightly/builds/328/steps/build --all/logs/stdio [...] ERROR: error 65280 occurred while making /usr/home/buildslave27/slave27/openoffice-fbsd-nightly/build/main/libtextcat When you have fixed the errors in that module you can resume the build by running: build --all:libtextcat Any ideas on that one? There should be a log file for the libtextcat problem with more specific details about the error, but I can't look as the AOO FreeBSD buildbot log files are not available where they should be [1] because their delivery failed [2]. As a reference the corresponding good log file (e.g. for Linux) is at [3]. Please check the log files on the build machine itself at main/libtextcat/unxfbsdx.pro/misc/logs [1] http://ci.apache.org/projects/openoffice/buildlogs/fbsdn/log/unxfbsdx.pro.build.html [2] http://ci.apache.org/builders/openoffice-fbsd-nightly/builds/328/steps/move%20logs%20to%20web/logs/stdio [3] http://ci.apache.org/projects/openoffice/buildlogs/linux64/main/libtextcat/unxlngx6.pro/misc/logs/libtextcat.txt Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: mingw32 for building the ODK under Linux?
On 2015-04-29 00:07, Kay Schenk wrote: I normally set --disable-odk in my builds. When I enabled it today for some testing, I get an configuration error that says -- checking for external/unowinreg/unowinreg.dll... configure: WARNING: not found, will be cross-built using mingw32 configure: error: for rebuilding unowinreg.dll you need the mingw32 C++ compiler. Specify mingw32 g++ executable name with --with-mingwin. Or use prebuilt one from http://tools.openoffice.org/unowinreg_prebuild/680/ and put it into external/unowinreg using your browser or a command equivalent to: wget -O external/unowinreg/unowinreg.dll http://www.openoffice.org/tools/unowinreg_prebuild/680/unowinreg.dll Is this really needed for Linux builds of the ODK? If you want to build an ODK that can run on windows then this DLL is needed. As the error message says you can build this DLL from scratch or you can download the pre-built library from [1]. For some background info please see the thread around [2]. I usually take the pre-built binary blob and put it into main/external/unowinreg/ as suggested by the error message. It isn't mentioned in our build information. The unowinreg.dll blob is mentioned as a prerequisite in [3]. [1] http://www.openoffice.org/tools/unowinreg_prebuild/680/unowinreg.dll [2] http://markmail.org/message/lwgjbdvtoyijymwf [3] https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO#General_Build_Requirements Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
CVE-2015-1774: OpenOffice HWP Filter Remote Execution and DoS Vulnerability
CVE-2015-1774 OpenOffice HWP Filter Remote Code Execution and Denial of Service Vulnerability A vulnerability in OpenOffice's HWP filter allows attackers to cause a denial of service (memory corruption and application crash) or possibly execution of arbitrary code by preparing specially crafted documents in the HWP document format. Severity: Important Vendor: The Apache Software Foundation Versions Affected: All Apache OpenOffice versions 4.1.1 and older are affected. Mitigation: Apache OpenOffice users are advised to remove the problematic library in the program folder of their OpenOffice installation. On Windows it is named hwp.dll, on Mac it is named libhwp.dylib and on Linux it is named libhwp.so. Alternatively the library can be renamed to anything else e.g. hwp_renamed.dll. This mitigation will drop AOO's support for documents created in Hangul Word Processor versions from 1997 or older. Users of such documents are advised to convert their documents to other document formats such as OpenDocument before doing so. Apache OpenOffice aims to fix the vulnerability in version 4.1.2. Credits: Thanks to an anonymous contributor working with VeriSign iDefense Labs. signature.asc Description: OpenPGP digital signature
Re: Spam on bugzilla
On 2015-03-12 17:38, jan i wrote: On 12 March 2015 at 17:27, FR web forum ooofo...@free.fr wrote: https://bz.apache.org/ooo/show_bug.cgi?id=117896 https://bz.apache.org/ooo/show_bug.cgi?id=119006 https://bz.apache.org/ooo/show_bug.cgi?id=24317 Andrea just sent an email to infra, I suspect it is the same theme. The account was registered since last november but hasn't done much since. I didn't delete the account yet but disabled it by changing the password... I cannot remove the spam comments though, but I think that is hiding such comments is a planned feature for Bugzilla. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Some old OOo SVN dumps, of use to anyone?
On 2015-03-03 00:21, Rob Weir wrote: On Mon, Mar 2, 2015 at 3:24 AM, Herbert Duerr h...@apache.org wrote: On 2015-02-28 23:05, Andrea Pescetti wrote: Rob Weir wrote: It could be even more useful, of course, if hosted as an actual (read-only) repository, to consult the history of the code base. Isn't this part of Herbert's big git repo with the whole code history that it was possible to reconstruct? Yes, my git repository of the AOO/OOo history [1] also contains the import of the then available latest OOo-SVN repo. The old OOo project only used SVN from 2008 to 2009 and though the SVN repo had imported a few CVS branches the most interesting ones (e.g. all the CVS child-workspace branches where the actual development happened between 2003-2008) were dropped during that import and due to the way things were merged many interesting commit details were dropped too. [...] Any idea why your ZIP is only 2GB, but my dump is 150GB? Even when I zip my svndump file it is still 21GB. So I wonder if I have something different or more than what you have. Or is git really that much more efficient at storing a revision history? Yes, git can be extremely efficient for preserving code history. 99% of my 2GB blob consists of such git pack file. The zip format of my blob is mainly to add missing pieces (e.g. tag names, branch names, mailmap, grafts) and to prepare the directory layout as expected by typical git tools [1]. The zip-compression is quite irrelevant for the blob. Any other directory-preserving container would have been fine, but zip is well known and ubiquitous. [1] https://git.wiki.kernel.org/index.php/InterfacesFrontendsAndTools#Graphical_Interfaces By the way, I just noticed that the historical blob just contains the OOo-CVS, OOo-SVN and OOo-HG histories. If needed the AOO history and maybe the LO history could be added later to get a more complete picture of all the relationships and interactions. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Some old OOo SVN dumps, of use to anyone?
On 2015-02-28 23:05, Andrea Pescetti wrote: Rob Weir wrote: It could be even more useful, of course, if hosted as an actual (read-only) repository, to consult the history of the code base. Isn't this part of Herbert's big git repo with the whole code history that it was possible to reconstruct? Yes, my git repository of the AOO/OOo history [1] also contains the import of the then available latest OOo-SVN repo. The old OOo project only used SVN from 2008 to 2009 and though the SVN repo had imported a few CVS branches the most interesting ones (e.g. all the CVS child-workspace branches where the actual development happened between 2003-2008) were dropped during that import and due to the way things were merged many interesting commit details were dropped too. These interesting parts of the old OOo-CVS history were also recovered and put into my git repo. The 2009-2011 code history in Mercurial and the 2011-2014/01 AOO history are also included. For more details please see my last year's FOSDEM presentation [2]. [1] http://people.apache.org/~hdu/HistOOory_lastest.zip [2] http://people.apache.org/~hdu/HistOOory_Presentation.pdf If it's already there, nice; if not, ideally it should be merged with it. It should already be there, but somebody please check it with some samples. For a more complete history the bit git repo should be updated with the latest AOO progress. And the mercurial import could be redone with hg-hash annotations enabled too. Hope that helps, Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [PROPOSAL] move repo to Git.
Hi Pedro, I don't currently use git but what I use is not really important: if a move to git were to be considered, it would only make sense if we can rescue the pre-apache history and in particular the Hg CWSs. Most of the open-source history has been preserved. I talked about this in my last year's FOSDEM presentation [1]. The code history was provided a big git repository in a 2GB blob [2]. Unzip it and start your favorite git tool to explore it (e.g. gitk --all). [1] http://people.apache.org/~hdu/HistOOory_Presentation.pdf [2] http://people.apache.org/~hdu/HistOOory_lastest.zip Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [VOTE] New Apache OpenOffice PMC Chair
On January 30, 2015 7:52:16 PM CET, Andrea Pescetti pesce...@apache.org wrote: [...] Who of the two candidates do you prefer to replace Andrea Pescetti as the OpenOffice project PMC Chair? [ ] Dennis E. Hamilton (orcmid) [ ] Jan Iversen (jani) Two excellent candidates. Thanks for running! And many thanks to Andrea for his outstanding performance as PMC Chair. +1 for Jan Iversen Hi from FOSDEM in Brussels! Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Has SVN Robot stopped to work?
On 08.01.2015 18:32, Regina Henschel wrote: I see no notifications in Bugzilla for new commits. The last one I found is in issue 125981 from 2014-12-30. Thanks for noticing! The server must have had an outage at that time. Our svn robot service has been restarted now and the seven missed commits have been re-processed. If anyone is interested to help maintain this the first step would be to get yourself added to the svn2bz group for the sif.zones server. I guess writing a JIRA issue to INFRA is the best way to accomplish this. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Officeshots.org
I'll try to provide one for the plugfest. I'll probably have it running on my notebook in a dedicated virtual machine. On 02.12.2014 23:43, Michiel Leenaars wrote: Dear Apache OpenOffice developers, as some of you will know we have the 10th ODF plugfest coming up next week, hosted by the UK Cabinet Office [1] - for which you are all invited, of course. For that purpose (and to support the UK government migration to ODF) we are working hard on Officeshots.org. Officeshots is an automated validation and testing infrastructure that contains instances of many different office applications (and potentially different versions), and can be used to see how documents will be opened and rendered by other ODF consuming applications. It would be really awesome if someone from the Apache OpenOffice community would set up a copy of AOO for Officeshots.org (ideally on multiple platforms and both a trunk version and a release, but lets start with the basics). This is not a very difficult or time consuming thing to do, and it can run on a desktop in the background or on a small virtual machine somewhere. It would however be very useful for interop testing, because all test documents created during the plugfest can be automatically pushed to it. Also, the upcoming ODF Autotests infrastructure can use the same infrastructure. The manual for installing a factory can be found here: http://code.officeshots.org/trac/officeshots/wiki/FactoryManual If you find yourself with an hour of time and the kindness to volunteer, please register at http://www.officeshots.org and subsequently contact me to get the appropriate rights to set up a factory. Best regards, Michiel Leenaars OpenDoc Society [1] http://plugfest.opendocumentformat.org === Support NLnet, the open internet and open source with just 5 minutes of your time. Make a difference today. Visit: http://nlnet.nl/help (English) - http://nlnet.nl/ayuda (Espanol) === - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Compiling 4.1.1 on MacOS X 10.6.8 (intel) - GCC version problem
On 27.11.2014 01:09, Clive Bruton wrote: I am trying to compile OpenOffice 4.1.1 to run on MacOS X 10.6.8. For building older versions of OpenOffice on Mac please see [1]. It requires XCode 2 or XCode 3, both of which are not easy to get nowadays. They are also almost impossible to install on current systems. For these older versions the page also documents the requirement to compile with the 10.4 SDK. For building AOO 4.1 or newer please see [2]. The build system has been reworked to allow current XCode versions (4.5 or newer) and works fine with newer SDKs (10.7 or newer). However OSX 10.7 or newer are a requirement for these newer builds. [1] https://wiki.openoffice.org/wiki/Documentation/Building_Guide/Building_on_MacOSX [2] https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Building_on_MacOsX When I run the ./configure it runs for a few seconds then shows the following error: checking the GNU gcc compiler version... configure: error: found version 1.0.2, use version 3+ of the gcc compiler If I run: gcc -v I get: gcc version 4.2.1 (Apple Inc. build 5659) Any ideas on how to fix this? Also, what's the specific reason 4.1.1 isn't built as a binary for 10.6.8, while 4.0.1 is? Please see above. The build system was quite outdated, the build requirements were more than obsolete and targeted platforms that were no longer supported by Apple. Also many other vendors like Mozilla, Google, Microsoft, Adobe, etc. had already dropped support for these old platforms. When we did the overdue refresh for newer platforms we also used the opportunity to switch to 64bit. It would have been possible to get it work on OSX10.6 too, but it was already unsupported by Apple then and nobody was interested to put work into backporting the stuff [3]. [3] http://markmail.org/message/qfqarbaoesonibur Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Compiling 4.1.1 on MacOS X 10.6.8 (intel) - GCC version problem
On 27.11.2014 12:31, Clive Bruton wrote: On 27 Nov 2014, at 08:35, Herbert Duerr wrote: For building older versions of OpenOffice on Mac please see [1]. I think what you are saying is that there are dependencies in the code that require 10.7. If this is the case then the error reported should be that the system is not supported (and why), rather than the gcc version is incorrect. Agreed. This and other messages should be updated to pinpoint the exact root cause. Also the configure options that don't make sense on a platform should be removed altogether. While reworking the configure step IMHO also the advanced options should have to be enabled extra. There is plenty of opportunity to make the configure step and the build system much smoother. It requires XCode 2 or XCode 3, both of which are not easy to get nowadays. They are also almost impossible to install on current systems. For these older versions the page also documents the requirement to compile with the 10.4 SDK. Actually, these versions of Xcode are easy enough to get (I downloaded 3.2.6 just a few days ago), and at least with 3.x the option is there in the install to include support for 10.4. The old versions of Xcode are here (Xcode 2.3-6.1 for download, just search for Xcode): https://developer.apple.com/downloads/index.action Installing and running these old XCodes on recent systems (e.g. Yosemite) is the really tricky thing. And finding and downloading their blobs is also not as easy as installing them from the app store. Please see above. The build system was quite outdated, the build requirements were more than obsolete and targeted platforms that were no longer supported by Apple. Also many other vendors like Mozilla, Google, Microsoft, Adobe, etc. had already dropped support for these old platforms. When we did the overdue refresh for newer platforms we also used the opportunity to switch to 64bit. It would have been possible to get it work on OSX10.6 too, but it was already unsupported by Apple then and nobody was interested to put work into backporting the stuff [3]. Thanks for the note. I think the issue is that all the companies you name have a commercial interest in obsolescence, I'm not sure what the incentive for the Apache foundation would be in supporting that business model. I'm not sure that e.g. Google or Mozilla are interested in planned obsolescence. They are probably just not interested in putting extra effort into providing upgrade paths for users that seem to be averse to upgrading. The law of diminishing returns applies in this situation. From my own perspective, and I am probably in a small minority, my interest in supporting older systems (ie up to 10.6) is because they are able to run PPC and classic apps, which 10.7 is unable to do. I'm pretty sure I have Apache and MySQL running on such systems. The two Apache projects you mentioned probably just require plain POSIX compliance for their development platforms. AFAIK this aspect of the Mac development environment has remained stable, so not extra effort was required, whereas in our GUI heavy requirements plenty of stuff has been deprecated. We cannot ignore these deprecations forever, they'll be removed sooner or later. Anyway, in your case I suggest to build the latest AOO 4.0.1 source [1] on XCode3 with the Mac 10.4 SDK using the build instructions at [2]. [1] http://svn.apache.org/repos/asf/openoffice/tags/AOO401/ [2] https://wiki.openoffice.org/wiki/Documentation/Building_Guide/Building_on_MacOSX Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Issues for vertical layout on Mac
Hi Aron, On 27.11.2014 08:53, aron wrote: I reported a vertical layout issues under Mac at here https://www.libreoffice.org/bugzilla/show_bug.cgi?id=86768 also reported it at OpenOffice's bugzilla https://issues.apache.org/ooo/show_bug.cgi?id=125908 It looks like OSX's CoreText does funny things when vertical mode is requested for fonts that don't understand the concept of vertical mode. I suggest to experiment with the pCFVertBool variable in main/vcl/aqua/source/gdi/ctfonts.cxx or by disabling the line setting the value for KCTVerticalFormsAttributeName altogether. If it shows that only fonts without OpenType's vert or vrt2 feature are affected we could add a check for this and then work around this CoreText problem. I've updated the AOO issue you reported accordingly. Like shown in the illustration below, both Mongolian and English text is not handled correctly on vertical layout mode under Mac(and Ubuntu too although there is no Ubuntu's screen shot at here). Attachments are stripped from mails sent to this mailing list so the images cannot be seen. But they are available in the issue you reported. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: missing new aoo4.2 win nightly snapshot
On 19.11.2014 20:00, Oliver Brinzing wrote: Apparently the Windows build gets named after the revision of the latest commit in AOO's trunk whereas other builds get named after the latest commit in the big ASF repository. this behaviour is new, i first noticed it about two weeks ago. Looking at an older log from the linux-buildbot log, e.g. [1] from one month ago the svn-step there set the got_revision property to the latest revision of the full ASF-repository too. [1] http://ci.apache.org/builders/openoffice-linux32-nightly/builds/185/steps/svn/logs/stdio AOO Help/Info shows: AOO420m1(Build:9800) - Rev. 1635806 for today's build, so i think the builds did not change the last two weeks? The major and minor versions and the build number of the product are set manually and didn't change in the last two weeks. The latest AOO trunk revision remained at 1635806 in this timeframe. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: about vertical text direction
Hi Aron, On 20.11.2014 11:50, soyol aron wrote: I want to insert a text box which can show vertical text in writter. But It seems like that there is no options for vertical direction text in the combo box in frame’s setting dilaog, just likes the screen shot below. (this is a Libre Office's screenshot but I think that this is same to OpenOffice) I'm not sure whether I understood your question. But I know that the user interface elements for vertical writing are only enabled when the setting Tools-Options-LanguageSettings-Languages-ShowUIforEastAsianWriting is enabled. Does enabling that checkbox help with your problem? Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: missing new aoo4.2 win nightly snapshot
On 18.11.2014 23:41, Kay Schenk wrote: On 11/18/2014 08:32 AM, Oliver Brinzing wrote: http://ci.apache.org/projects/openoffice/ Windows Nightly (aoo-win7) Nov 18 02:30 1635806 success #217 Build successful looks like revision 1635806 is build every night ... linux build is at rev. 1640267 Regards Oliver The windows buildbots are setup slightly differently than the linux ones. We need to investigate why the different options are causing this mismatch. (???) Many Apache projects (including AOO) share the huge repository at svn.apache.org. So if there is a commit in another project then the revision number of the whole repository is increased. This new revision number can then be used as an indicator how current a checkout is. The revision number of the latest commit to a particular project is another interesting indicator. Unless this particular project got the latest commit then this revision number is different from the one of the full ASF repository. Apparently the Windows build gets named after the revision of the latest commit in AOO's trunk whereas other builds get named after the latest commit in the big ASF repository. Both numbers have their merit. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: missing new aoo4.2 win nightly snapshot
On 18.11.2014 17:32, Oliver Brinzing wrote: http://ci.apache.org/projects/openoffice/ Windows Nightly (aoo-win7) Nov 18 02:30 1635806 success #217 Build successful looks like revision 1635806 is build every night ... As of today revision 1635806 is the revision of the latest commit to AOO's trunk. Github has a nice view of trunk commits at [1]. [1] https://github.com/apache/openoffice/commits/trunk linux build is at rev. 1640267 Please see my other mail on why this number is different but the actual source that was build was the same. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Very simple first patch
On 14.11.2014 01:04, Kay Schenk wrote: On 11/13/2014 03:10 PM, Andrea Pescetti wrote: On 13/11/2014 Michal Hriň wrote: [...] It is a update of external package :) And here is a problem, but it doesn't depend on you. Policy so far has been: we download build-time dependencies from the Extensions site and from Apache Extras. Can we get a memory refresher on why we can't use the svn versions of these external sources directly? David Fisher wrote in [1] that he removed them because fallback urls to svn are now removed as per Infra policy. I guess the revision control server that is so very critical to so many ASF projects should not be impeded by the download of such large third-party tarballs. [1] http://svn.apache.org/viewvc?view=revisionrevision=r1377529 [...] It seems like the testing from the new SourceForge are is going pretty well... http://markmail.org/message/4p3klhqkkvszmwav Maybe time for some additional testing from: http://sourceforge.net/projects/oooextras.mirror/files/ I'll make local changes and test with this as new OOO_EXTRAS area. Who would have rights to update these files on SF? The sourceforge ooextras.mirror project currently has only one administrator [2]. [2] https://sourceforge.net/u/sf-editor1/ Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
CVE-2014-3524: Apache OpenOffice Calc Command Injection Vulnerability
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 CVE-2014-3524 OpenOffice Calc Command Injection Vulnerability Severity: Important Vendor: The Apache Software Foundation Versions Affected: Apache OpenOffice 4.1.0 and older on Windows. OpenOffice.org versions may also be affected. Description: The vulnerability allows command injection when loading Calc spreadsheets. Specially crafted documents can be used for command-injection attacks. Further exploits are possible but have not been verified. Mitigation: Apache OpenOffice users are advised to upgrade to Apache OpenOffice 4.1.1. Users who are unable to upgrade immediately should be cautious when opening untrusted documents. Credits: The Apache OpenOffice security team credits Rohan Durve and James Kettle of Context Information Security as the discoverer of this flaw. Herbert Dürr Member of the Apache OpenOffice Security Team -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (Cygwin) iQIcBAEBAgAGBQJT9e2fAAoJEDfnuKc+PLjJNT0P/1kg+qHwcuqDScV2HdOHbIP3 409ABpECFSLsAf4S6EwpBTeSBQoBCco+uyzMPJ9yOO6xcDdcuq2BF6vdBLL46UKC WP+yy4G4BBAX/NnE+mTVT2Tc+JgwJJ6Zzd03JuIQo4T0qnsnYjfG7fAY9fx4vTc5 TAvFEakG8Nrrvoq5s856aKZdRlM5JMsUPzFd1JtsWopWmyRWHd9dNwJZJAmTr68F 3QeBONe9SKK1nb9TxQt5W4MUbraw6doN6q5bDa8eDJUiwzGraMqdCBTD2tVe09BF Mi2TM6lJc4D27aZ8vMxZJTMWRGNGSU9fAuZYNmndXCYGk3rjKB6ghEfxK2DjaG5b KuXAg6jg8Q+9CZNL769h1NIavj+Yhs7ouiFgS5gkb0l8oeU/UiCcmqq5y0cTzT43 Bu/5VYLj4dNq2XwwMLY7lzQeJ4xKS8WLmBEJ43v3Pocha5f020dftgH0D+sV3V8C 7Rn33gPrf5Ff/klGcvEUOkCRRalKI72CAN7c8AkPlNwWb4OhIQboSNRHF1jHm8Kb mifIsECKudk8cKbKkiRuP9Eaq+nfZp/WswvmPboRuMdTLuT4vwGUTXzL7If8XDb6 a2a3Mc4Mr5unYVJLG3lS+VkozjQOVjjDwy8FuiZg/To/bsmZ5s+vURwHH8EGkUFN N3jdeIXCa76iNNKuVPHF =Ku0Y -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
CVE-2014-3575:OpenOffice Targeted Data Exposure Using Crafted OLE Objects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 CVE-2014-3575 OpenOffice Targeted Data Exposure Using Crafted OLE Objects Severity: Important Vendor: The Apache Software Foundation Versions Affected: Apache OpenOffice 4.1.0 and older on Windows. OpenOffice.org versions are also affected. Description: The exposure exploits the way OLE previews are generated to embed arbitrary file data into a specially crafted document when it is opened. Data exposure is possible if the updated document is distributed to other parties. Mitigation: Apache OpenOffice users are advised to upgrade to Apache OpenOffice 4.1.1. Users who are unable to upgrade immediately should be cautious when they are asked to Update Links for untrusted documents. Credits: The Apache OpenOffice security team credits Open-Xchange for reporting this flaw. Herbert Dürr Member of the Apache OpenOffice Security Team -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (Cygwin) iQIcBAEBAgAGBQJT9e3wAAoJEDfnuKc+PLjJC8gP/2ZLgMRO9r2YyAbEWl6iA1gP eVtq6I6O5W9a0ov1zGpbBaPVqZGMCGPDgsdTBUmm2FRAY0U0Yz0bflpGcSUdIpJ/ ULMp6TLfgb24PpiySOQHRvz/6QDsTTgkEyKClkM3THzvNXh6mSCExaDsDv8fseaJ y1tvTRHrHLeG+lZKPwDnIvDYDSONYNksK/e7gcF5rjNZpmcl6F4gZmMcm1j1TP1a HbsgOzMpC+A0X26VfuDapYBT6mjeITS6+ZReAcD3sPul95UK/BQ6qU29dvDY7uYg 7U9vzr2155uyv9qUx0UqE2XRKIHfUEhhxHZqFtTVlllkv34E1PNNYdhzUUYDuo4w W4+GhrebUaArIeQNd1KLCgvnQ0O6ykegV/Rc+OIgG/8DOyC18SS3r11nLs0L0pDe WmBfOii2OaS/d0RrOdHFsNpscSL1dRaGOXLDD5lxm2VPp6D3TgCM9UgNnBzF4u3S 4lKid1JlxswFbOOT0hNrX7V/kwx9Z2DfDzw8EmjLZGmiH1W3u99EZxmIlKZQRwrg 3enbMuSADsrWSjnxxmwlJD6iT0AaBEJ30doxqnfftIbNt4+r45fSPRPWYriQZ00j 7a+CrKLfBS9ctuXChldWGtgbh4Pkq3RxsVhAw7aiIQdII53v8086A/jzVU0zYNN8 AUxJRYsI1SGTlytbeP0o =2Y3B -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [VOTE]: Release Apache OpenOffice 4.1.1 (RC3)
+1, release revision 1617669 as Apache OpenOffice 4.1.1. I checked the Linux build, the source release vs. the repository, the source signature and checksums. Also the German Linux binaries work fine. On 15.08.2014 09:15, Jürgen Schmidt wrote: Hi all, this is a call for vote on releasing the available release candidate (RC3) as Apache OpenOffice 4.1.1. Apache OpenOffice 4.1.1 is mainly a bugfix release with some important bugfixes. And we can provide again more complete UI translations and have now support for 41 languages. New languages for this release compared to 4.1.0 are Catalan, Catalan (Valencia AVL) and Catalan (Valencia RACV). Apache OpenOffice 4.1.1 is the continuation of high quality software releases. An overview of the integrated release issues can be found under: http://ci.apache.org/projects/openoffice/milestones/4.1.1-rc3-r1617669/AOO4.1.1_fixes.html The release candidate artifacts (source release, as well as binary releases for 41 languages) and further information how to verify and review Apache OpenOffice 4.1.1 can be found on the following wiki page: https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds (alternative directly via http://ci.apache.org/projects/openoffice/milestones/4.1.1-rc3-r1617669) *.dmg files are still not recognized as binaries and have to be saved manually (save link as ...). The RC is based on the release branch AOO410, revision 1617669! And a fresh and clean RAT scan output of this revision can be found under http://ci.apache.org/projects/openoffice/milestones/4.1.1-rc3-r1617669/AOO4.1.1_RAT_Scan.html Please vote on releasing this package as Apache OpenOffice 4.1.1 The vote starts now and will be open until: Tuesday, 19 August: 2014-08-19 12:00am UTC+2. We invite all people to vote (non binding) on this RC. We would like to provide a release that is supported by the majority of our project members. [x] +1 Release this package as Apache OpenOffice 4.1.1 [ ] 0 Don't care [ ] -1 Do not release this package because... Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Where are AOO 4.1.1 daily binaries for Windows?
On 10.07.2014 17:16, Herbert Duerr wrote: On 10.07.2014 08:56, Regina Henschel wrote: Herbert Duerr schrieb: [...] There was a problem on the win-nightly buildbot. It updated the source to the latest trunk instead to the latest revision of the branch it was requested to checkout. This should be fixed now and the next nightly will get the AOO410 source. Now is an error in the path to the source :( Working with that bot feels like remote-controlling a car on Pluto... the turnaround times are high and there are a lot of dark corners. Anyway with a bit of luck the next nightly build will produce the desired install set. The new recipe worked and the nightly Windows builds of our release branch (on the way to AOO 4.1.1) are now available at the regular location of our nightly Windows builds [1]. [1] http://ci.apache.org/projects/openoffice/install/win/ Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Where are AOO 4.1.1 daily binaries for Windows?
On 10.07.2014 08:56, Regina Henschel wrote: Herbert Duerr schrieb: [...] There was a problem on the win-nightly buildbot. It updated the source to the latest trunk instead to the latest revision of the branch it was requested to checkout. This should be fixed now and the next nightly will get the AOO410 source. Now is an error in the path to the source :( Working with that bot feels like remote-controlling a car on Pluto... the turnaround times are high and there are a lot of dark corners. Anyway with a bit of luck the next nightly build will produce the desired install set. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Where are AOO 4.1.1 daily binaries for Windows?
On 09.07.2014 12:05, Regina Henschel wrote: [...] Build Source Stamp: [branch openoffice/branches/AOO410] HEAD ---^ But I do not find the binaries. On http://ci.apache.org/projects/openoffice/install/win/ I see a Apache_OpenOffice_4.2.0_Win_x86_install_en-US_1608755.exe and its 'version.ini' too says, that it is a 4.2.0. There was a problem on the win-nightly buildbot. It updated the source to the latest trunk instead to the latest revision of the branch it was requested to checkout. This should be fixed now and the next nightly will get the AOO410 source. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: build break in sw = two nightly builds now switched to the release branch
On 07.07.2014 08:53, Regina Henschel wrote: seems I have been faster ;) Commit done. r1608348 Thanks! I took the liberty to merge the fix into the release branch where the same problem was introduced and is solved now. This event showed that a more regular check of our release branch is needed. I temporarily switched the Linux32 and the Windows nightly builds to our release branch for AOO 4.1.1. Till the release this switch should help our QA efforts and the more regular monitoring of the branch will also detect build problems faster. The changes are already active, but the next nightly builds will only be available starting tomorrow at about this time. Regina Henschel schrieb: Hi, the current trunks breaks in sw because of missing includes #include vcl/pdfextoutdevdata.hxx #include svtools/filter.hxx in trunk\main\sw\source\core\doc\notxtfrm.cxx [...] Thanks for finding it! The problem was probably introduced because the fix was developed on a platform where building with precompiled headers was enabled, which hid the problem. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: EXTERNAL: Re: NSS Module
On 26.06.2014 02:32, Steele, Raymond wrote: Where is the build output located? It is emitted to stdout unless you used the --html option in your build command. To capture stdout either redirect it with e.g. build --all -P2 stdout.log -- -P2 or use a pipe and the tee command build --all -P2 -- -P2 | tee stdout.log to capture it and watch the progress at the same time. I have NSS on my system, but the --with-system-nss flag is not an option. If I use --with-system-libs, wouldn't that enable system-libs for all software? I'm no expert on AOO's configure system but as far as I know the option --with-system-libs should only enable the system libs where development headers and libraries are available on the build system. There is still the question on whether the system-nss is being used: The makefile output (NSS is not being built because...) would be one important piece of information containing the relevant environment variables ENABLE_NSS_MODULE and SYSTEM_NSS. The environment variables are of course also visible in the... environment once you sourced the platform specific file mentioned by the configure script. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: NSS Module
Hi Raymond, On 23.06.2014 18:42, Steele, Raymond wrote: After running the configure, the ENABLE_NSS_MODULE environment variable is set to yes, but for some reason NSS is not built. The build fails in xmlsecurity because the NSS libraries were not built and copied over to solver. I have to manually run dmake on NSS then copy them to the lib directory in solver. Any ideas why? Looking into main/nss/makefile.mk the logic on whether the builtin nss is built is right there: If nss is disabled or if the system-provided nss is selected, then the builtin nss will not be built. In that case there would be an info: NSS will not be built because... I guess this was the case. Please search the build output for this line. The system provided nss is preferred over the builtin nss if you configured with --with-system-nss or --with-system-libs. Please check whether any of these configure options were active. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Question ad encoding of unoinfo java return string value
On 17.06.2014 21:10, Rony G. Flatscher (Apache) wrote: According to some older infos about the encoding returned by unoinfo[.exe] java the resulting string starts with an indicator byte, where '0' indicates an ASCII encoding (and the paths are delimited with '\0'), whereas '1' indicates UTF-16LE (and the paths are delimited with \0\0). On German Windows (AOO 4.1) I see the encoding '1' (UTF-16LE), but the characters are not 16-bit (UTF-16LE) encoded, but plain ASCII, however the paths get delimited with \0\0. OOo (e.g. 3.4.1) would return encoding '1' (UTF-16LE) where each ASCII character is preceded by '\0'. Clearly, an installation routine dealing with the returned string value of AOO gets confused, if it was written with UTF-16LE in mind, working correctly on earlier OOo. I had a quick look at the problem. This is indeed a behavior change. There was a suspicious line in the responsible code. When I cleaned it up (#i125115#) on trunk the output is fine again. Is this something for our bugfix release? Please lobby for it if see it that way and when you verified the fix. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: EXTERNAL: Re: Macro Security Button
Hi Raymond, On 12.06.2014 17:39, Steele, Raymond wrote: I am just trying to set ENABLE_NSS_MODULE=YES.I thought enabling category-b would do this, but that does not seem to be the case. How does one go about enabling the security macros button? I thought it was by enabling NSS and category-b, but that does not seem to work. I could manually force it , or change the configure script, but that does not seem to be the correct solution. According to main/configure.in line 330 the nss module is enabled by default. It gets disabled though in line 1422 of the same file unless category-b licensed code is explicitly enabled. This is so for policy reasons, see [1] for details. So if you enabled category-b licensed code and didn't disable nss, then nss should be enabled. If this isn't so please check and eventually update your system's autoconf tool. If that doesn't help then enabling the ENABLE_NSS_MODULE option by force may be the fastest solution. [1] http://markmail.org/thread/erh6leykxwygio2k Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: cleaning up our sourceforge top-level directory
On 27.05.2014 20:58, Marcus (OOo) wrote: Am 05/27/2014 05:46 PM, schrieb Kay Schenk: We still allow for downloads of legacy OOo, so it would probably be better to move the older versions to something like our current structure -- your second option above? +1 And, should the older packages, if it applies only to 3.3, also have its own area? Maybe someone still wants/needs these. Then they should look for them in the ASF archive. This should be the only location for very old release builds. The ASF archive does not contain older OOo builds such as 3.2.1 or 3.3. These artifacts were not released under the ASF umbrella so they are neither archived in http://archive.apache.org/dist/incubator/ooo/ nor in http://archive.apache.org/dist/openoffice/ Ancient OOo releases are still available in the archive mirror network though. Please see http://www.openoffice.org/download/archive.html for links. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Tracking bugs like Issue 124985 - [Meta] Meta Bug for collecting bugs which appeal for AOO 4.1.x
Hi Rainer, On 26.05.2014 20:13, Rainer Bielefeld wrote: It's an essential that information should be consistent at any place for Bugzilla. +1 Here an overview concerning priority /severity of the issues listed in the meta-issue; ! Critical major normaltrivial ! Total ---!-!-- P1 !1 . . . ! 1 P2 !. . . 1 ! 1 P3 !. 4 5 . ! 9 ---!-!-- Tot!1 4 5 1 ! 11 Regressions are also an important consideration. So my question is why Issue 114361 with severity trivial has been considered by godlike decision (there is no reasoning, neither in Issue 124985 nor in Issue 114361) so serious that it has been added added to the meta bug? With some minimum carefulness the severity would have been rised to major or more, the dataloss keyword would have been added, so that the decision will be comprehensible. I did that now in Issue 114361 A higher severity was very much warranted for this data loss. Data loss sounds a bit like an abstract concept but in this case it was I had a perfectly fine presentation, saved it and some pics are gone!!!. So the meta-issue helped to identify that this important issue was not properly flagged and would have been overlooked if we had only used the query as suggested. +1 for the meta-issue then. Common known characteristics of unresolved Issue 124985 blocking Bug reports you find in Report [1] (More than 3400). So the question is why have 11 been picked as blocker for the meta issue, but more of 3400 not [2]? For the references [1], [2] or [3] in your mail I cannot find their actual links, but I think I know what you mean. As said the meta-issue is only intended as a publicly visible reminder and best-effort overview what should eventually get into an eventual bugfix release if we decide whether we'll need one. The meta-issue helps with this discussion. +1 for the meta-issue. Whether they really should get into an eventual bugfix release would be decided later by requesting the blocker flag. I'd say good criteria for such issues are: - regressions - crashes - data losses * risk of new regressions So even if a bug is only minor; if it is a regression, a fix is available and low risk it should get into a bugfix release. Such a bug would not be caught by a query for major issues, but IMHO they are great candidates anyway. Should we decide that our bugfix releases must only contain fixes for bugs with major severity then this is fine as well. The bugs below this level would be removed from nomination. I'd advise against ignoring such fixes though. With some minimum corrections for the criteria of possible Meta bug blockers I can reduce the number by 90% [3] [...] Such systematic working is the only way for real progress. This systematic work is very important indeed and I appreciate and have the deepest respect for our QA volunteer who work on it. If after some work we have valid data in the bug reports Meta Bugs indeed can be useful to show up dependencies and relations what are not simply visible in the bug reports. For anything else queries like https://issues.apache.org/ooo/buglist.cgi?cmdtype=runnamedlist_id=149854namedcmd=Potential411Blockers (shared with registered users) are much more powerful, especially in projects with bigger community than AOO and much bug tracker activity (20 reports per day, not only 2). I'm logged in and have all the rights needed but I can't see that query. On the other hand the meta-issue is visible to everyone without any trouble... Best regards, Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [Lazy Consensus] link to a german forum
On 26.05.2014 23:08, Andrea Pescetti wrote: Hagar Delest wrote: I agree, we should add the link on the landing page (which has still an old logo BTW). Adding something like (3rd party) would be fine. OK. So can someone tell us the best way to write Third party forums in German in German? Unabhängige befreundete deutsch-sprachige Foren would be a good translation IMHO. It means Friendly but independent German-speaking forums. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
cleaning up our sourceforge top-level directory
I just noticed that many people seem to download AOO directly from sourceforge and that the directory structure obviously misleads them to download obsolete binaries. Here is the top-level layout and its weekly download count: 4.1.0:843,483 weekly downloads localized: 25,891 weekly downloads 4.0.1: 24,410 weekly downloads 4.0.0: 3,731 weekly downloads stable 1,800 weekly downloads extended 558 weekly downloads contrib41 weekly downloads milestones:31 weekly downloads packages6 weekly downloads The localized and stable folders only provide the old 3.2.x, 3.3.0 and 3.4.x releases, so getting more than 28000 weekly downloads there is an alarming signal. The packages folder contains old OpenOffice.org 3.3.0 releases for SolarisX86, SolarisSparc, MacPPC and for languages that are not yet supported by AOO such as Maithili or Konkani. The extended folder contains ISO-images with several builds of OOo321 and OOo330. The contrib folder contains old dictionaries. They are not directly usable and the newest one is from 2009. So the current layout is apparently confusing and misleads a lot of people to download stuff they wouldn't use if they knew that better alternatives are available. I don't want to spend much time one this but I'd like to clean up the localized, stable, extended, contrib and packages top-level directories by either - removing them altogether - recreate a 3.4.1 folder and remove the others - recreate a 3.4.1 and an old-OOo folder and remove the others Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Tracking bugs like Issue 124985 - [Meta] Meta Bug for collecting bugs which appeal for AOO 4.1.x
On 26.05.2014 13:14, Rainer Bielefeld wrote: my experience is that such tracking bugs are not useful. The time invested in adding dependencies (what is rather uncertain, who can know how many bugs are missing and on what facts the various contributors added the bugs to the Meta) should be invested (with much more benefit) into careful review of the related BZ bugs and completion of information in the BZ bugs. I disagree that they are useless. As long as we're not sure if or when we should do a 4.1.1 and what changes could get into it such a meta-issue gives an easy overview of the candidates and their status: https://issues.apache.org/ooo/showdependencytree.cgi?id=124985hide_resolved=0 If we decide to make a bugfix release then the appropriate milestone target and its release-blocker flag will be created. Once the issue candidates have been reviewed and their bug fields (target and blocker) have been adjusted only then the meta-bug becomes irrelevant. But up to that point it is a good tracking mechanism with global visibility, clear accountability of who suggested what and direct links to the candidate issues. I recommend not to create tracking bugs what can be replaced easily by queries and if there is no evidence that they are necessary for the bug fixing process. And if there is a decision that the tracking bug should be created please follow [...] https://issues.apache.org/ooo/buglist.cgi?bug_severity=blockerbug_severity=criticalbug_severity=majorbug_status=UNCONFIRMEDbug_status=CONFIRMEDbug_status=ACCEPTEDbug_status=REOPENEDf3=OPf4=versionf5=versionf6=CPf8=cf_bug_typej3=ORlist_id=149754o4=regexpo5=regexpo8=equalspriority=P1priority=P2query_format=advancedv4=^4.1v5=^4.2v8=DEFECT Currently this query just yields bug 124891 which indeed looks like a good candidate. I suggest to FUP this discussion on the q...@openoffice.apache.org list. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: buildbot success in ASF Buildbot on openoffice-linux64-nightly
On 16.05.2014 11:10, Herbert Duerr wrote: On 15.05.2014 07:54, Ariel Constenla-Haile wrote: On Tue, Apr 15, 2014 at 08:42:12AM +, build...@apache.org wrote: Hi! , The openoffice-linux64-nightly builder has just completed a run STATUS: Success [...] This last mail was from a month ago, aren't the build bots sending this notification any longer? [...] So the main suspect is AOO's custom messageFormatter. Maybe it throws an exception that is internally caught by the buildbot software? Since we don't have access (AFAIK) to the buildbot's stderr output we have to guess. In revision 908989 I disabled our custom messageFormatter for now. Let's see how if we can narrow down the problem in this way. So my hypothesis that the custom message formatter caused the problem was apparently correct: The messages are now sent again after I (temporarily?) changed the mail notifier configuration to use the default message formatter. The difference can be seen in [1] (default) and [2] (custom). The default formatter produces a quite good message so that I suggest to keep it as is. Fixing the original problem when access to stderr or the bbot's internal log isn't available isn't worth the trouble. [1] http://mail-archives.apache.org/mod_mbox/openoffice-commits/201404.mbox/%3C20140401083733.90BA5C015E%40aegis.apache.org%3E [2] http://mail-archives.apache.org/mod_mbox/openoffice-commits/201405.mbox/%3c201405170844.s4h8ivoy084...@aegis.apache.org%3E Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: buildbot success in ASF Buildbot on openoffice-linux64-nightly
On 15.05.2014 07:54, Ariel Constenla-Haile wrote: On Tue, Apr 15, 2014 at 08:42:12AM +, build...@apache.org wrote: Hi! , The openoffice-linux64-nightly builder has just completed a run STATUS: Success [...] This last mail was from a month ago, aren't the build bots sending this notification any longer? There were no changes in the openoffice buildbot script at that time, but it seems the buildbot instance was updated from 0.8.6 to 0.8.8. And the cms-build notifications were moved to another file, but that was a while later. Other asf-buildbot projects use a similiar MailNotifier setup and their mailing works fine. The only major differences between them us and them are that they don't use the messageFormatter option and they set the MailNotifier mode to change instead of AOO's all. So the main suspect is AOO's custom messageFormatter. Maybe it throws an exception that is internally caught by the buildbot software? Since we don't have access (AFAIK) to the buildbot's stderr output we have to guess. In revision 908989 I disabled our custom messageFormatter for now. Let's see how if we can narrow down the problem in this way. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [ANN] Apache OpenOffice 4.1.0 released
On 30.04.2014 00:15, Marcus (OOo) wrote: Am 04/29/2014 02:15 PM, schrieb Rory O'Farrell: Announced on en-Forum. BTW: Time to create a 4.1.0 value for the Version field in BZ. Good point. I disabled the 4.1.0-Beta and 4.1.0-dev versions, disabled the 4.1.0 target milestone, added a 4.2.0-dev version, also created a new 4.2.0 target and disabled the 4.1.0-release-blocker flag. If we decide to pursue a 4.1.1 version too then that target can be added too. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [VOTE]: Release Apache OpenOffice 4.1.0 (RC4)
On 28.04.2014 17:23, Andrea Pescetti wrote: On 25/04/2014 Jürgen Schmidt wrote: this is a call for vote on releasing the available release candidate (RC4) as Apache OpenOffice 4.1.0. +1 Release this package as Apache OpenOffice 4.1.0 +1 for releasing this package as AOO 4.1.0 also from me after building the source package from scratch, checking the source code signature, checking the repository revision vs. the source tarball, checking the built and downloaded binaries on Mac and Linux/AMD64, running tests, reviewing the RAT output, etc. Sorry for the mis-threading of my vote, but due to a problem [1] with the Apache mail server acting as a spam relay it was blacklisted by a couple of Email providers, so the original vote invitation mail never reached my inbox. Getting into the voting thread is now only possible by replying to another mail of the voting thread. [1] https://issues.apache.org/jira/browse/INFRA-7594 Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [DISCUSS]: Digital signing of documents and macros
A small update on that topic: there is a simple workaround! Signing also works on Mac and Linux if the environment variable MOZILLA_CERTIFICATE_FOLDER is set to the currently active mozilla/thunderbird/firefox/etc. profile. E.g. on Linux setting the environment variable could look like MOZILLA_CERTIFICATE_FOLDER=sql:/home/xxx/.mozilla/firefox/23d7j.default and on Mac it could look like MOZILLA_CERTIFICATE_FOLDER=sql:/Users/xxx/Library/Application Support/Firefox/Profiles/23d7j.default Herbert On 17.04.2014 11:55, Jürgen Schmidt wrote: Hi, we currently have an issue with digital signing on non Windows platforms. The whole problem was introduced with the drop of some very old Mozilla stuff that made always problems. Feature description (simplified) Digital signing of document and/or macros is a feature to increase the integrity in a workflow where documents are exchanged and to build a trusted environment. 1. document signatures With a valid certificate it is possible to sign a document after it is saved. It is comparable with a seal. Other users loading this document will see a signature icon in the status bar that shows that this document is signed. Double click on this icon opens a dialog where the user can view the certificate. Two status are possible, the first one is that the certificate can be validated and is marked as trusted. The second (identified with the same icon + a yellow triangle warning sign) is where the certificate can't be validated automatically. 2. macro signatures Similar to documents the user can sign macros in the same way. When a user load a document with signed macros a dialog is opened to enable macros or not. In this dialog the user get also information that the macro is signed and is able to view the certificate. It is also possible to trust this certificate always and the next time the macro is accepted automatically. Problem This functionality was tightly coupled to Mozilla and made use of the Mozilla certificate store. At least on Linux and MacOS where as on Windows system certificate store was used directly. Current situation is that it still works on Windows but is partly broken on Linux and MacOS. Signing of new document or macros is not possible at all because no certificate store is available or better accessible. Signed documents can be loaded but the cert can't be validated. Signed macros can be loaded/enabled and executed. It is also possible to add an exception to trust this cert always to prevent the macro dialog in the future. General This feature heavily depends on the Mozilla certificate store which seems to be not optimal. For example on Mac the user would have to install Mozilla to make use of this feature. Standard browser for most users is Safari. A further observation is why I can't accept a cert for document signatures but for macro signatures. For example if I know where it comes from and know that it is a self signed cert why I can't trust this cert. Solution idea Rely on the system certificate store where possible similar to Windows, means on MacOS connect to the Keychain. On Linux it is still unclear to me how it can work. Maybe managing an own cert store and use openssl to access system resources to validate certificates. Or access via openssl an existing cert store for the user/system. I am no expert here and many open questions that have to be answered. Opinions and especially expert knowledge from an implementation perspective are highly appreciated and welcome. Juergen - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: EXTERNAL: Re: Extension Manager Add Crashes
On 16.04.2014 01:16, Steele, Raymond wrote: Why do you mention the Solaris Sparc UNO C++ bridge below. Is it related to the x86/intel bridge. I am running Solaris 11 x86_64. Ah, ok. Looking at the directory main/bridges/source/cpp_uno there is no UNO bridge yet for Solaris Studio on a x86-64 CPU. But apparently your compile got through, so in order to know where to tweak you need to find out which bridge was actually used. Then you can adapt it to your platform (operating system, compiler, cpu architecture, ABI). As I mentioned the platform independence of AOO's UNO subsystem was unfortunately not designed in e.g. by using plain programming language constructs or using portable mechanisms like C-linking. Getting a bridge to work was accomplished by brute force :-/ (reverse engineering the vtable layouts, symbol mangling, calling conventions, implementation details of exception handling, etc.) but if we're lucky a few tweaks to the currently active bridge could suffice. For an idea on what tweaks might be needed please check the evolution of the related x86-64 bridges for Linux, FreeBSD or MacOSX. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: CMS Build Down?
On 16.04.2014 15:26, Rob Weir wrote: On Tue, Apr 15, 2014 at 11:55 PM, Samer Mansour samer...@gmail.com wrote: Yes, I got the e-mail from infra a few days ago and did it ( https://id.apache.org/). I was logged in to the CMS when I made the commits, not in anonymous mode. So I just tried the CMS and I'm getting an error message when trying to View Staging Build It goes to http://ci.apache.org/builders/ooo-site-site-staging and displays a Problem loading page error. aegis.apache.org, the server responsible for http://ci.apache.org is/was having problems for the last 20 hours. You can monitor its status at http://monitoring.apache.org/status/ and try again when that server exits its CRITICAL condition. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: EXTERNAL: Re: Extension Manager Add Crashes
On 14.04.2014 17:59, Steele, Raymond wrote: Anyone available that understands the OpenOffice bridges or could point me to the correct documentation so that I can begin to understand the problem myself? This has been a road block for me. The OpenOffice bridges are part of the UNO framework. An overview [1] and FAQ [2] can help to get started into this topic. Especially see the FAQ's chapter 2.9 (Why is it so annoying to write a compiler version dependent C++ bridge?) on the deliberate design decisions that lead to this unfortunate fragility. There are other applications in the same league as OpenOffice that use their implementation languages plainly avoiding this extreme platform dependency. [1] https://wiki.openoffice.org/wiki/Uno/Article/Understanding_Uno [2] https://wiki.openoffice.org/wiki/Uno/FAQ [3] http://www.openoffice.org/udk/cpp/man/cpp_bridges.html [4] https://wiki.openoffice.org/w/images/5/5e/DevelopersGuide_OOo3.1.0_05AdvancedUNO.odt There is a good chance that the ABI hasn't much changed and that the different compiler versions produces similar enough code so that one could eventually get along with minor tweaks to the Solaris Sparc UNO C++ bridge. The links above hopefully help to find the knobs in main/bridges/source/cpp_uno/cc*solaris_sparc* source. The related tests in main/testtools/source/bridgetest can eventually help too. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Re issue 124599
On 04.04.2014 17:39, Andre Fischer wrote: On 04.04.2014 17:34, Andre Fischer wrote: On 04.04.2014 17:01, Andre Fischer wrote: Issue 124599 is the release blocker that requires a second RC. We have a bug fix, the patch is attached to the issue. Question is, how to proceed without Juergen to approve the release blocker flag? Does anybody else feel like a stand in for Juergen or should I just proceed? After all, if I stop his vote, I should probably fix the bug so that we/he can start the next vote. -Andre Herbert just reminded me that the upload speeds on the weekend are so much better then during the week. So I think that it would be good to check in the patch right now, start the builds and upload. Then we can decide on Monday how to proceed. -Andre New SVN revision is 1584753. New builds for this revision are being prepared and will hopefully finish uploading over the weekend. On Monday or latest on Tuesday everything should be ready again and we can decide then how to proceed. If things go as expected we could start a new vote early next week. Since the eventual RC2 will be very similar to the RC1 (with the exception of the installation experience on Windows) I recommend to use the extra time for further checking of the original binaries until the new builds become available. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [RELEASE]: propose AOO 4.1.0 RC
On 02.04.2014 17:12, imacat wrote: Traditional Chinese not found yet. Should I wait for a while? As Jürgen wrote, the Linux builds are still being uploaded. Languages starting with a-g are already available for 64bit Linux, other languages and 32bit Linux will follow in a couple of hours. What's most important and what the vote is about is the source revision. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Incubator still has SVN tree = to be removed in 72h
On 25.03.2014 12:50, Herbert Duerr wrote: [...] So if the next 72 hours indicate consensus on removing the incubator/ooo part of the repository I suggest that we should do so. The code history is already preserved in our git-import. Ok, the 72h period is up and we reached (lazy) consensus on it. The incubator/ooo tree has the read-only flag on though so it cannot be removed yet. If anyone has the karma to make it writable again please do so. Or remove the incubator/ooo part of the repository directly. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: AOO 4.1 Beta Survey Results
[...] Please describe the issue(s) you encountered. 1. [Mac OS 10.9.2 user] When I open old openoffice docs, it tells me that all fields cannot be opened, but it looks fine when it's opened. This was local problem of the machine that was used for creating the Beta 4.1 binaries for Mac. The problem has been analyzed [1] and the machine is fixed now so that the next builds will be clean. [1] https://issues.apache.org/ooo/show_bug.cgi?id=124426 Also, when I save a doc, it tells me that there is an error, that it didn't save it when in fact it really did save it. This had the same root cause as above [1]. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Incubator still has SVN tree = to be removed in 72h
On 24.03.2014 15:36, Herbert Duerr wrote: On 24.03.2014 15:13, sebb wrote: On 24 March 2014 13:51, Herbert Duerr h...@apache.org wrote: On 23.03.2014 09:52, Andrea Pescetti wrote: sebb wrote: There is still an SVN tree under Incubator: https://svn.apache.org/repos/asf/incubator/ooo/ I assume this was all transferred to the main ASF SVN area at https://svn.apache.org/repos/asf/openoffice/ If so, please can someone tidy up the Incubator tree? It was indeed all transferred, and the old copy made read-only by Infra. It wasn't deleted since we still had releases and documentation around that referred to the Incubator. There are still many e.g. Wiki pages that reference the incubator locations. I updated some of them but there are still plenty left, e.g. about the branch aw080, netbeans, OOXML, etc. I suggest to update them to their new location at https://svn.apache.org/repos/asf/openoffice For links that should continue to point into the incubator directory, e.g. because the branch was integrated and removed at the new location SVN offers the possibility to reference older branches using the https://svn.apache.org/repos/asf/!svn/bc/155/incubator/ooo/trunk/ notation. Although that should work, I think it could be confusing. IMO it would be better to find the appropriate entry in the new SVN layout. If there is no such entry, is there really a need to keep the reference to the incubator-only SVN tree? I mostly agree. For the pages that I already updated I was able to change all references to their new repository location. But for sub-project specific pages the status is not always obvious which alternative would be most suitable: - update them to their new repository location - keep the link into the incubator location - are the pages are still relevant or could/should they be deleted. AFAIK it is not easy to resurrect deleted Wiki pages, so doing that on still somewhat interesting pages would be a net loss. The best solution would be to check the problematic pages and their links. So if anyone has more insight into their status please update them: A quick google search found pages about the object inspector extension, the netbeans extension, the aw080 branch, OOXML, etc. A closer examination showed that the problematic links had counterparts in the post-graduation repository location and the text around these links didn't indicate a special dependency, so I'm confident that it was OK to update them, which I just did. So if the next 72 hours indicate consensus on removing the incubator/ooo part of the repository I suggest that we should do so. The code history is already preserved in our git-import. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Incubator still has SVN tree = to be removed in 72h
On 25.03.2014 13:00, Rob Weir wrote: On Tue, Mar 25, 2014 at 7:50 AM, Herbert Duerr h...@apache.org wrote: [...] So if the next 72 hours indicate consensus on removing the incubator/ooo part of the repository I suggest that we should do so. The code history is already preserved in our git-import. The only issue would be if anyone is doing LTS on 3.40 or 3.4.1, right? Didn't those versions go back to SVN to pick up the binary dependencies? All tags (including AOO340 and AOO341) and the AOO34x release branch are also available at the post-graduation location [1][2][3], so this use case should be covered. [1] http://svn.apache.org/repos/asf/openoffice/tags/AOO340 [2] http://svn.apache.org/repos/asf/openoffice/tags/AOO341 [3] http://svn.apache.org/repos/asf/openoffice/branches/AOO34/ Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Be careful before the release
We're on a good way to a healthy AOO 4.1 release so we should avoid the pitfalls that prevented a timely AOO 4.1 Beta release. Let's examine this negative example a bit further, so we can all learn from it: A commit [1] stopped the Beta and forced the only respin that was needed despite the massive changes+improvements that went into the code base. [1] http://svn.apache.org/r1547732 The commit broke the installation of language packs and this breakage wasn't discussed before. The responsible developer sneaked that train-wreck in with a mega-patch under a non-suspicious comment. I don't remember him discussing the breakage of language packs before and that the creation of patches could negatively influences the usability of the language packs wasn't discussed either. Of course one could say It happens, but since that developer gets VERY annoying if It happens to anyone else the same casual attitude would be inappropriate. What's worse is that the commit comment [2] for unbreaking the language packs was Wrong initialization of . which is completely unusable. It didn't even mention language packs. That they were broken and now they are fixed. And what's that '.' Is this some magic hyper-linked dot? We should better use commit messages that can stand on their own. [2] http://svn.apache.org/r1573613 So in short: Be careful, be professional, don't do unto others what you wouldn't want them do unto you, and yes It happens and we have to deal with it. Positively if possible that is. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Incubator still has SVN tree
On 24.03.2014 15:13, sebb wrote: On 24 March 2014 13:51, Herbert Duerr h...@apache.org wrote: On 23.03.2014 09:52, Andrea Pescetti wrote: sebb wrote: There is still an SVN tree under Incubator: https://svn.apache.org/repos/asf/incubator/ooo/ I assume this was all transferred to the main ASF SVN area at https://svn.apache.org/repos/asf/openoffice/ If so, please can someone tidy up the Incubator tree? It was indeed all transferred, and the old copy made read-only by Infra. It wasn't deleted since we still had releases and documentation around that referred to the Incubator. There are still many e.g. Wiki pages that reference the incubator locations. I updated some of them but there are still plenty left, e.g. about the branch aw080, netbeans, OOXML, etc. I suggest to update them to their new location at https://svn.apache.org/repos/asf/openoffice For links that should continue to point into the incubator directory, e.g. because the branch was integrated and removed at the new location SVN offers the possibility to reference older branches using the https://svn.apache.org/repos/asf/!svn/bc/155/incubator/ooo/trunk/ notation. Although that should work, I think it could be confusing. IMO it would be better to find the appropriate entry in the new SVN layout. If there is no such entry, is there really a need to keep the reference to the incubator-only SVN tree? I mostly agree. For the pages that I already updated I was able to change all references to their new repository location. But for sub-project specific pages the status is not always obvious which alternative would be most suitable: - update them to their new repository location - keep the link into the incubator location - are the pages are still relevant or could/should they be deleted. AFAIK it is not easy to resurrect deleted Wiki pages, so doing that on still somewhat interesting pages would be a net loss. The best solution would be to check the problematic pages and their links. So if anyone has more insight into their status please update them: A quick google search found pages about the object inspector extension, the netbeans extension, the aw080 branch, OOXML, etc. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Fwd: [jira] [Resolved] (INFRA-7463) Customization for the OpenOffice bugzilla
For your info: The bugzilla improvements regarding field descriptions we discussed in the mailing list thread [Bug 124386] Improve Help for Version Selector are active now; many thanks to Mark Thomas. Herbert Original Message Subject: [jira] [Resolved] (INFRA-7463) Customization for the OpenOffice bugzilla Date: Tue, 18 Mar 2014 09:36:44 + (UTC) From: Mark Thomas (JIRA) j...@apache.org To: h...@apache.org [ https://issues.apache.org/jira/browse/INFRA-7463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas resolved INFRA-7463. Resolution: Fixed Patch applied. Bugzilla restarted. Customization for the OpenOffice bugzilla - Key: INFRA-7463 URL: https://issues.apache.org/jira/browse/INFRA-7463 Project: Infrastructure Issue Type: Wish Components: Infra Wishlist Reporter: Herbert Duerr Attachments: bugzilla.patch The field descriptions for issues in bugzilla are apparently not clear enough, so the OpenOffice project discussed some enhancement ideas on its development mailing list. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [Bug 124386] Improve Help for Version Selector
On 18.03.2014 14:54, Ariel Constenla-Haile wrote: On Tue, Mar 11, 2014 at 12:05:31PM +0100, Herbert Duerr wrote: Since many entries in our bugzilla database are not about bugs, but about new features or enhancements I'd also like to use the term issue instead of bug, when Bugzilla refers to such an entry. Isn't it possible to use both? The recent change turns all bug XXX into simple text, for example https://issues.apache.org/ooo/show_bug.cgi?id=124366#c1 used to have a link in See bug 119006 for more information. As far as I know we'd need to use a bugzilla hook for a more generic auto-linkification. The current changes only changed text templates. Writing the hook seems not too difficult [1] but we haven't gotten around to it. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=364254 Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [Bug 124386] Improve Help for Version Selector
On 11.03.2014 23:16, Andrea Pescetti wrote: Herbert Duerr wrote: I'd also like to use the term issue instead of bug, when Bugzilla refers to such an entry. I agree with the proposed changes in general, and it would be nice if Bugzilla still added automatic hyperlinks to issue 123456 when used in a comment (I believe it wasn't working any longer - it worked only for the bug 123456 pattern - some time ago; haven't checked recently). I'd like that too. But unfortunately this auto-linkification [1] isn't directly configurable. We'd need to write a hook for it [2]. [1] http://www.bugzilla.org/docs/2.20/html/hintsandtips.html [2] https://bugzilla.mozilla.org/show_bug.cgi?id=364254 But we'll need to provide such a hook a least when we switch to git because autolinks from bugzilla into the repository are very valuable IMHO. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
[Bug 124386] Improve Help for Version Selector
Members of our QA team requested a clarification of the Version field
used in our bugzilla instance. There are other terms that could need
some clarification too.
So before I request ASF-Infra to change our bugzilla installation by
using the patch [1], I'd like to ask for lazy consensus to request this
change in our bugzilla installation.
[1] https://issues.apache.org/ooo/attachment.cgi?id=82837action=diff
In particular the help text for version should be changed from
The version field defines the version of the software the bug was
found in.
to
The oldest version of the software the bug can be found in.,
Also the help text for assigned to should be changed from
The person in charge of resolving the ${terms.bug}.
to
The person in charge of progressing the ${terms.bug}.
because we sometimes need more info, specific testing, etc. from others.
The help text for operating system should be changed from
The operating system the $terms.bug was observed on.
to
The operating systems the $terms.bug can be observed on.
because AOO problems are often impacting multiple platforms.
Since many entries in our bugzilla database are not about bugs, but
about new features or enhancements I'd also like to use the term issue
instead of bug, when Bugzilla refers to such an entry.
Herbert
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [Ticket#2014031010001921] Referenzkunde
Dear Tilman, many thanks for your very motivating feedback on our project and for volunteering as reference customer. I added you to the list of german reference customer with the detail you provided: http://svn.apache.org/viewvc/openoffice/ooo-site/trunk/content/de/marketing/referenzkunden.html?r1=1575939r2=1575938pathrev=1575939 --- Sehr geehrter Herr Klosa, herzlichen Dank für Ihre sehr motivierende Nachricht und für die Bereitschaft, als Referenzkunde aufgenommen zu werden. Ich habe Ihre Daten in die Liste der deutschen Referenzkunden eingetragen. Mit freundlichen Grüßen, Herbert Dürr On 10.03.2014 10:24, Tilmann Klosa wrote: Sehr geehrtere Damen und Herren wir benutzen seit 2009 OpenOffice und sind extrem zufrieden was den Support und die Leistungen angeht. OpenOffice beweist dass Open Source Projekte Sinn haben. Deswegen würde ich gerne die SEO-Küche als Referenzkunde auf ihrer Seite eintragen lassen: [1]http://www.openoffice.org/de/marketing/referenzkunden.html Unsere Daten: SEO Küche Internet Marketing GmbH Co. KG Fraunhoferstr 6, 83059 Kolbermoor Ansprechpartner: Carsten Schumann (i...@seo-kueche.de) Bemerkung: Wir nutzen OpenOffice seit 2009 auf dem Mac und sind extrem zufrieden was die Nutzerfreundlichkeit und die Stabilität von openoffice.org angeht. Auch die extrem stabile PDF-Konvertierung überzeugt! [2]http://www.seo-kueche.de/ Über eine positive Rückmeldung würde ich mich freuen und verbleibe mit schönen Grüßen aus Kolbermoor Tilmann Klosa Linkbuilding Für Fragen stehe ich Ihnen gerne unter der Rufnummer +49 (8031) 58084-35 zur Verfügung. -- SEO-Küche Internet Marketing GmbH Co.KG Fraunhoferstraße 6 83059 Kolbermoor Telefon: 0800 / 473288-33 Telefax: 0800 / 473288-34 E-Mail: i...@seo-kueche.de Internet: [3]http://www.seo-kueche.de Social-Media: Facebook: [4]http://facebook.com/seokueche Twitter: [5]http://twitter.com/seokueche Google+: [6]https://plus.google.com/106126403235350875952/ Geschäftsführer: Marco Frazzetta, Oliver Lindner Register: Amtsgericht Traunstein, HRA 11167 Umsatzsteuer-Identifikationsnummer gemäß § 27 a Umsatzsteuergesetz: DE286985708 -- [1] http://www.openoffice.org/de/marketing/referenzkunden.html [2] http://www.seo-kueche.de/ [3] http://www.seo-kueche.de [4] http://facebook.com/seokueche [5] http://twitter.com/seokueche [6] https://plus.google.com/106126403235350875952/ - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [VOTE]: Release Apache OpenOffice 4.1.0 Beta (RC)
On 06.03.2014 09:55, Jürgen Schmidt wrote: Hi all, this is a call for vote on releasing the available release candidate (RC) as Apache OpenOffice 4.1.0 Beta. The Beta release is intended to reach more early adopters and to receive more valuable feedback to improve potentially critical areas for the final release. [...] Please vote on releasing this package as Apache OpenOffice 4.1.0 Beta The vote starts now and will be open until: Sunday evening, 9 March: 2014-03-09 11:00pm UTC. But we invite all people to vote (non binding) on this RC. We would like to provide a release that is supported by the majority of our project members. [ ] +1 Release this package as Apache OpenOffice 4.1.0 Beta [ ] 0 Don't care [ ] -1 Do not release this package because... I checked the RAT-scan, the source-bz2-tarball, the NOTICE file, the source signature, the build of the source tarball on a platform, some convenience binary tarballs, their checksums and signatures, etc. All looks fine, so +1 for releasing revision 1573601 as AOO 410 beta. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Compiler warnings
On 05.03.2014 09:30, Andre Fischer wrote: I am currently working on some bug in the sc module and find that it is really hard to even find compiler errors among the many warning messages. Some of these warnings are caused directly by code in sc but the majority of the warnings originate in header files. Platform is Windows. The most annoying warnings are warning C4530: C++ exception handler used, but unwind semantics are not enabled. Specify /EHsc and even more (because of the warning text that is repeated again and again) warning C4555: expression has no effect; expected expression with side-effect The problem is in MSVC2008's list header. They probably fixed that in their newer versions. Another reason to update our build environment on that platform to something newer. The warning expression has no effect itself is interesting enough, just not in in list header. Fortunately terms like list(1137) can be filtered out easily. Any ideas how to silence these two? We could disable such warnings altogether by adding e.g. the -wd4555 option to CFLAGSWARNCXX in main/solenv/inc/wntmsci11.mk and main/solenv/gbuild/platform/windows.mk re C4530: One option would be to compile all sc code with exceptions enabled. That sounds reasonable. Does anyone know of a reason not to do that? Not that I'm aware of. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Compiler warnings
On 05.03.2014 10:28, Andre Fischer wrote: On 05.03.2014 10:01, Herbert Duerr wrote: The warning expression has no effect itself is interesting enough, just not in in list header. Fortunately terms like list(1137) can be filtered out easily. Please explain how that can be filtered out easily. e.g. by piping the output through the command perl -ne 'print if not /^.*list.1137/../^\S/' It removes all list.1137 lines and their indented followup lines. Unfortunately also one more line but perl experts can probably fix that easily. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Compiler warnings
On 05.03.2014 11:45, Andre Fischer wrote: On 05.03.2014 11:28, Herbert Duerr wrote: On 05.03.2014 10:28, Andre Fischer wrote: On 05.03.2014 10:01, Herbert Duerr wrote: The warning expression has no effect itself is interesting enough, just not in in list header. Fortunately terms like list(1137) can be filtered out easily. Please explain how that can be filtered out easily. e.g. by piping the output through the command perl -ne 'print if not /^.*list.1137/../^\S/' It removes all list.1137 lines and their indented followup lines. Unfortunately also one more line but perl experts can probably fix that easily. Of course, on the command line this is easy, but I am building inside emacs. Any idea how to do it there? As I don't use emacs I had to rely on my googling skills instead and found [1] that looks relevant. Does it help? [1] http://stackoverflow.com/questions/206806/filtering-text-through-a-shell-command-in-emacs Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Fwd: Reporting a problem with the OpenOffice Calc
Forwarding to our localization list. On 04.03.2014 09:50, Karol Łotocki wrote: jest: WI*LE*KIE LITERY powinno być: WI*EL*KIE LITERY Pozdrawiam, Karol Apparently the polish translation of the term uppercase has a typo that changes the meaning. The relevant pootle entry seems to be [1]. [1] https://translate.apache.org/pl/aoo40/translate/officecfg/registry/data/org/openoffice/Office/UI.po#filter=allunit=15560157 Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [RELEASE]: first Beta RC ...
On 03.03.2014 13:45, jan i wrote: Do we get ratscan log before the vote ? It already ran [1] and reported [2] no problems. [1] http://ci.apache.org/builders/openoffice-linux64-rat/builds/97 [2] http://ci.apache.org/projects/openoffice/rat-output.html Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [RELEASE]: first Beta RC ...
On 03.03.2014 18:15, Kay Schenk wrote: Will 32 bit Linux rpm be available any time soon? The sneak preview is already there [1], but because of the language-pack showstopper AOO410-beta-rc needs another round. [1] http://ci.apache.org/projects/openoffice/milestones/4.1.0-beta/binaries/en-US/Apache_OpenOffice_Beta_4.1.0_Linux_x86_install-rpm_en-US.tar.gz Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
[Bug 119006][Bug 123681] Restore windows problem on Mac OS X
Since the OSX windows restore problem is very popular in our forums, our mailing lists and in bugzilla I'd like to advertise my fix for that (rev 1571205) and invite testers. A build of the latest trunk with the fix is available at [1]. [1] http://people.apache.org/~hdu/AOO_Mac64_Test.dmg Herbert (who doesn't like features that break working apps) - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [RELEASE]: New snapshot is ready
On 17.02.2014 20:37, Marcus (OOo) wrote: Am 02/17/2014 02:43 PM, schrieb Herbert Duerr: The development snapshot Wiki page is updated too, but due to server problems it is currently inaccessible. Just curious. How to update a Wiki page when the Wiki server is down? By updating it before it went down ;-) Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Any news on a new build of 64-bit MacOSX AOO 4.1 (either dayly/developer or snapshot build) ?
Hi Rony, On 11.02.2014 14:47, Rony G. Flatscher (Apache) wrote: On 11.02.2014 10:45, Oliver-Rainer Wittmann wrote: On 11.02.2014 09:55, Herbert Duerr wrote: [...] There are hints from other users that the crash after a while may have to do with the update service having problems. Does the problem persist when you disable the automatic update check? (OpenOffice-Preferences-OpenOffice-OnlineUpdate-CheckAutomatically) Actually, it does not show anymore! :( Even removed all installed components (AOO, ScriptProvider.oxt), reinstalled AOO alone, then with the ScriptProvider.oxt to no avail. Thats good news and bad news :-) However, I still have yesterdays DiagnosticReports which I can make available (at least I can see three different crashes, soffice with a SIGSEGV (linked to the Java awt event thread problem), soffice with a SIGABRT, and a unopkg with a SIGABRT. Altogether I have eleven crash files created with the 64-bit version that you have made kindly available yesterday. Please advise, whether you want all crash files from yesterday and where to put them (issue, make it downloadable, send it as an attachment?)! If you have webspace somewhere then making them available there would be a good start, especially since these seem to be different problems. Or: - Does the crash occur when you check manually (Menu Help - Check for Updates...) for a new AOO version? No crash. - Does the crash occur when you check manually (Menu Tools - Extension Manager - Check for Updates? No crash, but a popup-error dialog with the title OpenOffice 4.1.0 and the message Error reading data from the Internet. Server error message.. After pressing the o.k. button, this is followed by another error popup OpenOffice 4.1.0 with the message http://www.rexxla.org/updates/ScriptProviderForooRexx.update.xml does not exist., pressing o.k. yields one error popup after another for each URL that does not exist, e.g. http://sourceforge.net/projects/bsf4oorexx/files/ScriptProviderForooRexx.update.html;. Removing the ScriptProvider extension (not all of its URLs are valid currently), rerunning the Extension Manager - Check for Updates yields no updates and does not yield a crash. This check for an extension update with bad URLs is the prime suspect for the crash-after-two-minutes. If you are using time machine then checking the difference between the current and the older versions of the ScriptProviderForooRexx extension might be interesting. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Any news on a new build of 64-bit MacOSX AOO 4.1 (either dayly/developer or snapshot build) ?
On 11.02.2014 15:23, Rony G. Flatscher (Apache) wrote: On 11.02.2014 15:07, Herbert Duerr wrote: Please advise, whether you want all crash files from yesterday and where to put them (issue, make it downloadable, send it as an attachment?)! If you have webspace somewhere then making them available there would be a good start, especially since these seem to be different problems. Uploaded all of them as a zip-file (including the .*plist) to http://wi.wu.ac.at/rgf/tmp/aoo/20140211/. Thanks! It shows that the update-check problem is caused by an unexpected exception of type com::sun::star::ucb::InteractiveNetworkReadException 10 __cxa_call_unexpected + 129 11 libucbhelper4s5abi.dylib ucbhelper::cancelCommandExecution 12 libucpdav1.dylib http_dav_ucp::Content::open 13 libucpdav1.dylib http_dav_ucp::Content::execute 14 libucpdav1.dylib http_dav_ucp::Content::execute 15 updatefeed.uno.dylib 16 updatefeed.uno.dylib 17 updatefeed.uno.dylib 18 updchk.uno.dylib checkForUpdates If you had a way to reproduce this I'd give you debug versions of these libraries so the stack would be more precise. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: a mistake in drawingml.hxx?
On 10.02.2014 11:08, shzh zhao wrote: in oox\inc\oox\export\drawingml.hxx there is a line like #include svx/escherex.hxx if you search 'escherex.hxx' ,you can find it in filter/inc/filter/msfilter. Yes, it was moved from svx to filter in October 2009 with issue 106421. can anyone fix this bug in the code base? I guess this problem shows up now has to do with you working on enabling this export type. Is there an issue-id for that already? I'd like to use it for committing the header-include fix. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Any news on a new build of 64-bit MacOSX AOO 4.1 (either dayly/developer or snapshot build) ?
Hi Rony, On 10.02.2014 11:51, Rony G. Flatscher (Apache) wrote: is there anywhere a new build of the 64-bit MacOSX AOO 4.1 available (beyond rev. 1560772)? No matter whether it is a (daily?) developer or an official snapshot. I just uploaded my last dev-build [1]. [1] http://people.apache.org/~hdu/AOO_nightly20140209.dmg We're planning to do a new milestone build soon. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Any news on a new build of 64-bit MacOSX AOO 4.1 (either dayly/developer or snapshot build) ?
Hi Rony, On 10.02.2014 21:14, Rony G. Flatscher (Apache) wrote: A few remarks using yesterday's build: - If letting AOO 4.1 hang around with swriter (doing nothing), after approx. two minutes AOO crashes: do you need the DiagnosticReport file in case you cannot duplicate this? Yes please. There are hints from other users that the crash after a while may have to do with the update service having problems. Does the problem persist when you disable the automatic update check? (OpenOffice-Preferences-OpenOffice-OnlineUpdate-CheckAutomatically) Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Solaris GCC or Sun Studio?
Hi Απόστολος, As far it regards Solaris,I have noticed that the building scripts of OpenOffice assume that one is building with Sun Studio. This compiler is a bit outdated and of course GCC is available for most platforms. Since LibreOffice has removed support for Sun Studio, I guess it would be a goof idea to remove support for Sun Studio. It adds complexity without reason. For example, I tried to compile a module and it failed just because it assumed that I was using Sun Studio. Some people are still using SunStudio for building OpenOffice. Please see the thread http://markmail.org/thread/5gnsk7hmehxfdthx for more details and the problems that result from this platform, but we shouldn't remove it yet. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: instsetoo_native need(s) to be rebuilt...
Hi Apostolos, On 01.02.2014 14:43, Απόστολος Συρόπουλος wrote: I have compiled all OpenOffice modules and now building stops as follows: ERROR: ERROR: unopkg sync --verbose -env:UNO_JAVA_JFW_ENV_JREHOME=true 21 | failed! in function: register_extensions [...] I have no idea what is wrong and moreover where should I look to find the problem. Any ideas and/or suggestions would be really apprecieted! This might also be a re-occurrence of a missing library or symbol. This can hopefully be caught by my patch suggested in http://markmail.org/message/lcctwzqrinjgwa7e by enable it also for non-debug mode until this is solved. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
FreeBSD patches (was: New SNAPSHOT available (based on r1560772))
Hi Maho, On 02/05/2014 05:24 AM, Nakata Maho wrote: Questions: 1. subject says 1560772 but https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds says 1560773. Which is correct? Strictly speaking the new SNAPSHOT tag was created in r1560773. It tagged the revision 1560772. The latest change in the trunk that was relevant for these were in revision 1560760. The ASF subversion repository shares all the projects and branches, so if you are checking out our trunk with any of the revision between the last trunk-change and the creation of its tag (i.e. 1560760..1560773) then you'll get exactly same sources. If you checked out the tag directly then the latest SNAPSHOT revision 1560773..1564650 will do, as the tag wasn't moved inbetween this revision range. 2. Approve for FreeBSD patches a. http://svnweb.freebsd.org/ports/head/editors/openoffice-devel/files/patch-webdav?revision=342617view=markup The headers from ext_libraries/apr are delivered to main/solver/410/*/inc/apr/ so the change of the include directory from apr to apr-1 wouldn't work for most of our platforms. Same for apr-util and serf. Is it possible to tweak the order of include paths for FreeBSD, so that the include statements could stay the same for all platforms? correct one is following. http://svnweb.freebsd.org/ports/head/editors/openoffice-devel/files/patch-webdav?revision=342631view=co I'm also not sure about this. Oliver is our expert on the Serf/Ucb integration. Oliver could you please have a look at the suggested patches above? b. http://svnweb.freebsd.org/ports/head/editors/openoffice-devel/files/patch-nss?revision=342426view=markup +1, looks good to me 3. Weired error in canvas due to sal. What do you think? cf. http://svnweb.freebsd.org/ports/head/editors/openoffice-devel/files/patch-sal?revision=342617view=markup /work/tinderbox-ligeti8amd64/portstrees/FreeBSD/ports/editors/openoffice-devel/work/aoo/main/solver/410/unxfbsdx.pro/inc/rtl/string.hxx:237:5: error: 'rtl::OString::operator const sal_Char*() const' is private /work/tinderbox-ligeti8amd64/portstrees/FreeBSD/ports/editors/openoffice-devel/work/aoo/main/canvas/source/cairo/cairo_textlayout.cxx:336:40: error: within this context /work/tinderbox-ligeti8amd64/portstrees/FreeBSD/ports/editors/openoffice-devel/work/aoo/main/canvas/source/cairo/cairo_textlayout.cxx: In member function 'bool cairocanvas::TextLayout::draw(cairo::SurfaceSharedPtr, OutputDevice, const Point, const com::sun::star::rendering::ViewState, const com::sun::star::rendering::RenderState) const': Thanks for finding this! These implicit conversions are dangerous, so better use the change from http://svn.apache.org/r1564650 instead. Thanks for working on this! Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory Fault
Hi Raymond, most regulars are traveling (and are meeting this weekend at FOSDEM in Brussels). I already recommended the try to find whether any exceptions are thrown (and caught away) during the steps you already debugged. In gdb I'd use the command catch throw to find the throwing code. Maybe there is similar facility in Solaris Studio? Herbert On 31.01.2014 20:27, Steele, Raymond wrote: Anyone out there? We really need to get this working, but are having a difficult time. From: Steele, Raymond Sent: Wednesday, January 29, 2014 5:11 PM To: dev@openoffice.apache.org; a...@openoffice.apache.org; Herbert Duerr (h...@apache.org) Cc: Meffe, David K Subject: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory Fault We've recently compiled OpenOffice 4.01 on Solaris 11 x86 and are experiencing the following at runtime. I've included some of the stack trace below. Any help would be great. Thanks! Observed Behaviour 1.OpenOffice starts, the splash screen with logo appears and then closes replaced with the full application window and choices for specific OpenOffice projects. 2.Selecting either the Word or Spreadsheet project causes a segmentation fault and closes the application. 3.Following the start of the application with the debugger, we can see the SidebarController is created in a first pass without error (known because first time to this stop point does not error). 4.As the process continues, the SidebarController constructor is called a second time (unknown why, but could be understood with more familiarity with the system). 5.The failure doesn't appear in the constructor, but the trace follows down SidebarController constructor call of WeakReferenceSidebarController WeakController (this); 6.This template definition for WeakController uses ReferenceTemplate::Refrence( interface_type *pInterface) as its definition in ::com::sun::star::uno::Reference.hxx. 7.The function will try to convert the pInterface parameter to a XInterface type called _pInterface. 8.If it succeeds in converting the pInterface to _pInterface then the function will try to acquire a new reference. 9.Assumption: Creating this new reference calls SidebarController::notifyContextChangeEvent with a corrupt or bad rEvent. This assumption is based on the stack where the immediate next routine after the Reference function call is the notifyContextChangeEvent, also while following along in the debugger, the rEvent parameter at this point is already corrupted with the value ERROR stored in the structure. 10. It is later after the notifyContextChangeEvent calls Context and then ustring that the segmentation fault occurs, but I believe the error located in rEvent is what causes this later problem. It appears as if inside the SidebarController Constructor at line 168 when xWeakController(this) is called that the problem first occurs. The xWeakController appears to be defined in Reference.hxx in /cppu/inc/com/sun/star/uno/ and this definition as an inline function that calls the _pInterface-acquire() at line 136. We assume that this acquire is where the problem occurs because the SidebarController::notifyContextChangeEvent (which is the next item on the stack) rEvent contains an ERROR value in the dbxtool (debug tool) immediately following in the stack. It eventually crashes downstream at line 103 of ustring.hxx in /sal/inc/rtl when the string is trying to be accessed as pData = str.pData; Stack Trace: (dbx) where current thread: t@1 =[1] rtl::OUString::OUString(this = 0xfeff9dac, str = CLASS), line 103 in ustring.hxx [2] sfx2::sidebar::Context::Context(this = 0xfeff9dac, rsApplication = CLASS, rsContext = CLASS), line 51 in Context.cxx [3] sfx2::sidebar::SidebarController::notifyContextChangeEvent(this = 0xebc6d6b0, rEvent = STRUCT), line 257 in SideBarController.cxx [4] com::sun::star::uno::Referencesfx2::sidebar::SidebarController::Reference(this = 0xfeff9f64, pInterface = 0xebc6d6b0), line 136 in Reference.hxx [5] sfx2::sidebar::SidebarController::SidebarController(this = 0xebc6d6b0, pParentWindow = 0x9659bf8, rxFrame = CLASS), line 168 in SidebarController.cxx I can provide more of the stack trace if needed. Thanks in Advance! Raymond - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Building on Mac
On 30.01.2014 09:40, Andre Fischer wrote: 1. Is it possible to build on OSX with only freely available tools (that don't require registration)? Apple's XCode development environment is available for free in either their app store or in their downloads for developers area. Apple requires a registrations for both. Since an Xcode download is a plain disk-image file that could be easily redistributed there might be alternative channels for them, but I'd strongly recommend to use the reliable and legal download locations from the original provider Apple. If there are direct download links at Apple that don't require registration then they are not well publicized. If anyone knows such a link please provide it. 2. Is there anybody with access to a Mac who is willing to extend the building guide to cover OSX? [2] and [3] describe in some detail how to build OpenOffice on Windows and Linux (in its Ubuntu flavor) but hardly a word on OSX. Once XCode is installed it's just the plain generic svn-checkout, configure and build steps documented in [1]. The good thing about XCode is that it provides all that's needed. 3. I remember that I also had to set up macports [4] for some frequently used shell commands (I think) but that is not mentioned anywhere in the building guide. Is it not needed anymore? I don't have macports or fink installed and can build just fine. All our build requirements are covered by Xcode. Of course these tool sets provide a lot of value, e.g. if anyone prefers to write his helper scripts in e.g. Lisp then macports is a good way to get a lisp interpreter for free. But our build doesn't require any of this. I think that it is not enough that it is theoretically possible to build OpenOffice on Mac OSX. It should also be documented in a public place so that everybody can do it. Get XCode 4.5 and install it. Do the generic AOO build [1]. [1] https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO By the way, I'm working on enabling an AOO build with newer XCode versions, that no longer provide a 10.7 SDK. I'd suggest to not give up so easily. If a download requires a registration then annoying as it may be, it is nothing a reasonably experienced developer cannot handle. Even Mac newbies often manage to get things from the App Store. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: New SNAPSHOT available (based on r1560772)
On 28.01.2014 18:35, Andrea Pescetti wrote: On 27/01/2014 Herbert Duerr wrote: [2] http://people.apache.org/~hdu/developer-snapshots/snapshot/ I see that filenames look like Apache_OpenOffice_4.1.0_Linux_x86-64_install-rpm_it.tar.gz Shouldn't they have a m1 or some other identifier that identifies them as not final? Yes, I'd prefer that too. But up to now all such snapshots were named as like that (equal to the target version) and there wasn't too much confusion. We'll have a similar situation when we get to vote on the next release candidates. They HAVE to be named like the final version, even if they are only release candidates and may fail the vote. Temporarily renaming the release candidate install packages to contain rcN and naming them back to their final name might work. All the checksum and signature files have to be updated too then. I also suggest to rename the macos part of Mac packages to OSX (or osx). The name Mac OS [1] was dropped since Mac OS X and Mac OS X lost the Mac part since 10.7 (a.k.a. Lion). I thing that avoiding a space character between OS and X, because spaces in installation packages cause more trouble than adhering 100% to Apple's naming scheme. [1] http://en.wikipedia.org/wiki/Mac_OS [2] http://en.wikipedia.org/wiki/OSX I suggest to move this page into our MediaWiki instead where generated markup can be directly used. As you wish. No problem for me, of course. Actually, considering the audience, your link [2] above is just fine. I believe testers will be able to find what they need. Yes. The Wiki update is still in progress, Andre is working on a script to automate it for MediaWiki. Thanks to Kay's note about the enabled Html-Extension in the Confluence Wiki we could keep it there too though. This needs some more minor adjustments to the new script. I also suggest to use a different name for these kinds of snapshots, because the buildbots provide a different of snapshot [5] that are not built for maximum compatibility. How about renaming the release-like snapshots to milestone? Milestone is OK for me. And with an e.g. m1 marker we could say the 'm' is for milestone. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: 64bit Mac crashs often after start
Hi Raphael, On 01/29/2014 08:07 AM, Raphael Bircher wrote: I recognise that the OSX 4.0.1 often crachs after start. It is not realy reproducible, but I have the feeling that there is something wrong. I just whant to let you know, so we can keep a eye on this. System: 10.9 Mavericks. I will try to get more information about this behavior The Mac crash reporter will have some interesting details about this. Please copy and paste such a report into a text document and attach it to a new issue. I also suggest to experiment with enabling/disabling extensions, the update checker and with the java settings. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
New SNAPSHOT available (based on r1560772)
New snapshot builds based on the feature freeze revision (according to the release plan [1]) are available at [2]. [1] https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.1+Release+Planning [2] http://people.apache.org/~hdu/developer-snapshots/snapshot/ The development-snapshot CWiki page [3] has been partially updated, but since Markup was disabled [4] in the latest Confluence update the process of updating this page has become incredibly painful and will take some more time. [3] https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds [4] http://blogs.atlassian.com/2011/11/why-we-removed-wiki-markup-editor-in-confluence-4/ I suggest to move this page into our MediaWiki instead where generated markup can be directly used. I also suggest to use a different name for these kinds of snapshots, because the buildbots provide a different of snapshot [5] that are not built for maximum compatibility. How about renaming the release-like snapshots to milestone? [5] http://ci.apache.org/projects/openoffice/#linsnap Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Compilinng the gcc_solaris_intel bridge
Hi Apostolos, On 27.01.2014 17:04, Απόστολος Συρόπουλος wrote: After a number of efforts I have finally managed to find the proper patch for file bridges/source/cpp_uno/gcc3_solaris_intel/uno2cpp.cxx and so to build a functional bridge for Solaris. Previously, I could not build the testtools module but now they compile just fine. Congratulations on solving this last critical step! Here is the patch: [...] --- bridges/source/cpp_uno/gcc3_solaris_intel/uno2cpp.cxx.oldΔευ Ιαν 27 17:38:53 2014 +++ bridges/source/cpp_uno/gcc3_solaris_intel/uno2cpp.cxxΔευ Ιαν 27 17:34:30 2014 [...] + // preserve potential 128bit stack alignment +and $0xfff0, %%esp\n\t +mov %0, %%eax\n\t +lea -4(,%%eax,4), %%eax\n\t +and $0xf, %%eax\n\t +sub $0xc, %%eax\n\t +add %%eax, %%esp\n\t // copy values mov %0, %%eax\n\t mov %%eax, %%edx\n\t This looks very much like the change for issue 108371, which means that the patch is licensed properly for our project. Of course the patch is just a copy of the corresponding Linux patch, but I was not sure whether it work! I'm glad you tried it out! Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Patch from r1554051 reverted
On 01/26/2014 10:41 AM, Andrea Pescetti wrote: A massive commit from Herbert from a couple days ago http://svn.apache.org/r1560747 overrides (reverts) a short configure.in patch I had applied on 29 December: http://svn.apache.org/r1554051 I assume this was not intentional (simply, the small patch was probably invisible in the large commit set), so I'm going to apply it again. +1, sorry about that. But first I'd like to check that it was not reverted for other reasons. Just let me know. The accident happened when a merge conflict was wrongly resolved. Thanks for finding the problem. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: unoinfo-bug in latest MacOSX snapshot still present (Re: [RELEASE]: snapshot build for Mac and Windows based on revision
On 22.01.2014 20:17, Rony G. Flatscher (Apache) wrote: Just downloaded the latest snapshot build for MacOSX (en-us, rev. 1556251) and found that the unoinfo-bug reported in https://issues.apache.org/ooo/show_bug.cgi?id=123475 is still present, preventing Java programs using uninfo java for setting the classpath to be able to interact with AOO. As the issue might not be too visible, yet the bug inhibits effectively Java from using AOO when using unoinfo it seems that it should be fixed, before a final release for 4.1.0. Fixed with [1] that will get into the next snapshot build, that will be out really soon. Please test it then. [1] http://svn.apache.org/r1560615 Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Problem with Java on the 64bit Mac OSX?
Hi Raphael, On 20.01.2014 13:35, Raphael Bircher wrote: I just started to test the 64 bit version of Mac OS X AOO. The Letter Wizard don't work at all. can someone confirm that? Fixed with [1] that will get into the next snapshot build, which will be out really soon (including 64bit Mac). Please re-test it then. [1] http://svn.apache.org/r1560617 Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Install error on nightly Windows build (r1560073)
Hi Rob, On 22.01.2014 17:29, Rob Weir wrote: Installing on a clean Windows 7 64-bit image. I get an error when configuring Microsoft Visual C++ 2008 Redistributable Error 1935 An error occured during the installation of assembly 'policy.9.0.Microsoft.VC90.CRT,version=9.0.30729.6161 HRESULT:0x800736B3 Anyone else seeing this? Apparently, as there is a knowledgebase article for that [1]. They recommend to run a tool [2] to fix it. [1] http://support.microsoft.com/kb/970652 [2] http://support.microsoft.com/default.aspx?scid=kb;EN-US;946414 Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Install error on nightly Windows build (r1560073)
Hi Rob, On 22.01.2014 17:56, Rob Weir wrote: On Wed, Jan 22, 2014 at 11:39 AM, Herbert Duerr h...@apache.org wrote: [...] Apparently, as there is a knowledgebase article for that [1]. They recommend to run a tool [2] to fix it. This is odd, since this is a fresh VM image of Windows 7, with no other applications ever installed. Only Windowsand Windows updates. So it would be odd for there to be registry corruption. Unless it came from Windows updates... Bingo! The knowledge base article mentions that An unsuccessful install of prior Windows Updates OR Custom MSI packages could have left over faulty registry keys under HKEY_LOCAL_MACHINE\COMPONENTS. So the Windows updates probably caused the problem. It's hard to believe, but even Windows has bugs ;-) Do you know if we used the same version of the MSVCRT package with 4.0.1? The deliver log [1] of the nightly build showed that everything seemed normal. [1] http://ci.apache.org/projects/openoffice/buildlogs/win/main/external/wntmsci12.pro/misc/logs/external_deliver.txt Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Compiling solver in cygwin references missing include folder
On 21.01.2014 01:28, Greg Bullock wrote: I'm trying to set up my Windows 7 + cygwin + VSPro2008 system to build the aoo trunk, with the hope of making some modest contributions to the project. The build -all stage gets some ways into the task then gives the following error message (quoted with some preceding lines for context): It is build --all, but looking at your log you already ran the right command. [...] Can someone advise how to work around this? Do I need to somehow specify an STL path in the configure ... step? Or do I need to give a path to the boost library? Or did I miss a warning somewhere? My compiler resides at /cygdrive/c/Program Files (x86)/Microsoft Visual Studio 9.0/VC/bin, and the folder /cygdrive/c/Program Files (x86)/Microsoft Visual Studio 9.0/VC/include has its own hash_set file, but no unordered_set file. Does your MSVC2008 have the service pack [1]? If not then please get SP1 from [2] and install it. [1] http://blogs.msdn.com/b/vcblog/archive/2008/08/11/tr1-fixes-in-vc9-sp1.aspx [2] http://www.microsoft.com/en-us/download/details.aspx?id=10986 Happy to supply any additional information that may help. Hope that helps. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: EXTERNAL: Re: Building comphelper
Hi David, I just wanted to share the basics of what I have found so far. I still have no idea on how to solve the issue. Any help would be great! Observed Behaviour 1. OpenOffice starts, the splash screen with logo appears and then closes replaced with the full application window and choices for specific OpenOffice projects. 2. Selecting either the Word or Spreadsheet project causes a segmentation fault and closes the application. 3. Following the start of the application with the debugger, we can see the SidebarController is created in a first pass without error (known because first time to this stop point does not error). 4. As the process continues, the SidebarController constructor is called a second time (unknown why, but could be understood with more familiarity with the system). 5. The failure doesn't appear in the constructor, but the trace follows down SidebarController constructor call of WeakReferenceSidebarController WeakController (this); 6. This template definition for WeakController uses ReferenceTemplate::Refrence( interface_type *pInterface) as its definition in ::com::sun::star::uno::Reference.hxx. 7. The function will try to convert the pInterface parameter to a XInterface type called _pInterface. 8. If it succeeds in converting the pInterface to _pInterface then the function will try to acquire a new reference. 9. Assumption: Creating this new reference calls SidebarController::notifyContextChangeEvent with a corrupt or bad rEvent. This assumption is based on the stack where the immediate next routine after the Reference function call is the notifyContextChangeEvent, also while following along in the debugger, the rEvent parameter at this point is already corrupted with the value ERROR stored in the structure. 10. It is later after the notifyContextChangeEvent calls Context and then ustring that the segmentation fault occurs, but I believe the error located in rEvent is what causes this later problem. I haven't fully caught up with everything, but if I had to debug this I'd watch out for exceptions thrown in step 5 and later. In gdb I'd use the command catch throw to find the throwing code. Is there a similar facility in Solaris Studio? Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: EXTERNAL: Re: Building comphelper
On 09.01.2014 16:47, Steele, Raymond wrote: We found a work around for this problem, but believe it may be implemented incorrectly. We added the following to the top of fmtatr2.cxx: #ifndef _RWSTD_NO_MEMBER_TEMPLATES #define _RWSTD_NO_MEMBER_TEMPLATES 1 #endif A good find! And indeed [1] also ran into such a problem and defining that to disable templatized version of std::vectorT::assign() was a workaround needed by the SunStudio compiler. http://trac.osgeo.org/geos/ticket/224 The compile of sw then began compiling correctly. Any thoughts? I'd say that all such defines that make boost less aggressive in using advanced template magic are fine, so don't worry about it. But I'd use such an option consistently then, not only in one file. I suggest to add a -D_RWSTD_NO_MEMBER_TEMPLATES=1 into the solaris makefiles in solenv. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: EXTERNAL: Re: Building comphelper
On 09.01.2014 22:48, Steele, Raymond wrote: Attached is a copy of the stack trace when we tried to launch both the Word Processor and the Spreadsheet application in OpenOffice. We are going to attempt to resolve the crash based on this information, but if anything pops out at you, please let us know. The crashes in Writer and Calc you are seeing both happen when copy constructing an OUString from one provided by the SidebarController, so the provided string must be bad. I suggest to set a breakpoint at SidebarController.cxx:257 and examine the rEvent.ApplicationName and rEvent.ContextName whether these are good strings. From the stack I'd say they probably are not. Then go up the stack and check where they come from and why their are bad. Good luck! (I'll be away next week, starting this weekend) Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Build Fails In Module Coinmp
On 09.01.2014 17:39, Tyler Kavanaugh wrote: I was able to start the build using Herbert's suggestion, and everything seemed to be going well all the way until the build system tried to build the modules coinmp, python, and sal. At that point, it failed. I've got a build log I can submit, if anyone wants to see it. I also tried building the individual module sal, by running: build --from sal -P2 -- -P2 and ended up getting some sort of undefined symbol error coming from the STL headers, as far as I could tell. Are you building AOO 4.0.x or trunk? On what platform? If you are building AOO 4.0.x you have to use the --without-stlport configure option. On trunk this is automatically enabled. The relevant excerpt from the build log are essential for solving the problem. I personally am away for the next couple of days though, but maybe someone else can figure out what went wrong. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Interesting interoperability problem with formatting of date
On 10.01.2014 17:12, Jürgen Schmidt wrote: I received a xls document with some date values, date related functions and formatting and noticed an interesting interoperability problem. For example: Cell Value FormatVisible Value A1 01/01/2014 MM/DD/YY 01/01/2014 A2 =DAY(A1) DD31 Excel shows the value 1 and the user expected the same value in OpenOffice but we show 31. The reason can be explained by looking in the help of the DAY function in Excel and OpenOffice (see below) The problem is the different reference date and counting. The serial number 1 in Excel is 01/01/1900. In OpenOffice we count from 0 and serial number 1 in AOO is related to 12/31/1899 because the reference date in AOO is 12/30/1899. FWIW the rationale behind the different reference date is given in [1]. Apparently the problem solved by using a different reference was that the year 1900 was not a leap year, because of the modulo-100 rule. [1] https://issues.apache.org/ooo/show_bug.cgi?id=26125#c2 If cell A2 would be formatted as number everything would be fine. But formatted as date it takes the integer value 1 as offset to our reference date, means 12/30/1899 + 1 day = 12/31/1899 = 31. Weighing the benefits of the workaround mentioned above with interoperability problems or the problem Jürgen just described, my scale would tip for a reference date (== day 0) of Dec 31, 1899. So this means it is wrong or better misleading by design. I am not sure if this can be fixed or should be fixed. Any opinions? If there is a way to change our reference day without losing backwards compatibility for existing documents then we should go for it. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: EXTERNAL: Re: Building comphelper
Hi Raymond,
Hi David,
On 07.01.2014 23:11, Steele, Raymond wrote:
Raymond and I remain stuck on the last issue that we wrote to you about. We
would like to better encapsulate our problem and see if you might be able to
provide more clarification on what we might be able to try.
1.We have performed a directory clean and restarted the build --all
process from the beginning with the debug flag set. This time we are not
using the multi-processing commands.
2.The build process proceeds without error, even compiling all the files
up to the svx module.
3.When the svx module is finished compiling and the LNK of the
Library/libsvxcore.so is being performed the process stops with an Undefined
symbol linking error.
4.The symbol is ParagraphDataParagraphData::operator(const
ParagraphData) and it used to complain about this file in the e3dundo.o.
Wasn't it complaining about a missing ParagraphDataVector symbol originally?
5.Since the ParagraphData didn't appear in e3dundo neither did the
OutlinerParaObject, I was at a loss for this linking error, but there was an
#include editeng/outlobj.hxx. Since that is the location of
OutlinerParaObject, I have commented out that include to see what would
happen. The result is the system still compiled, but the linking failed
again, this time in another location.
6.The new location that we got the same Undefined symbol error link
message on was in the file sdrlinefillshadowtextattribute.o located in the
attribute directory. This time I was unable to find a #include
editeng/outlobj.hxx in either the header or source file. However
sdrlinefillshadowtextattribute includes sdrlinesshadowtextattribute.hxx which
includes sdrtextattribute.
7.sdrtextattribute was the first location we have found where the
OutlinerParaObject is used and the #include editeng/outlobj.hxx. Since we
had not found this object before (at least in the path that was failing),
this was the first thing that made some sense in this problem.
8.We have reviewed your last email, but are having a difficult time
understanding what you recommended. It appeared you were recommending we
modify the OutlinerParaObject constructor, but how? You wanted us to remove
the ParagraphDataVector parameter? Or did you want us to create a different
constructor? What would the constructor look like?
I was suggesting to add another constructor that didn't have the problem of
needing a ParagraphDataVector symbol. Does this patch work for you? Since this
makes svx binary incompatible with its original you need to do a build
--prepare --from svx when you apply it.
--- main/editeng/inc/editeng/outlobj.hxx
+++ main/editeng/inc/editeng/outlobj.hxx
@@ -46,10 +46,8 @@ private:
public:
// constructors/destructor
-OutlinerParaObject(
-const EditTextObject rEditTextObject,
-const ParagraphDataVector rParagraphDataVector =
ParagraphDataVector(),
-bool bIsEditDoc = true);
+OutlinerParaObject( const EditTextObject, const ParagraphDataVector,
bool bIsEditDoc = true);
+OutlinerParaObject( const EditTextObject);
OutlinerParaObject(const OutlinerParaObject rCandidate);
~OutlinerParaObject();
--- main/editeng/source/outliner/outlobj.cxx
+++ main/editeng/source/outliner/outlobj.cxx
@@ -98,6 +98,10 @@ OutlinerParaObject::OutlinerParaObject(const EditTextObject
rEditTextObject, co
{
}
+OutlinerParaObject::OutlinerParaObject( const EditTextObject)
+: mpImplOutlinerParaObject( new ImplOutlinerParaObject(
rEditTextObject.Clone(), ParagraphDataVector(), true))
+{}
+
OutlinerParaObject::OutlinerParaObject(const OutlinerParaObject rCandidate)
: mpImplOutlinerParaObject(rCandidate.mpImplOutlinerParaObject)
{
9.Also even after all of this, do you think that if we modify the
OutlinerParaObject that the rest of the svx will link correctly and that all
these errors we have seen from this problem resulted from an error in the
OutlinerParaObject and our compiler?
I sure hope so ;-)
Once again, thanks for all your help in advance.
You're welcome!
I hope you had a good holiday season. We look forward to hearing back from
you.
BTW: I'll also be away next week.
Herbert
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Problems at the Beginning of the Windows Build
On 01/09/2014 01:28 AM, Tyler Kavanaugh wrote: I've just finished configuring and bootstrapping the Windows build of OpenOffice (from the head revision on trunk). I changed to aoo/main/instsetoo_native, and ran: build -P2 -- -P2 Also use the --all option, so that all dependencies of this final module are processed first, i.e. run build --all -P2 -- -P2 [...] The first time I tried to do the build, about an hour or so ago, I got errors relating to the use of carriage return/newline (\r\n) pairs, with Perl complaining that '\r' wasn't a valid command. (Keep in mind that my initial checkout was done using TortoiseSVN and not Cygwin). So I clobbered the whole checkout, redid it with the Cygwin svn client, then reconfigured and bootstrapped again. I remembered to source the winenv.set.sh file--did that prior to the call to ./bootstrap. Apparently cygwin's Subversion and Tortoise use different defaults for files without a svn:eol-style property (or with svn:eol-style=native). Keeping files as they are checked in when that property hasn't been set seems to be the default for cygwin's svn. Can Tortoise be configured to behave similarly? Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Using system boost 1.54 (was Re: EXTERNAL: Re: Building comphelper)
On 01/08/2014 07:52 PM, Kay Schenk wrote: On Wed, Jan 8, 2014 at 2:32 AM, Herbert Duerr h...@apache.org wrote: [...] The config.hpp provided by boost must match with the rest of the library. At least that's what this header is intended for. yes...but if a developer is using a local boost, might they inadvertently include some config options that might not be compatible with OpenOffice's build process? This was my concern when I saw this. If the system boost version is new enough and its config.hpp matches to the rest of its headers then it should be possible to make AOO build with it. If there are platforms where the system boost's default configuration doesn't work for building AOO then AOO should be adapted for it. Patches for that situation should be integrated if they don't cause regressions for other platforms / the boost version AOO brings along. I ditched using my local boost_1.54, and things are going much much better. Not quite there yet but close. :} Yay! yes, got a good build! YAY! Indeed! :-) At this point, given the customized work you've done, we might think of warning folks against using their local boost versions -- at least put some notes in configure.in. Just a thought. We should add such a warning to about every system library that is not regularly enabled for building and testing. The release builds prefer the defaults, but for many libraries AOO's configure script allows the use of system provided alternatives: apache-commons, apr, apr-util, beanshell, boost, cairo, coinmp, cppunit, curl, db, dicts, expat, graphite, hsqldb, hunspell, hyphen, icu, jpeg, libtextcat, libtextcat-data, libwpd, libxml, libxslt, lucene, mdds, mysql, mysql-cppconn, mythes, nss, odbc-headers, openssl, poppler, python, redland, sane-header, saxon, serf, vigra, xrender-headers and zlib. Assuming that each of the above mentioned libraries have 4 to 12 different versions out in the wild this means that between 4^40 and 12^40 different configurations are possible, of which we build and test only very few (=4?) regularly. The configuration space is increased even more when we consider that there are many different kinds of compilers in different versions, also linkers etc. What would be the simplest approach to address this? Just adding a use the --with-system-X options only if you know that this works or if you enjoy debugging? Or should we hide them behind an --enable-expert-options configure switch which would be similar to the broad --enable-category-b option? Your analysis above is well-taken. And, dealing with configure options, which local configure options might be helpful, and which ones might be more challenging, is an interesting question. These are topics that should be discussed in a new thread, I think. +1 I have to admit that I'm not an expert on autoconf, so I don't know whether we can make options disappear for e.g. a non-expert mode. But at least a better grouping of these options should be possible. I know we all want developers to have a good experience and providing more clarification on how the configure options effect the outcome will certainly help. +1 again Even people who worked for many years with the OpenOffice code often don't really know the exact impact of each configure switch. Many use their tried and working configure scripts and almost never deviate from that. E.g. for each of --with-system-X switches it is very hard to answer how enabling it would impact the build and the result, especially when X is available in a couple of different versions and configurations. But this might be an interesting opportunity for volunteers? E.g. when trying to figure out the impact of the --with-system-hunspell switch one could install one hunspell version after the other on the different platforms, do a clean build with each of them and test the install set. The experience gained from these iterations could result in a much improved description of such a configuration switch, which would be very much appreciated by everyone. Thanks again for all your help with my build problems... You're welcome! Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: libuno_cppu failure
Hi Απόστολος, On 04.01.2014 19:41, Απόστολος Συρόπουλος wrote: Today I tried to investigate a little bit why uno fails, in particular why build --all:testtools fails in OpenSolaris. So I tried to rebuild some libraries with debugging information. I have used build debug=true dbglevel=2 to build libuno_cppu.so.3 and here is what I get: Compiling: cppu/unxsogi.pro/misc/uno_cppu_version.c Compiling: cppu/unxsogi.pro/misc/uno_purpenvhelpergcc3_version.c Making:libuno_cppu.so.3 ### OFFSET_OF(AlignSize_Impl, dDouble) = 4 instead of expected 8!!! /extra/sources/OpenOffice/aoo4/main/solenv/bin/checkdll.sh: line 60: 4017: Abort(coredump) dmake: Error code 1, while making '../unxsogi.pro/lib/libuno_cppu.so.3' ERROR: error 65280 occurred while making /extra/sources/OpenOffice/aoo4/main/cppu/util The following patch solves the problem: --- cppu/source/uno/data.cxx.oldΣαβ Ιαν 4 20:13:17 2014 +++ cppu/source/uno/data.cxxΣαβ Ιαν 4 20:13:10 2014 @@ -357,7 +357,7 @@ #if defined(INTEL) \ (defined(__GNUC__) (defined(LINUX) || defined(FREEBSD) || defined(OS2 )) || defined(MACOSX) \ -|| defined(__SUNPRO_CC) defined(SOLARIS)) +|| (defined(__SUNPRO_CC) || defined(__GNUC__)) defined(SOLARIS)) #define MAX_ALIGNMENT_4 #endif Great! As expected the source tree has zero support for Solaris and GCC (The Sun people did lousy job as far it regards GCC and Solaris). Well, building Solaris OOo with GCC was as interesting to the Sun people as Microsoft is in building their MSO with the Sunpro or the GCC compiler: Almost zero. Now, I rerun build --all:testtools and I get the following: [...] ### unexpected exception content! failed exception test failed oneway exception test failed exception occured: error: test failed! Ouch! None of the exception stuff works in your new build. That is a hard nut to crack... Can anybody help me proceed? You already had the UNO bridges and their tests working in your older builds. Do you have an idea, what might have caused this bad regression? Getting back to the old (working) behavior is the only reasonable thing to do. Debugging/Fixing UNO bridge is not much fun and doing it remotely with only an occassional mail here and there is almost impossible. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Issue of Key events being handled twice, impacting accessibility with loss of object focus
On 06.01.2014 16:32, V Stuart Foote wrote: The errant double handling of cursor key events is a problem for Accessibility support of assistive technologies where program focus is being shifted away from the active object; e.g. writer - selected text for formatting, calc - cell being formated, etc. Current issues in BZ: bug 122363 https://issues.apache.org/ooo/show_bug.cgi?id=122363 bug 123933 https://issues.apache.org/ooo/show_bug.cgi?id=123933 bug 123934 https://issues.apache.org/ooo/show_bug.cgi?id=123934 I had thought the issue was isolated to sidebar Gtk UI, but when Andre F. looked at it in May it was a broader issue. I don't think it ever got any further attention and has resurfaced during QA for 4.1.0. I don't know much about this topic but on some platforms I saw the compile warning below which might be relevant, especially since the GalleryControl is a part of the sidebar: main/svx/inc/GalleryControl.hxx: overloaded virtual function sal_Bool KeyInput( const KeyEvent rKEvt, Window* pWindow); hides the virtual function 'Window::KeyInput' virtual void KeyInput( const KeyEvent rKEvt ); of main/vcl/inc/vcl/window.hxx Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
