Re: [LINUX-BUILD] mingw32 error
On 09/20/2011 09:29 PM, Carl Marcum wrote: Hi all, I'm attempting a build on a fresh Fedora 15 x86-64 box using SVN version 1173422 I have installed the prerequisites listed on [1]. With a notable exception of using Oracle JDK 1.7.0. Running "autoconf" from the "main" directory I get this error: 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 I'm not sure why I would need mingw32 C++ if I have gcc c++. [1] http://wiki.services.openoffice.org/wiki/Fedora_Build_Instructions Thanks, Carl I did find something about it here [1]. How can you --disable-odk using autoconf? [1] http://wiki.services.openoffice.org/wiki/OpenSolaris_Build_Instructions/Configure_Errors#Error:_unowinreg.dll_not_found Thanks, Carl
[LINUX-BUILD] mingw32 error
Hi all, I'm attempting a build on a fresh Fedora 15 x86-64 box using SVN version 1173422 I have installed the prerequisites listed on [1]. With a notable exception of using Oracle JDK 1.7.0. Running "autoconf" from the "main" directory I get this error: 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 I'm not sure why I would need mingw32 C++ if I have gcc c++. [1] http://wiki.services.openoffice.org/wiki/Fedora_Build_Instructions Thanks, Carl
Re: Late introduction :={
No problem! Good to know you're hard at work helping our customers! Welcome to the list. On 09/20/2011 02:19 PM, floris v wrote: Hi, Apologies for posting earlier without properly introducing myself. I'm Peter Roelofsen, better known as floris v on the OOo forums, where I mostly answer Writer related questions. I'll occasionally answer posts in this mailing list when they're about something that I can cover, like confirming that OOo will or won't hang or crash on some action. Cheers, Peter -- MzK "There's something about the sound of a train that's very romantic and nostalgic and hopeful." -- Paul Simon
Late introduction :={
Hi, Apologies for posting earlier without properly introducing myself. I'm Peter Roelofsen, better known as floris v on the OOo forums, where I mostly answer Writer related questions. I'll occasionally answer posts in this mailing list when they're about something that I can cover, like confirming that OOo will or won't hang or crash on some action. Cheers, Peter
Re: Introduction and start working
Hi Oliver-Rainer! Am Dienstag, den 20.09.2011, 12:26 +0200 schrieb Oliver-Rainer Wittmann: > After same change acceptance in the last months I have got the > possibility to continue my engagement in OpenOffice, now under the > Apache Foundation, as an employee of IBM. I am aiming to be a valuable > contributor to this project. Hey, cool to know that you're here ... greetings to "a small town near Hamburg" :-) Cheers, Christoph
autoconf... same warnings?
Hi at all In the build today I first run autoconf. There I got same output wich I don't know to inteprate. Maybe sameone who has experience with autoconf take a look on it. Here is the output: automake: no `Makefile.am' found for any configure output server3:main server3$ autoconf configure.in:2077: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2591: _AC_COMPILE_IFELSE is expanded from... ../../lib/autoconf/general.m4:2607: AC_COMPILE_IFELSE is expanded from... ../../lib/m4sugar/m4sh.m4:606: AS_IF is expanded from... ../../lib/autoconf/general.m4:2032: AC_CACHE_VAL is expanded from... acinclude.m4:15: AX_FUNC_WHICH_GETSPNAM_R is expanded from... configure.in:2077: the top level Greetings Raphael -- My private Homepage: http://www.raphaelbircher.ch/
RE: automake insteed configure
+1 Also, depending on how one keeps releases in the SVN, the Build Instructions can copy-on-write and only need to be changed on the trunk when there is a change in what is happening on the trunk. All previous versions will still have theirs. They can also be in HTML, or there could also be an HTML version in the repo. This also puts the Build instructions in the ideal place for their QA, their being used to make a build of the current code, etc. Did I say I like it? +1 - Dennis -Original Message- From: Rob Weir [mailto:robw...@apache.org] Sent: Tuesday, September 20, 2011 11:41 To: ooo-dev@incubator.apache.org Subject: Re: automake insteed configure On Mon, Sep 19, 2011 at 6:00 AM, Raphael Bircher wrote: > Hi all > > In the past, configure was only rebuild if needed by samone (releng?) in > Hamburg. Now Mathias Bauer recommends to build configure.sh everytime and > make automake to the default step by the buildprocess. I think this Step > should be don ASAP. > I think that's not a load of changes, but I have a question: "How to run > automake, and where it is located" can sameone help me. > So we're diverging now from what is in the Building Guide. How do we want to keep these in sync, so new developers have accurate instructions for how to build? I know we have information on the wiki. But that gets out of synch very quickly. And if, in 6 months from now, someone needs to go back and build AOOo 3.4.0 again, the instructions on the wiki will now be different, and not good for the older build. So how do we keep build instructions that are accurate and tied to a revision of the project? Wouldn't storing build instructions in SVN, in the source tree, help here? Then when a programmer changes the build, they don't need to leave their editor or IDE. They just update the build instructions and commit it. -Rob > Thanks a load > > Greetings > Raphael > -- > My private Homepage: http://www.raphaelbircher.ch/ >
Re: Introduction and start working
Hi Oliver-- Welcome welcome welcome! :) On 09/20/2011 03:26 AM, Oliver-Rainer Wittmann wrote: Hi, I am Oliver-Rainer Wittmann, living in a small town near Hamburg, Germany, and I want to join Apache OpenOffice. In the last nine years I was working in Sun's/Oracle's OpenOffice.org development team as a software developer. My main focus was on the word processing component Writer and on the OpenDocument support for this component. May be you know me from one of the last OpenOffice.org conferences (OOoCons) which I attended since 2008 as a speaker. May be you know me as o...@openoffice.org as the Co-Lead of the OpenOffice.org Writer project. May be you know me from the OASIS ODF TC - the technical committee which is responsible for the OpenDocument file format - on which I have been an active member since December 2006 until this early summer. After same change acceptance in the last months I have got the possibility to continue my engagement in OpenOffice, now under the Apache Foundation, as an employee of IBM. I am aiming to be a valuable contributor to this project. I will start working on a consolidation of the Windows Build software requirements as given on http://ooo-wiki.apache.org/wiki/Documentation/Building_Guide/Building_on_Windows: - get rid of dependence on unicows.dll -- take over issue 88652 (https://issues.apache.org/ooo/show_bug.cgi?id=88652) from Mathias and perform the given tasks. - get rid of dependence on instmsiw.exe and instmsia.exe -- I did not find any reference to these files in the sources. On my system (Windows 7) I have done a build without them and successfully installed this built version. Thus, I will provide a corresponding patch which only removes the check for the existence of these files in the configure script. I will ask others for verification on their Windows system, if a build and a following installation is still possible. Please let me know, if somebody else is already working on these things or if you have any remarks, pros, cons, ... Afterwards, I will have a closer look at http://ooo-wiki.apache.org/wiki/ApacheMigration. I will work on certain items of it starting with: - A lot of stuff is mentioned (and marked as solved) on this page which only needs to be done as proposed and discussed on this list, but as far as I can see not yet been done. Please let me know your remarks or objections. I am looking forward to good collaboration and building close relationships. Best regards, Oliver. -- MzK "There's something about the sound of a train that's very romantic and nostalgic and hopeful." -- Paul Simon
Re: automake insteed configure
On Mon, Sep 19, 2011 at 6:00 AM, Raphael Bircher wrote: > Hi all > > In the past, configure was only rebuild if needed by samone (releng?) in > Hamburg. Now Mathias Bauer recommends to build configure.sh everytime and > make automake to the default step by the buildprocess. I think this Step > should be don ASAP. > I think that's not a load of changes, but I have a question: "How to run > automake, and where it is located" can sameone help me. > So we're diverging now from what is in the Building Guide. How do we want to keep these in sync, so new developers have accurate instructions for how to build? I know we have information on the wiki. But that gets out of synch very quickly. And if, in 6 months from now, someone needs to go back and build AOOo 3.4.0 again, the instructions on the wiki will now be different, and not good for the older build. So how do we keep build instructions that are accurate and tied to a revision of the project? Wouldn't storing build instructions in SVN, in the source tree, help here? Then when a programmer changes the build, they don't need to leave their editor or IDE. They just update the build instructions and commit it. -Rob > Thanks a load > > Greetings > Raphael > -- > My private Homepage: http://www.raphaelbircher.ch/ >
Re: A systematic approach to IP review?
2011/9/20 Jürgen Schmidt : > On Tue, Sep 20, 2011 at 2:34 PM, Shane Curcuru wrote: > >> So... has anyone actually run Apache RAT yet? It has a scan only mode >> which I'd think would be the simplest place to start. >> >> it's on my todo list to take a look on it, probably i will come back with > questions > I did a run earlier today. Good news is we have 4 files with Apache license. Bad news is we have 52,876 files with "unknown" license. In most cases that should just be the standard OOo header. These scans will be much more useful after we've replaced the OOo headers with Apache headers. But we can't just do a global change. We should only make that change for files that are in the official Oracle SGA. After that is done, then the RAT report will be more useful. > Juergen > > >> Personally, I'd recommend working on basic RAT scans, with the scripts to >> run them and any exception rules (for known files, etc.) all checked into >> SVN with the build tools for the code. But hey, it's easy for me to suggest >> "we" do stuff, when I only currently have time to be a mentor and thus can >> get away with just making suggestions. 8-) >> >> I like the general concept of storing the IP type for files in SVN >> properties; although properties are easy to change, Apache does have a >> strong history of being able to provide oversight for commit logs throughout >> a project's history. >> >> - Shane >> >
Re: handling of ext_sources - Juergen's suggestion [was: Re: A systematic approach to IP review?]
> Is your main concern performance? Even as individual tarballs, > ext-sources is 86 files, 250MB. ooo/extras is 243 files and 822 MB. > And ooo/main is 76,295 files for over 900MB. So ext-sources is not a > huge contributor to download time. You have to think about compressed data. ext_csources is 250MB *after* compression. extras and main *can* be compressed. But for me, it doesn't matter if it is in VCS or in a directory. And yes, VCS allows change tracking. The file names on hg are prepended by MD5 sum: Pavel-Janiks-MacBook-Pro:.ooo_tar_balls pavel$ md5sum d70951c80dabecc2892c919ff5d07172-db-4.7.25.NC-custom.tar.gz d70951c80dabecc2892c919ff5d07172 d70951c80dabecc2892c919ff5d07172-db-4.7.25.NC-custom.tar.gz Pavel-Janiks-MacBook-Pro:.ooo_tar_balls pavel$ So there is some work already done around this and it has some logic. -- Pavel Janík
Re: apologize for my bad quoting ;-)
Hi Jürgen Am 20.09.11 17:29, schrieb Jürgen Schmidt: 2011/9/20 Jürgen Schmidt Hi, i got noticed that my emails are purely quoted. I apologize for that and i promise to improve it in the future. I use currently gmail in the browser and often don't see or better don't realize how bad i quote it :-( because gmail folded most of the text for me. poorly ;-) You are not the only one who make typos ;-) But your quote is ok now Greetings Raphael -- My private Homepage: http://www.raphaelbircher.ch/
Re: apologize for my bad quoting ;-)
2011/9/20 Jürgen Schmidt > Hi, > > i got noticed that my emails are purely quoted. I apologize for that and i > promise to improve it in the future. I use currently gmail in the browser > and often don't see or better don't realize how bad i quote it :-( because > gmail folded most of the text for me. > poorly ;-) Juergen
Re: [OT] ASF confusion? Near to Munich/Augsburg?
Hi Christian Am 20.09.11 15:34, schrieb Christian Grobmeier: Hello, I meanwhile got several e-mails offlist from users who have not the time to read the thousands of e-mails on ooo-dev and therefore have trouble understanding things around the Apache Software Foundation and how they relate with the OpenOffice.org podling. There is a lake of Information in the german speeking regions yes. In the past, we make press release from the german NLC. The last information was about the 3.3 Release. Since then we have no translated news. The people who looks into the mailing lists, see that here is same activity. But they don't know what exactly we doing here. As I see, there is a load of confusion outthere. For people it's still unclair if the project will survieve or not. If you are one of these persons and if you are able to travel to Augsburg 22.09.2011 (this thursday!) you can participate in an 1-hour session explaining "how the ASF" works. The event is free of charge and is organized by the local Java User Group. I can't be there, but yes, maybe sameone sould geve out same informations in german. Greetings Raphael -- My private Homepage: http://www.raphaelbircher.ch/
Re: handling of ext_sources - Juergen's suggestion [was: Re: A systematic approach to IP review?]
Ai2011/9/20 Pavel Janík : >> Have we ever considered using version control to...uh...manage file versions? >> >> Just an idea. > > > Maybe Heiner will say more, but in the past, we have had the external > tarballs in the VCS, but then we moved them out and it worked very well. > There never was a reason to track external.tar.gz files in VCS, because we do > not change them. > -- That's fine. If they don't change, then doing a "svn update" will not bring them down each time. Aside from being useful for version control, SVN is useful also very useful as an audit trail. So in the rare occasions when one of these files does change, we know who changed it and why. This is important for ensuring the IP cleanliness of the project. Is your main concern performance? Even as individual tarballs, ext-sources is 86 files, 250MB. ooo/extras is 243 files and 822 MB. And ooo/main is 76,295 files for over 900MB. So ext-sources is not a huge contributor to download time. > Pavel Janík > > > >
Re: Beanshell to be relicensed under Apache License 2 !!
IMHO it's great to see that we can replace the old bsh code with the new one to get AL2-compliant, together with the big advantage that we don't have to change anything else; at least thats the impression I got. ;-) Marcus Am 09/18/2011 03:05 AM, schrieb Pedro F. Giffuni: Dear Apache OpenOffice.org community; I have been authorized, and it is my pleasure, to share with you the good news ... The Beanshell scripting language will be made available soon under the Apache License version 2. Later on, this month, the website will be updated to reflect that: http://beanshell.org/ This is done specifically to permit wider utilization of bsh by Apache projects. It will benefit the OOo incubator but also Apache Camel and others and is actually a very nice technology that is now unrestrictedly available to all Java developers and users. Special thanks to Daniel Leuck and Pat Niemeyer @ikayzo for trusting their technology to an even wider audience of open source developers and users! Pedro.
Re: Introduction and start working
Hi Oliver, welcome onboard. :-) It's great to see that you got the chance to develop full time for our office product. Marcus Am 09/20/2011 12:26 PM, schrieb Oliver-Rainer Wittmann: Hi, I am Oliver-Rainer Wittmann, living in a small town near Hamburg, Germany, and I want to join Apache OpenOffice. In the last nine years I was working in Sun's/Oracle's OpenOffice.org development team as a software developer. My main focus was on the word processing component Writer and on the OpenDocument support for this component. May be you know me from one of the last OpenOffice.org conferences (OOoCons) which I attended since 2008 as a speaker. May be you know me as o...@openoffice.org as the Co-Lead of the OpenOffice.org Writer project. May be you know me from the OASIS ODF TC - the technical committee which is responsible for the OpenDocument file format - on which I have been an active member since December 2006 until this early summer. After same change acceptance in the last months I have got the possibility to continue my engagement in OpenOffice, now under the Apache Foundation, as an employee of IBM. I am aiming to be a valuable contributor to this project. I will start working on a consolidation of the Windows Build software requirements as given on http://ooo-wiki.apache.org/wiki/Documentation/Building_Guide/Building_on_Windows: - get rid of dependence on unicows.dll -- take over issue 88652 (https://issues.apache.org/ooo/show_bug.cgi?id=88652) from Mathias and perform the given tasks. - get rid of dependence on instmsiw.exe and instmsia.exe -- I did not find any reference to these files in the sources. On my system (Windows 7) I have done a build without them and successfully installed this built version. Thus, I will provide a corresponding patch which only removes the check for the existence of these files in the configure script. I will ask others for verification on their Windows system, if a build and a following installation is still possible. Please let me know, if somebody else is already working on these things or if you have any remarks, pros, cons, ... Afterwards, I will have a closer look at http://ooo-wiki.apache.org/wiki/ApacheMigration. I will work on certain items of it starting with: - A lot of stuff is mentioned (and marked as solved) on this page which only needs to be done as proposed and discussed on this list, but as far as I can see not yet been done. Please let me know your remarks or objections. I am looking forward to good collaboration and building close relationships. Best regards, Oliver.
Re: handling of ext_sources - Juergen's suggestion [was: Re: A systematic approach to IP review?]
> Have we ever considered using version control to...uh...manage file versions? > > Just an idea. Maybe Heiner will say more, but in the past, we have had the external tarballs in the VCS, but then we moved them out and it worked very well. There never was a reason to track external.tar.gz files in VCS, because we do not change them. -- Pavel Janík
Re: handling of ext_sources - Juergen's suggestion [was: Re: A systematic approach to IP review?]
+1 - This will make it easier to update the BSD/MIT unrestricted stuff. - Hopefully it also means we will eventually stop depending on GNU patch for the build. Welcome Oliver! Great job Juergen: it's the first code replacement and a very necessary one for OO forks too (unless they want to carry lcc's copyright;) ). cheers, Pedro. On Tue, 20 Sep 2011 15:44:59 +0200, Pavel Janík wrote: Hi, I like this idea. From a developer point of view I only have to checkout "ext_sources" once and reference it from all my "trunks" using the already existing configure-switch 'with-external-tar=""' when we will have such repository, we will surely modify the current sources so you don't have to add such switch because ../ext_sources will be auto-checked. BTW - welcome! :-)
Re: handling of ext_sources - Juergen's suggestion [was: Re: A systematic approach to IP review?]
2011/9/20 Pavel Janík : >> Would we be able to do this? What if the flaw was related to code in >> ext_sources? > > Then we patch it. Patch will be in the trunk/main, as always. > >> And if not us, in the project, what if some "downstream consumer" of >> AOOo 3.4.0 wants to rebuild 3.4.0 later, for a patch or whatever. But >> we've already updated ext_sources for AOOo 4.0? > > Versions - we can and will have more tarballs of one external source. > Have we ever considered using version control to...uh...manage file versions? Just an idea. > This all is already solved. > -- > Pavel Janík > > > >
Re: handling of ext_sources - Juergen's suggestion [was: Re: A systematic approach to IP review?]
On 20.09.2011 15:58, Rob Weir wrote: On Tue, Sep 20, 2011 at 9:48 AM, Armin Le Grand wrote: On 20.09.2011 15:33, Oliver-Rainer Wittmann wrote: Hi, On 20.09.2011 14:37, Jürgen Schmidt wrote: ... What do others think about a structure where we have "ext_sources" besides "trunk". incubator/ooo/trunk incubator/ooo/ext_source ... So are we saying we would never need to branch or tag these files? For example, suppose we release AOOo 3.4.0, and then later we release AOOo 4.0. Then someone finds a serious security flaw in AOOo 3.4.0, and we decide to release an AOOo 3.4.1 as well as a AOOo 4.0.1. Would we be able to do this? What if the flaw was related to code in ext_sources? And if not us, in the project, what if some "downstream consumer" of AOOo 3.4.0 wants to rebuild 3.4.0 later, for a patch or whatever. But we've already updated ext_sources for AOOo 4.0? In other words, how do we track, in SVN, a compatible set of matching trunk/ and ext_source/ revisions, so we (or someone else) can recreate any released version of AOOo? Good point. Thus, it should be part of incubator/ooo/trunk, something like: incubator/ooo/trunk/main incubator/ooo/trunk/extras incubator/ooo/trunk/ext_sources It could be in an own repro, but this would just bring up the risk to not use the same tags in both (by purpose or by error). Indeed, looks as if it has to be a part of trunk somehow. Not very nice for binaries. Maybe we could find a intermediate place for them as long as we will need to do changes pretty often. Currently we will have to do some add/remove/changes to it. It could be good to add them to trunk after it has stabilized a little more. -Rob I like this idea. From a developer point of view I only have to checkout "ext_sources" once and reference it from all my "trunks" using the already existing configure-switch 'with-external-tar=""' +1 Also, hopefully ext_sources will not change too much (after a consolidation phase) and it's mostly binaries, thus not too well suited for a repository. Let's not extend our main repository with those binaries, please. Best regards, Oliver. Regards, Armin -- ALG
Re: handling of ext_sources - Juergen's suggestion [was: Re: A systematic approach to IP review?]
> Would we be able to do this? What if the flaw was related to code in > ext_sources? Then we patch it. Patch will be in the trunk/main, as always. > And if not us, in the project, what if some "downstream consumer" of > AOOo 3.4.0 wants to rebuild 3.4.0 later, for a patch or whatever. But > we've already updated ext_sources for AOOo 4.0? Versions - we can and will have more tarballs of one external source. This all is already solved. -- Pavel Janík
Re: handling of ext_sources - Juergen's suggestion [was: Re: A systematic approach to IP review?]
On Tue, Sep 20, 2011 at 9:48 AM, Armin Le Grand wrote: > On 20.09.2011 15:33, Oliver-Rainer Wittmann wrote: >> >> Hi, >> >> On 20.09.2011 14:37, Jürgen Schmidt wrote: > > ... >>> >>> What do others think about a structure where we have "ext_sources" >>> besides >>> "trunk". >>> >>> incubator/ooo/trunk >>> incubator/ooo/ext_source >>> ... So are we saying we would never need to branch or tag these files? For example, suppose we release AOOo 3.4.0, and then later we release AOOo 4.0. Then someone finds a serious security flaw in AOOo 3.4.0, and we decide to release an AOOo 3.4.1 as well as a AOOo 4.0.1. Would we be able to do this? What if the flaw was related to code in ext_sources? And if not us, in the project, what if some "downstream consumer" of AOOo 3.4.0 wants to rebuild 3.4.0 later, for a patch or whatever. But we've already updated ext_sources for AOOo 4.0? In other words, how do we track, in SVN, a compatible set of matching trunk/ and ext_source/ revisions, so we (or someone else) can recreate any released version of AOOo? -Rob >>> >> >> I like this idea. >> >> From a developer point of view I only have to checkout "ext_sources" >> once and reference it from all my "trunks" using the already existing >> configure-switch 'with-external-tar=""' > > +1 > > Also, hopefully ext_sources will not change too much (after a consolidation > phase) and it's mostly binaries, thus not too well suited for a repository. > Let's not extend our main repository with those binaries, please. > >> Best regards, Oliver. >> > > Regards, > Armin > -- > ALG > >
Re: Freeze on Impress
Hi Armin Am 20.09.11 15:44, schrieb Armin Le Grand: On 20.09.2011 15:22, Raphael Bircher wrote: Hello I have found a freeze in Impress. Steps to reproduce: - Start impress, and create a new doc - Type samething on the first slide - Add a slide - Type samething on the second slide - Open Print Dialog, and go to the tab OpenOffice.org Impress - Try to check "Distribute on multiple sheets on paper" OpenOffice.org Freeze. Tested on WIN7 with freshly build AOO version from (pretty) current trunc, no crash here. Thanks for testing! So maybe Mac or Unix only? -- My private Homepage: http://www.raphaelbircher.ch/
Re: Introduction and start working
On Tue, Sep 20, 2011 at 6:26 AM, Oliver-Rainer Wittmann wrote: > Hi, > > I am Oliver-Rainer Wittmann, living in a small town near Hamburg, Germany, > and I want to join Apache OpenOffice. > Welcome to the project, Oliver! > In the last nine years I was working in Sun's/Oracle's OpenOffice.org > development team as a software developer. My main focus was on the word > processing component Writer and on the OpenDocument support for this > component. > May be you know me from one of the last OpenOffice.org conferences (OOoCons) > which I attended since 2008 as a speaker. > May be you know me as o...@openoffice.org as the Co-Lead of the OpenOffice.org > Writer project. > May be you know me from the OASIS ODF TC - the technical committee which is > responsible for the OpenDocument file format - on which I have been an > active member since December 2006 until this early summer. > I hope we will see you back at OASIS as well. In particular it would be good to understand which change tracking proposal will work best for AOOo. > After same change acceptance in the last months I have got the possibility > to continue my engagement in OpenOffice, now under the Apache Foundation, as > an employee of IBM. I am aiming to be a valuable contributor to this > project. > IBM? I've heard of it. They make typewriters, yes? > I will start working on a consolidation of the Windows Build software > requirements as given on > http://ooo-wiki.apache.org/wiki/Documentation/Building_Guide/Building_on_Windows: > - get rid of dependence on unicows.dll > -- take over issue 88652 > (https://issues.apache.org/ooo/show_bug.cgi?id=88652) from Mathias and > perform the given tasks. > - get rid of dependence on instmsiw.exe and instmsia.exe > -- I did not find any reference to these files in the sources. On my system > (Windows 7) I have done a build without them and successfully installed this > built version. Thus, I will provide a corresponding patch which only removes > the check for the existence of these files in the configure script. I will > ask others for verification on their Windows system, if a build and a > following installation is still possible. I don't know if you saw the "developer education" event we did a couple of weeks ago for the Linux build. It might be interesting to do something similar for the Windows build, once you have the above issues resolved. This would help us test the build documentation and build system. as well as enable more developers to help with the project. > Please let me know, if somebody else is already working on these things or > if you have any remarks, pros, cons, ... > > Afterwards, I will have a closer look at > http://ooo-wiki.apache.org/wiki/ApacheMigration. I will work on certain > items of it starting with: > - A lot of stuff is mentioned (and marked as solved) on this page which only > needs to be done as proposed and discussed on this list, but as far as I can > see not yet been done. > Please let me know your remarks or objections. > I see that you have an iCLA on record, but are not yet a committer. You can read more about becoming a committer here: http://incubator.apache.org/openofficeorg/ppmc-faqs.html I think the key thing is to participate in the dev discussions on this list and submit some high-quality patches. This should be easy for you. Think of it like an Olympic trial. Everyone, even the fastest runner in the world, still needs to try out for the team. > > I am looking forward to good collaboration and building close relationships. > > Best regards, Oliver. >
apologize for my bad quoting ;-)
Hi, i got noticed that my emails are purely quoted. I apologize for that and i promise to improve it in the future. I use currently gmail in the browser and often don't see or better don't realize how bad i quote it :-( because gmail folded most of the text for me. Sorry for that Juergen
Re: handling of ext_sources - Juergen's suggestion [was: Re: A systematic approach to IP review?]
On 20.09.2011 15:33, Oliver-Rainer Wittmann wrote: Hi, On 20.09.2011 14:37, Jürgen Schmidt wrote: ... What do others think about a structure where we have "ext_sources" besides "trunk". incubator/ooo/trunk incubator/ooo/ext_source ... I like this idea. From a developer point of view I only have to checkout "ext_sources" once and reference it from all my "trunks" using the already existing configure-switch 'with-external-tar=""' +1 Also, hopefully ext_sources will not change too much (after a consolidation phase) and it's mostly binaries, thus not too well suited for a repository. Let's not extend our main repository with those binaries, please. Best regards, Oliver. Regards, Armin -- ALG
Re: Freeze on Impress
On 20.09.2011 15:22, Raphael Bircher wrote: Hello I have found a freeze in Impress. Steps to reproduce: - Start impress, and create a new doc - Type samething on the first slide - Add a slide - Type samething on the second slide - Open Print Dialog, and go to the tab OpenOffice.org Impress - Try to check "Distribute on multiple sheets on paper" OpenOffice.org Freeze. Tested on WIN7 with freshly build AOO version from (pretty) current trunc, no crash here. Tested with a self backed AOOo (with --disable-copyleft) an a Mac OS X 10.5. Are there other Systems affected? Is this bug still in a older Version of OOo? Greetings Raphael Sincerely Armin -- ALG
Re: handling of ext_sources - Juergen's suggestion [was: Re: A systematic approach to IP review?]
Hi, > I like this idea. > > From a developer point of view I only have to checkout "ext_sources" once and > reference it from all my "trunks" using the already existing configure-switch > 'with-external-tar=""' when we will have such repository, we will surely modify the current sources so you don't have to add such switch because ../ext_sources will be auto-checked. BTW - welcome! :-) -- Pavel Janík
Re: Freeze on Impress
Tested on Windows Vista with build 9567, no crash. Peter roelofsen Op 20-9-2011 15:22, Raphael Bircher schreef: Hello I have found a freeze in Impress. Steps to reproduce: - Start impress, and create a new doc - Type samething on the first slide - Add a slide - Type samething on the second slide - Open Print Dialog, and go to the tab OpenOffice.org Impress - Try to check "Distribute on multiple sheets on paper" OpenOffice.org Freeze. Tested with a self backed AOOo (with --disable-copyleft) an a Mac OS X 10.5. Are there other Systems affected? Is this bug still in a older Version of OOo? Greetings Raphael
[OT] ASF confusion? Near to Munich/Augsburg?
Hello, I meanwhile got several e-mails offlist from users who have not the time to read the thousands of e-mails on ooo-dev and therefore have trouble understanding things around the Apache Software Foundation and how they relate with the OpenOffice.org podling. If you are one of these persons and if you are able to travel to Augsburg 22.09.2011 (this thursday!) you can participate in an 1-hour session explaining "how the ASF" works. The event is free of charge and is organized by the local Java User Group. If you would like to join, reserve a seat via Xing: https://www.xing.com/events/apache-software-foundation-22-09-2011-19-00-802422 Cheers, Christian
handling of ext_sources - Juergen's suggestion [was: Re: A systematic approach to IP review?]
Hi, On 20.09.2011 14:37, Jürgen Schmidt wrote: On Mon, Sep 19, 2011 at 1:59 PM, Rob Weir wrote: 2011/9/19 Jürgen Schmidt: On Mon, Sep 19, 2011 at 2:27 AM, Rob Weir wrote: ... Suggestions: 1) We need to get all files needed for the build into SVN. Right now there are some that are copied down from the OpenOffice.org website during the build's bootstrap process. Until we get the files all in one place it is hard to get a comprehensive view of our dependencies. do you mean to check in the files under ext_source into svn and remove it later on when we have cleaned up the code. Or do you mean to put it somehwere on apache extras? I would prefer to save these binary files under apache extra if possible. Why not just keep in in SVN? Moving things to Apache-Extras does not help us with the IP review. In other words, if we have a dependency on a OSS module that has an incompatible license, then moving that module to Apache Extras does not make that dependency go away. We still need to understand the nature of the dependency: a build tool, a dynamic runtime dependency, a statically linked library, an optional extensions, a necessary core module. If we find out, for example, that something in ext-sources is only used as a build tool, and is not part of the release, then there is nothing that prevents us from hosting it in SVN. But if something is a necessary library and it is under GPL, then this is a problem even if we store it on Apache-Extras, i am not really happy with all the binaries in the trunk tree because of the large binary blobs and i don't expect too many changes of these dependencies. And i would like to avoid to check them out every time. What do others think about a structure where we have "ext_sources" besides "trunk". incubator/ooo/trunk incubator/ooo/ext_source ... I like this idea. From a developer point of view I only have to checkout "ext_sources" once and reference it from all my "trunks" using the already existing configure-switch 'with-external-tar=""' Best regards, Oliver.
Freeze on Impress
Hello I have found a freeze in Impress. Steps to reproduce: - Start impress, and create a new doc - Type samething on the first slide - Add a slide - Type samething on the second slide - Open Print Dialog, and go to the tab OpenOffice.org Impress - Try to check "Distribute on multiple sheets on paper" OpenOffice.org Freeze. Tested with a self backed AOOo (with --disable-copyleft) an a Mac OS X 10.5. Are there other Systems affected? Is this bug still in a older Version of OOo? Greetings Raphael -- My private Homepage: http://www.raphaelbircher.ch/
Re: A systematic approach to IP review?
On Tue, Sep 20, 2011 at 2:34 PM, Shane Curcuru wrote: > So... has anyone actually run Apache RAT yet? It has a scan only mode > which I'd think would be the simplest place to start. > > it's on my todo list to take a look on it, probably i will come back with questions Juergen > Personally, I'd recommend working on basic RAT scans, with the scripts to > run them and any exception rules (for known files, etc.) all checked into > SVN with the build tools for the code. But hey, it's easy for me to suggest > "we" do stuff, when I only currently have time to be a mentor and thus can > get away with just making suggestions. 8-) > > I like the general concept of storing the IP type for files in SVN > properties; although properties are easy to change, Apache does have a > strong history of being able to provide oversight for commit logs throughout > a project's history. > > - Shane >
Re: A systematic approach to IP review?
On Mon, Sep 19, 2011 at 1:59 PM, Rob Weir wrote: > 2011/9/19 Jürgen Schmidt : > > On Mon, Sep 19, 2011 at 2:27 AM, Rob Weir wrote: > > > >> If you haven't looked it closely, it is probably worth a few minutes > >> of your time to review our incubation status page, especially the > >> items under "Copyright" and "Verify Distribution Rights". It lists > >> the things we need to do, including: > >> > >> -- Check and make sure that the papers that transfer rights to the > >> ASF been received. It is only necessary to transfer rights for the > >> package, the core code, and any new code produced by the project. > >> > >> -- Check and make sure that the files that have been donated have been > >> updated to reflect the new ASF copyright. > >> > >> -- Check and make sure that for all code included with the > >> distribution that is not under the Apache license, we have the right > >> to combine with Apache-licensed code and redistribute. > >> > >> -- Check and make sure that all source code distributed by the project > >> is covered by one or more of the following approved licenses: Apache, > >> BSD, Artistic, MIT/X, MIT/W3C, MPL 1.1, or something with essentially > >> the same terms. > >> > >> Some of this is already going on, but it is hard to get a sense of who > >> is doing what and how much progress we have made. I wonder if we can > >> agree to a more systematic approach? This will make it easier to see > >> the progress we're making and it will also make it easier for others > >> to help. > >> > >> Suggestions: > >> > >> 1) We need to get all files needed for the build into SVN. Right now > >> there are some that are copied down from the OpenOffice.org website > >> during the build's bootstrap process. Until we get the files all in > >> one place it is hard to get a comprehensive view of our dependencies. > >> > > > > do you mean to check in the files under ext_source into svn and remove it > > later on when we have cleaned up the code. Or do you mean to put it > > somehwere on apache extras? > > I would prefer to save these binary files under apache extra if possible. > > > > > Why not just keep in in SVN? Moving things to Apache-Extras does not > help us with the IP review. In other words, if we have a dependency > on a OSS module that has an incompatible license, then moving that > module to Apache Extras does not make that dependency go away. We > still need to understand the nature of the dependency: a build tool, a > dynamic runtime dependency, a statically linked library, an optional > extensions, a necessary core module. > > If we find out, for example, that something in ext-sources is only > used as a build tool, and is not part of the release, then there is > nothing that prevents us from hosting it in SVN. But if something is > a necessary library and it is under GPL, then this is a problem even > if we store it on Apache-Extras, > > i am not really happy with all the binaries in the trunk tree because of the large binary blobs and i don't expect too many changes of these dependencies. And i would like to avoid to check them out every time. What do others think about a structure where we have "ext_sources" besides "trunk". incubator/ooo/trunk incubator/ooo/ext_source ... If we can agree on such a structure i would move forward to bring in some new external sources. The proposed ucpp preprocessor -> BSD license, used in the idlc and of course part of the SDK later on. I made some tests with it and was able to build the sources on windows in our cygwin environment with a new gnu make file. I was also able to build udkapi and offapi with this new and adapted idlc/ucpp without any problems -> generated type library is equal to the old one. I have to run some more tests on other platforms as soon as i have other platforms available for testing. I decided to replace the preprocessor instead of removing it because of compatibility reasons and it was of course the easier change. The next step is to check how the process with ext_sources work in detail in our build process and adapt the new ucpp module. If anybody is familiar with ext_sources and can point me to potential hurdles, please let me know (on a new thread) ;-) Juergen > > > > >> > >> 2) Continue the CWS integrations. Along with 1) this ensures that all > >> the code we need for the release is in SVN. > >> > >> 3) Files that Oracle include in their SGA need to have the Apache > >> license header inserted and the Sun/Oracle copyright migrated to the > >> NOTICE file. Apache RAT (Release Audit Tool) [2] can be used to > >> automate parts of this. > >> > >> 4) Once the SGA files have the Apache headers, then we can make > >> regular use of RAT to report on files that are lacking an Apache > >> header. Such files might be in one of the following categories: > >> > >> a) Files that Oracle owns the copyright on and which should be > >> included in an amended SGA > >> > >> b) Files that have a compatible OSS license which w
Re: A systematic approach to IP review?
So... has anyone actually run Apache RAT yet? It has a scan only mode which I'd think would be the simplest place to start. Personally, I'd recommend working on basic RAT scans, with the scripts to run them and any exception rules (for known files, etc.) all checked into SVN with the build tools for the code. But hey, it's easy for me to suggest "we" do stuff, when I only currently have time to be a mentor and thus can get away with just making suggestions. 8-) I like the general concept of storing the IP type for files in SVN properties; although properties are easy to change, Apache does have a strong history of being able to provide oversight for commit logs throughout a project's history. - Shane
Re: Introduction and start working
Hi Nakata Maho, thanks for the welcome. Until last Friday I had a 21" iMac PowerPC on my home desk, but now it has been replaced by a new 27" iMac Intel. Thus, my PPC iMac is more or less retired, but if needed I can wake this machine up ;-) Best regards, Oliver. On 20.09.2011 13:39, Maho NAKATA wrote: Hello Oliver-Rainer Wittmann I'm very happy to work with you, again, and congratulations for new position at IBM. Do you still use PPC based Mac? Recently I bought MacBookAir and it is really nice laptop. Regards, Nakata Maho 2011/9/20 Oliver-Rainer Wittmann: Hi, I am Oliver-Rainer Wittmann, living in a small town near Hamburg, Germany, and I want to join Apache OpenOffice. In the last nine years I was working in Sun's/Oracle's OpenOffice.org development team as a software developer. My main focus was on the word processing component Writer and on the OpenDocument support for this component. May be you know me from one of the last OpenOffice.org conferences (OOoCons) which I attended since 2008 as a speaker. May be you know me as o...@openoffice.org as the Co-Lead of the OpenOffice.org Writer project. May be you know me from the OASIS ODF TC - the technical committee which is responsible for the OpenDocument file format - on which I have been an active member since December 2006 until this early summer. After same change acceptance in the last months I have got the possibility to continue my engagement in OpenOffice, now under the Apache Foundation, as an employee of IBM. I am aiming to be a valuable contributor to this project. I will start working on a consolidation of the Windows Build software requirements as given on http://ooo-wiki.apache.org/wiki/Documentation/Building_Guide/Building_on_Windows: - get rid of dependence on unicows.dll -- take over issue 88652 (https://issues.apache.org/ooo/show_bug.cgi?id=88652) from Mathias and perform the given tasks. - get rid of dependence on instmsiw.exe and instmsia.exe -- I did not find any reference to these files in the sources. On my system (Windows 7) I have done a build without them and successfully installed this built version. Thus, I will provide a corresponding patch which only removes the check for the existence of these files in the configure script. I will ask others for verification on their Windows system, if a build and a following installation is still possible. Please let me know, if somebody else is already working on these things or if you have any remarks, pros, cons, ... Afterwards, I will have a closer look at http://ooo-wiki.apache.org/wiki/ApacheMigration. I will work on certain items of it starting with: - A lot of stuff is mentioned (and marked as solved) on this page which only needs to be done as proposed and discussed on this list, but as far as I can see not yet been done. Please let me know your remarks or objections. I am looking forward to good collaboration and building close relationships. Best regards, Oliver.
Re: Introduction and start working
Hello Oliver-Rainer Wittmann I'm very happy to work with you, again, and congratulations for new position at IBM. Do you still use PPC based Mac? Recently I bought MacBookAir and it is really nice laptop. Regards, Nakata Maho 2011/9/20 Oliver-Rainer Wittmann : > Hi, > > I am Oliver-Rainer Wittmann, living in a small town near Hamburg, Germany, > and I want to join Apache OpenOffice. > > In the last nine years I was working in Sun's/Oracle's OpenOffice.org > development team as a software developer. My main focus was on the word > processing component Writer and on the OpenDocument support for this > component. > May be you know me from one of the last OpenOffice.org conferences (OOoCons) > which I attended since 2008 as a speaker. > May be you know me as o...@openoffice.org as the Co-Lead of the OpenOffice.org > Writer project. > May be you know me from the OASIS ODF TC - the technical committee which is > responsible for the OpenDocument file format - on which I have been an > active member since December 2006 until this early summer. > > After same change acceptance in the last months I have got the possibility > to continue my engagement in OpenOffice, now under the Apache Foundation, as > an employee of IBM. I am aiming to be a valuable contributor to this > project. > > I will start working on a consolidation of the Windows Build software > requirements as given on > http://ooo-wiki.apache.org/wiki/Documentation/Building_Guide/Building_on_Windows: > - get rid of dependence on unicows.dll > -- take over issue 88652 > (https://issues.apache.org/ooo/show_bug.cgi?id=88652) from Mathias and > perform the given tasks. > - get rid of dependence on instmsiw.exe and instmsia.exe > -- I did not find any reference to these files in the sources. On my system > (Windows 7) I have done a build without them and successfully installed this > built version. Thus, I will provide a corresponding patch which only removes > the check for the existence of these files in the configure script. I will > ask others for verification on their Windows system, if a build and a > following installation is still possible. > Please let me know, if somebody else is already working on these things or > if you have any remarks, pros, cons, ... > > Afterwards, I will have a closer look at > http://ooo-wiki.apache.org/wiki/ApacheMigration. I will work on certain > items of it starting with: > - A lot of stuff is mentioned (and marked as solved) on this page which only > needs to be done as proposed and discussed on this list, but as far as I can > see not yet been done. > Please let me know your remarks or objections. > > > I am looking forward to good collaboration and building close relationships. > > Best regards, Oliver. >
Re: A systematic approach to IP review?
On Mon, Sep 19, 2011 at 7:05 PM, Rob Weir wrote: > On Mon, Sep 19, 2011 at 12:43 PM, Marcus (OOo) > wrote: > > Am 09/19/2011 04:47 PM, schrieb Rob Weir: > >> > >> On Mon, Sep 19, 2011 at 8:13 AM, Marcus (OOo) > >> wrote: > >>> > >>> Am 09/19/2011 01:59 PM, schrieb Rob Weir: > > 2011/9/19 Jürgen Schmidt: > > > > On Mon, Sep 19, 2011 at 2:27 AM, Rob Weir > wrote: > > > >> If you haven't looked it closely, it is probably worth a few minutes > >> of your time to review our incubation status page, especially the > >> items under "Copyright" and "Verify Distribution Rights". It lists > >> the things we need to do, including: > >> > >> -- Check and make sure that the papers that transfer rights to the > >> ASF been received. It is only necessary to transfer rights for the > >> package, the core code, and any new code produced by the project. > >> > >> -- Check and make sure that the files that have been donated have > been > >> updated to reflect the new ASF copyright. > >> > >> -- Check and make sure that for all code included with the > >> distribution that is not under the Apache license, we have the right > >> to combine with Apache-licensed code and redistribute. > >> > >> -- Check and make sure that all source code distributed by the > project > >> is covered by one or more of the following approved licenses: > Apache, > >> BSD, Artistic, MIT/X, MIT/W3C, MPL 1.1, or something with > essentially > >> the same terms. > >> > >> Some of this is already going on, but it is hard to get a sense of > who > >> is doing what and how much progress we have made. I wonder if we > can > >> agree to a more systematic approach? This will make it easier to > see > >> the progress we're making and it will also make it easier for others > >> to help. > >> > >> Suggestions: > >> > >> 1) We need to get all files needed for the build into SVN. Right > now > >> there are some that are copied down from the OpenOffice.org website > >> during the build's bootstrap process. Until we get the files all > in > >> one place it is hard to get a comprehensive view of our > dependencies. > >> > > > > do you mean to check in the files under ext_source into svn and > remove > > it > > later on when we have cleaned up the code. Or do you mean to put it > > somehwere on apache extras? > > I would prefer to save these binary files under apache extra if > > possible. > > > > > Why not just keep in in SVN? Moving things to Apache-Extras does not > help us with the IP review. In other words, if we have a dependency > on a OSS module that has an incompatible license, then moving that > module to Apache Extras does not make that dependency go away. We > still need to understand the nature of the dependency: a build tool, a > dynamic runtime dependency, a statically linked library, an optional > extensions, a necessary core module. > > If we find out, for example, that something in ext-sources is only > used as a build tool, and is not part of the release, then there is > nothing that prevents us from hosting it in SVN. But if something is > a necessary library and it is under GPL, then this is a problem even > if we store it on Apache-Extras, > > > > > >> > >> 2) Continue the CWS integrations. Along with 1) this ensures that > all > >> the code we need for the release is in SVN. > >> > >> 3) Files that Oracle include in their SGA need to have the Apache > >> license header inserted and the Sun/Oracle copyright migrated to the > >> NOTICE file. Apache RAT (Release Audit Tool) [2] can be used to > >> automate parts of this. > >> > >> 4) Once the SGA files have the Apache headers, then we can make > >> regular use of RAT to report on files that are lacking an Apache > >> header. Such files might be in one of the following categories: > >> > >> a) Files that Oracle owns the copyright on and which should be > >> included in an amended SGA > >> > >> b) Files that have a compatible OSS license which we are permitted > to > >> use. This might require that we add a mention of it to the NOTICE > >> file. > >> > >> c) Files that have an incompatible OSS license. These need to be > >> removed/replaced. > >> > >> d) Files that have an OSS license that has not yet been > >> reviewed/categorized by Apache legal affairs. In that case we need > to > >> bring it to their attention. > >> > >> e) (Hypothetically) files that are not under an OSS license at all. > >> E.g., a Microsoft header file. These must be removed. > >> > >> 5) We should to track the resolution of each file, and do this > >> publicly. The audit trail is important. Some way
Introduction and start working
Hi, I am Oliver-Rainer Wittmann, living in a small town near Hamburg, Germany, and I want to join Apache OpenOffice. In the last nine years I was working in Sun's/Oracle's OpenOffice.org development team as a software developer. My main focus was on the word processing component Writer and on the OpenDocument support for this component. May be you know me from one of the last OpenOffice.org conferences (OOoCons) which I attended since 2008 as a speaker. May be you know me as o...@openoffice.org as the Co-Lead of the OpenOffice.org Writer project. May be you know me from the OASIS ODF TC - the technical committee which is responsible for the OpenDocument file format - on which I have been an active member since December 2006 until this early summer. After same change acceptance in the last months I have got the possibility to continue my engagement in OpenOffice, now under the Apache Foundation, as an employee of IBM. I am aiming to be a valuable contributor to this project. I will start working on a consolidation of the Windows Build software requirements as given on http://ooo-wiki.apache.org/wiki/Documentation/Building_Guide/Building_on_Windows: - get rid of dependence on unicows.dll -- take over issue 88652 (https://issues.apache.org/ooo/show_bug.cgi?id=88652) from Mathias and perform the given tasks. - get rid of dependence on instmsiw.exe and instmsia.exe -- I did not find any reference to these files in the sources. On my system (Windows 7) I have done a build without them and successfully installed this built version. Thus, I will provide a corresponding patch which only removes the check for the existence of these files in the configure script. I will ask others for verification on their Windows system, if a build and a following installation is still possible. Please let me know, if somebody else is already working on these things or if you have any remarks, pros, cons, ... Afterwards, I will have a closer look at http://ooo-wiki.apache.org/wiki/ApacheMigration. I will work on certain items of it starting with: - A lot of stuff is mentioned (and marked as solved) on this page which only needs to be done as proposed and discussed on this list, but as far as I can see not yet been done. Please let me know your remarks or objections. I am looking forward to good collaboration and building close relationships. Best regards, Oliver.
Re: svn commit: r1172617 - /incubator/ooo/trunk/main/solenv/bin/build.pl
On 20.09.2011 03:12, Pedro Giffuni wrote: You guys have just reminded me of codespell, a pretty nice tool to find english mistakes and typos in code comments: A nice tool indeed and the current OOo code base provides plenty of fodder for it. Fixing them provides some nice and easy tasks especially for native speakers. Herbert
Re: svn commit: r1172617 - /incubator/ooo/trunk/main/solenv/bin/build.pl
On 20.09.2011 01:22, TJ Frazier wrote: URL: http://svn.apache.org/viewvc?rev=1172617&view=rev Log: prolongue is not in my dictionary [...] Thank you very much for fixing that ugly error. For the best English, after "When you" in both places, you should either s/fixed/fix/ or s/fixed/have fixed/ to get the tense right. Thanks for the suggestion! => http://svn.apache.org/viewvc?view=revision&revision=1173008 Herbert
