Re: OpenOffice.org migration status

Hi - > On Oct 29, 2020, at 11:05 AM, Dave Fisher wrote: > > Hi Matthias, > > We now have staging at https://openoffice-org.staged.apache.org > > > It is only some content. In order to make our SSI work I had to add .htaccess > >

Re: 4.1.8-RC3

On 29 Oct, Jim Jagielski wrote: > I think we are ready for 4.1.8-RC3. I'll start Linux and macOS builds. Building on CentOS 5 and running both on CentOS 5 and Ubuntu 16 seem to work. - To unsubscribe, e-mail:

Re: 4.1.8-RC3

Hi Jim, all Compiling under Ubuntu 18.04.5 x64 stops at ERROR: error 65280 occurred while making /source/openoffice/main/sc/source/filter/xml ERROR: error 65280 occurred while making /source/openoffice/main/sc/source/ui/unoobj When you have fixed the errors in that module you can resume the

Re: OpenOffice.org migration status

Hi Matthias, We now have staging at https://openoffice-org.staged.apache.org It is only some content. In order to make our SSI work I had to add .htaccess https://github.com/apache/openoffice-org/blob/main/assets/.htaccess

Re: OpenOffice.org migration status

Hi Dave, Thanks for all the work! Once everything is finished I hope to understand it and will try to help. BTW: Do we plan to have a permanent redirection to https? Infra recommends to do it via .htaccess. When I worked on the "old" page I invested a lot of time to get rid of "mixed content" so

Re: 4.1.8-RC3

Yep, that's it. > On Oct 29, 2020, at 11:56 AM, Matthias Seidel > wrote: > > Hi Jim, > > Am 29.10.20 um 16:07 schrieb Jim Jagielski: >> I think we are ready for 4.1.8-RC3. I'll start Linux and macOS builds. > > That's 18848f57b6 ? > > Will start for Windows... > >> >>

Re: [openoffice] branch AOO418 updated: Fix redland build issues when using CentOS5 as build and later platforms as user. Squash General Error.

trunk and AOO42X should also get this fix. On 29 Oct, j...@apache.org wrote: > This is an automated email from the ASF dual-hosted git repository. > > jim pushed a commit to branch AOO418 > in repository https://gitbox.apache.org/repos/asf/openoffice.git > > > The following commit(s) were

Re: 4.1.8-RC3

Hi Jim, Am 29.10.20 um 16:07 schrieb Jim Jagielski: > I think we are ready for 4.1.8-RC3. I'll start Linux and macOS builds. That's 18848f57b6 ? Will start for Windows... > > - > To unsubscribe, e-mail:

4.1.8-RC3

I think we are ready for 4.1.8-RC3. I'll start Linux and macOS builds. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: test12 (Was: Re: test11 (Was: Re: test2 is ready to run))

AND WE HAVE A WINNER!! With the below changes to the redland build setup, I get no errors when opening on Ubuntu 18.04. > On Oct 29, 2020, at 7:28 AM, Jim Jagielski wrote: > > I'm trying with this: > > diff --git a/main/redland/raptor/makefile.mk b/main/redland/raptor/makefile.mk > index

Re: test12 (Was: Re: test11 (Was: Re: test2 is ready to run))

I'm trying with this: diff --git a/main/redland/raptor/makefile.mk b/main/redland/raptor/makefile.mk index 51b78762c3..0c8b6a4d7b 100644 --- a/main/redland/raptor/makefile.mk +++ b/main/redland/raptor/makefile.mk @@ -128,7 +128,7 @@ XSLTLIB!:=$(XSLTLIB) # expand dmake variables for xslt-config

Re: QA Automated Test coverage

Hi Peter > On 10/29/2020 10:47 AM Peter Kovacs wrote: > > > How about creating an automated manual test RPA robot as a GSoC? > > Just a wild idea. I think that if one of the people reading this email today knows how to fix this (and has the time/urge to scratch this itch) then it is

Re: QA Automated Test coverage

How about creating an automated manual test RPA robot as a GSoC? Just a wild idea. Am 28. Oktober 2020 22:42:11 MEZ schrieb Andrea Pescetti : >Peter Kovacs wrote: >> Maybe the following link helps? >> https://www.openoffice.org/qa/testcase/index.html > >Indeed, this section

Re: test12 (Was: Re: test11 (Was: Re: test2 is ready to run))

I did try specifically forcing --with-curl-config=no, because I saw that too, but that wasn't it.I also add 'with-threads' which was in the old CONFIGURE_FLAGS but that this one and again no luck. But I think we're on the right track. > On Oct 28, 2020, at 7:59 PM, Don Lewis wrote: > > On 27

Re: building from a source tarball

We could change the logic such that if that file is there, use that by default. > On Oct 28, 2020, at 5:55 PM, Andrea Pescetti wrote: > > Don Lewis wrote: >> On 28 Oct, Jim Jagielski wrote: >>> In particular, this is when building from the "official" SRC_RELEASE >>> tarball we provide. Is the

Re: test12 (Was: Re: test11 (Was: Re: test2 is ready to run))

On 28 Oct, Don Lewis wrote: > On 28 Oct, Don Lewis wrote: >> On 27 Oct, Don Lewis wrote: >>> On 27 Oct, Jim Jagielski wrote: Maybe... but it DID WORK before. That is, before the mega patch, configure did the "right thing". So if something is causing configure to make a different