AOO 4.2.0-beta/alpha

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

AOO 4.2.0-beta/alpha

Jim Jagielski
I've started playing around w/ getting 4.2.0-HEAD to build; as expected, so real issues w/ Ubuntu or CentOS7 but macOS is causing problems, what with the migration to gbuild for various modules and how these migrations constantly break macOS. I'll try to start hammering fixing/working-around these, but my recommendation would be that instead of migrating to gbuild willy-nilly, we only do so on (1) modules that NEED it, due to new versions or (2) are so easy and basic that the risk that it breaks other platforms is pretty much nil.

Does that make sense?
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Min macOS version for 4.20

Jim Jagielski
One option we have is that we drop support for macOS 10.7 and older for 4.20.x... this MIGHT help.

I can/will test that assumption.

> On Jan 8, 2019, at 9:54 AM, Jim Jagielski <[hidden email]> wrote:
>
> I've started playing around w/ getting 4.2.0-HEAD to build; as expected, so real issues w/ Ubuntu or CentOS7 but macOS is causing problems, what with the migration to gbuild for various modules and how these migrations constantly break macOS. I'll try to start hammering fixing/working-around these, but my recommendation would be that instead of migrating to gbuild willy-nilly, we only do so on (1) modules that NEED it, due to new versions or (2) are so easy and basic that the risk that it breaks other platforms is pretty much nil.
>
> Does that make sense?
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Min macOS version for 4.20

Peter Kovacs-4
I am not sure what you mean.
We should update to use the latest SDK.
According to Apple it is still posible to build for 10.7  with it.
Maybe that would be better approach?

I think you have also to look into available flags since there is a lot of change in the last 10 years in compiler terms.
See mechtildes post and my older post to build on Arch linux.
So you might well run into different issues with the approach.

Maybe also posting the issued might help. Maybe they are not that bad.

I am sorry that the mac buildbot isnt ready. I could use some help there.
If anyone has time.
We currently need to define the brew commands in order to install all the tools we need. Then we can try to build. And the result is public. Which would make it easy for others to check on their work.

Am Dienstag, 8. Januar 2019 schrieb Jim Jagielski:

> One option we have is that we drop support for macOS 10.7 and older for 4.20.x... this MIGHT help.
>
> I can/will test that assumption.
>
> > On Jan 8, 2019, at 9:54 AM, Jim Jagielski <[hidden email]> wrote:
> >
> > I've started playing around w/ getting 4.2.0-HEAD to build; as expected, so real issues w/ Ubuntu or CentOS7 but macOS is causing problems, what with the migration to gbuild for various modules and how these migrations constantly break macOS. I'll try to start hammering fixing/working-around these, but my recommendation would be that instead of migrating to gbuild willy-nilly, we only do so on (1) modules that NEED it, due to new versions or (2) are so easy and basic that the risk that it breaks other platforms is pretty much nil.
> >
> > Does that make sense?
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

--
Gesendet von meinem Sailfish-Gerät.
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: AOO 4.2.0-beta/alpha

Mechtilde Stehmann-2
In reply to this post by Jim Jagielski
Hello Jim,

Am 08.01.19 um 15:54 schrieb Jim Jagielski:
> I've started playing around w/ getting 4.2.0-HEAD to build; as expected, so real issues w/ Ubuntu or CentOS7 but macOS is causing problems, what with the migration to gbuild for various modules and how these migrations constantly break macOS. I'll try to start hammering fixing/working-around these, but my recommendation would be that instead of migrating to gbuild willy-nilly, we only do so on (1) modules that NEED it, due to new versions or (2) are so easy and basic that the risk that it breaks other platforms is pretty much nil.

As described before, I can build under CentOS 7 and Debian 8 (Jesse) but
not under Debian 9 (Stretch)

I didn't try Debian 10 (buster yet.
>
> Does that make sense?

Kind regards

--
Mechtilde Stehmann
## Apache OpenOffice
## Freie Office Suite für Linux, MacOSX, Windows
## Debian Developer
## PGP encryption welcome
## F0E3 7F3D C87A 4998 2899  39E7 F287 7BBA 141A AD7F


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Min macOS version for 4.20

Jim Jagielski
In reply to this post by Peter Kovacs-4
It's not really an SDK issue but a minimum target system. Even recent SDKs allow for building for 10.7, BUT (and this is the big but), some frameworks, etc are deprecated when using these newer SDKs (ie: newer Xcodes). Plus, each SDK use a different version of clang, which also factors in. And finally, you have older versions of the C++ lib to worry about (this was a major change with 10.8 -> 10.9 targets)...

So simply saying "use the latest SDK" implies a lack of understanding of the complexities in building such a complex beast for macOS platforms, esp when one considers that 4.20.x contains updated and upgraded code that breaks things as well and how each OS target version and each SDK and each version of Xcode all mangles together.

And the real issue in this regards is about our complimentary community provided builds not about building it "in general"...

> On Jan 8, 2019, at 11:38 AM, [hidden email] wrote:
>
> I am not sure what you mean.
> We should update to use the latest SDK.
> According to Apple it is still posible to build for 10.7  with it.
> Maybe that would be better approach?
>
> I think you have also to look into available flags since there is a lot of change in the last 10 years in compiler terms.
> See mechtildes post and my older post to build on Arch linux.
> So you might well run into different issues with the approach.
>
> Maybe also posting the issued might help. Maybe they are not that bad.
>
> I am sorry that the mac buildbot isnt ready. I could use some help there.
> If anyone has time.
> We currently need to define the brew commands in order to install all the tools we need. Then we can try to build. And the result is public. Which would make it easy for others to check on their work.
>
> Am Dienstag, 8. Januar 2019 schrieb Jim Jagielski:
>> One option we have is that we drop support for macOS 10.7 and older for 4.20.x... this MIGHT help.
>>
>> I can/will test that assumption.
>>
>>> On Jan 8, 2019, at 9:54 AM, Jim Jagielski <[hidden email]> wrote:
>>>
>>> I've started playing around w/ getting 4.2.0-HEAD to build; as expected, so real issues w/ Ubuntu or CentOS7 but macOS is causing problems, what with the migration to gbuild for various modules and how these migrations constantly break macOS. I'll try to start hammering fixing/working-around these, but my recommendation would be that instead of migrating to gbuild willy-nilly, we only do so on (1) modules that NEED it, due to new versions or (2) are so easy and basic that the risk that it breaks other platforms is pretty much nil.
>>>
>>> Does that make sense?
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> --
> Gesendet von meinem Sailfish-Gerät.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Min macOS version for 4.20

Peter Kovacs-3
Okay. I think I get the Idea now. I am sorry that I have tried to help
with my poor knowledge.

I will write again when I manage to explain what I mean.

On 08.01.19 22:40, Jim Jagielski wrote:

> It's not really an SDK issue but a minimum target system. Even recent SDKs allow for building for 10.7, BUT (and this is the big but), some frameworks, etc are deprecated when using these newer SDKs (ie: newer Xcodes). Plus, each SDK use a different version of clang, which also factors in. And finally, you have older versions of the C++ lib to worry about (this was a major change with 10.8 -> 10.9 targets)...
>
> So simply saying "use the latest SDK" implies a lack of understanding of the complexities in building such a complex beast for macOS platforms, esp when one considers that 4.20.x contains updated and upgraded code that breaks things as well and how each OS target version and each SDK and each version of Xcode all mangles together.
>
> And the real issue in this regards is about our complimentary community provided builds not about building it "in general"...
>
>> On Jan 8, 2019, at 11:38 AM, [hidden email] wrote:
>>
>> I am not sure what you mean.
>> We should update to use the latest SDK.
>> According to Apple it is still posible to build for 10.7  with it.
>> Maybe that would be better approach?
>>
>> I think you have also to look into available flags since there is a lot of change in the last 10 years in compiler terms.
>> See mechtildes post and my older post to build on Arch linux.
>> So you might well run into different issues with the approach.
>>
>> Maybe also posting the issued might help. Maybe they are not that bad.
>>
>> I am sorry that the mac buildbot isnt ready. I could use some help there.
>> If anyone has time.
>> We currently need to define the brew commands in order to install all the tools we need. Then we can try to build. And the result is public. Which would make it easy for others to check on their work.
>>
>> Am Dienstag, 8. Januar 2019 schrieb Jim Jagielski:
>>> One option we have is that we drop support for macOS 10.7 and older for 4.20.x... this MIGHT help.
>>>
>>> I can/will test that assumption.
>>>
>>>> On Jan 8, 2019, at 9:54 AM, Jim Jagielski <[hidden email]> wrote:
>>>>
>>>> I've started playing around w/ getting 4.2.0-HEAD to build; as expected, so real issues w/ Ubuntu or CentOS7 but macOS is causing problems, what with the migration to gbuild for various modules and how these migrations constantly break macOS. I'll try to start hammering fixing/working-around these, but my recommendation would be that instead of migrating to gbuild willy-nilly, we only do so on (1) modules that NEED it, due to new versions or (2) are so easy and basic that the risk that it breaks other platforms is pretty much nil.
>>>>
>>>> Does that make sense?
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>> --
>> Gesendet von meinem Sailfish-Gerät.
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Min macOS version for 4.20

Jim Jagielski
No worries at all, and sorry if I come off heavy handed... The macOS platform is problematic, at some level, for AOO because it requires some older tech for it to compile and run. For example, vcl still uses QTkit, which has been deprecated for awhile, which means we can't fully utilize later SDKs, which don't support it, but then we also have file that require newer C++ features, which aren't available in older SDKs, so we're stuck between a rock and a hard place...

My hope, and plan, is that we get a 4.20 out asap... some of that will require reverting some gbuild changes and getting it in a universally buildable state, and branch off 4.20 from there. We can then un-revert that back to trunk.
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: AOO 4.2.0-beta/alpha

Jim Jagielski
In reply to this post by Mechtilde Stehmann-2
In another thread I mentioned a plan... Bringing it up here for a wider audience.

My plan is to branch a 4.20 branch off of trunk as soon as it is relatively buildable on macOS.
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: AOO 4.2.0-beta/alpha

Jim Jagielski
Let me go into more detail here :)

So my plan is to create a 42X branch off of trunk once trunk builds. This branch will now be the development branch for the 4.2.x releases, at which point trunk will be the future development tree (and all gbuild related reversions required for the 4.2.x branch will be re-applied). So the process will be development on trunk w/ back ports to 42X. 4.2.0, 4.2.1, et.al. releases will be branched and tagged from the 42X branch.

Sound OK?

> On Jan 9, 2019, at 10:02 AM, Jim Jagielski <[hidden email]> wrote:
>
> In another thread I mentioned a plan... Bringing it up here for a wider audience.
>
> My plan is to branch a 4.20 branch off of trunk as soon as it is relatively buildable on macOS.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: AOO 4.2.0-beta/alpha

Damjan Jovanovic
In reply to this post by Jim Jagielski
It's not on purpose that it breaks. The last time I used a Mac was in 2005,
and I have zero experience developing for it.

Please post some info regarding these gbuild problems you have and let's
see if I can help.



On Tue, Jan 8, 2019 at 4:54 PM Jim Jagielski <[hidden email]> wrote:

> I've started playing around w/ getting 4.2.0-HEAD to build; as expected,
> so real issues w/ Ubuntu or CentOS7 but macOS is causing problems, what
> with the migration to gbuild for various modules and how these migrations
> constantly break macOS. I'll try to start hammering fixing/working-around
> these, but my recommendation would be that instead of migrating to gbuild
> willy-nilly, we only do so on (1) modules that NEED it, due to new versions
> or (2) are so easy and basic that the risk that it breaks other platforms
> is pretty much nil.
>
> Does that make sense?
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: AOO 4.2.0-beta/alpha

Jim Jagielski
In reply to this post by Jim Jagielski
OK, so I *finally* got a version in which at least the thing builds, but I once again get hit with the instsetoo_native final packing problem that I had a few months ago...

At this point, it seems prudent to branch... I'll do so in a few hours
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: AOO 4.2.0-beta/alpha

Jim Jagielski


> On Jan 9, 2019, at 12:18 PM, Jim Jagielski <[hidden email]> wrote:
>
> OK, so I *finally* got a version in which at least the thing builds, but I once again get hit with the instsetoo_native final packing problem that I had a few months ago...
>

Error: ERROR: /Users/jim/src/asf/AOO420/main/instsetoo_native/unxmaccx.pro/Apache_OpenOffice/dmg/install/ca-XR_inprogress/Apache_OpenOffice_4.2.0_MacOS_x86-64_install_ca-XR/OpenOffice.app/Contents/program/unopkg sync --verbose -env:UNO_JAVA_JFW_ENV_JREHOME=true 2>&1 | failed!

**************************************************
ERROR: ERROR: /Users/jim/src/asf/AOO420/main/instsetoo_native/unxmaccx.pro/Apache_OpenOffice/dmg/install/ca-XR_inprogress/Apache_OpenOffice_4.2.0_MacOS_x86-64_install_ca-XR/OpenOffice.app/Contents/program/unopkg sync --verbose -env:UNO_JAVA_JFW_ENV_JREHOME=true 2>&1 | failed!
in function: register_extensions
**************************************************
in function: register_extensionsstopping log at Wed Jan  9 12:33:26 2019
... removing directory /Users/jim/src/asf/AOO420/main/instsetoo_native/unxmaccx.pro/Apache_OpenOffice/dmg/stripped/bg ...
Error: ERROR: /Users/jim/src/asf/AOO420/main/instsetoo_native/unxmaccx.pro/Apache_OpenOffice/dmg/install/bg_inprogress/Apache_OpenOffice_4.2.0_MacOS_x86-64_install_bg/OpenOffice.app/Contents/program/unopkg sync --verbose -env:UNO_JAVA_JFW_ENV_JREHOME=true 2>&1 | failed!

**************************************************
ERROR: ERROR: /Users/jim/src/asf/AOO420/main/instsetoo_native/unxmaccx.pro/Apache_OpenOffice/dmg/install/bg_inprogress/Apache_OpenOffice_4.2.0_MacOS_x86-64_install_bg/OpenOffice.app/Contents/program/unopkg sync --verbose -env:UNO_JAVA_JFW_ENV_JREHOME=true 2>&1 | failed!
in function: register_extensions
**************************************************
in function: register_extensionsstopping log at Wed Jan  9 12:33:26 2019
dmake:  Error code 255, while making 'openoffice_ca-XR.dmg'

1 module(s):
        instsetoo_native
need(s) to be rebuilt

Reason(s):

ERROR: error 65280 occurred while making /Users/jim/src/asf/AOO420/main/instsetoo_native/util



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: AOO 4.2.0-beta/alpha

Marcus (OOo)
In reply to this post by Jim Jagielski
Am 09.01.19 um 16:12 schrieb Jim Jagielski:
> Let me go into more detail here :)
>
> So my plan is to create a 42X branch off of trunk once trunk builds. This branch will now be the development branch for the 4.2.x releases, at which point trunk will be the future development tree (and all gbuild related reversions required for the 4.2.x branch will be re-applied). So the process will be development on trunk w/ back ports to 42X. 4.2.0, 4.2.1, et.al. releases will be branched and tagged from the 42X branch.
>
> Sound OK?

seems so. When I understood this correct, then the following graphical
explaination should support this. So, let me try:



Trunk
|
|---> New branch for 4.2.0
|     |
|     |---> New branch for 4.2.1
|           |
|           |---> New branch for 4.2.2
|                 |
|                 |---> ...
|
|---> New branch for 4.3.0
|     |
|     |---> New branch for 4.3.1
|           |
|           |---> New branch for 4.3.2
|                 |
|                 |---> ...
.
.
.
|---> New branch for 5.0.0
|     |
|     |---> ...
\/



Ciao

Marcus



>> On Jan 9, 2019, at 10:02 AM, Jim Jagielski <[hidden email]> wrote:
>>
>> In another thread I mentioned a plan... Bringing it up here for a wider audience.
>>
>> My plan is to branch a 4.20 branch off of trunk as soon as it is relatively buildable on macOS.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: AOO 4.2.0-beta/alpha

Jim Jagielski
Almost:

Trunk
  |
  |
  |----> New branch for 4.2.x
  |         |
  |         |---> Branch and/or Tag for 4.2.0
  |         |
  |         |---> Branch and/or Tag for 4.2.1

etc

That is, 4.2.2, for example, is not branched from 4.2.1 but rather from the ever existing 4.2.x branch. Alternatively, all 4.2.x releases are branches off of the 42X branch, instead of 4.2.1 being a branch of 4.2.0, and 4.2.2 being a branch of 4.2.1 and 4.2.3 being a branch of 4.2.2, etc...

This allows a nice mix of CTR and RTC processes

> On Jan 9, 2019, at 3:07 PM, Marcus <[hidden email]> wrote:
>
> Am 09.01.19 um 16:12 schrieb Jim Jagielski:
>> Let me go into more detail here :)
>> So my plan is to create a 42X branch off of trunk once trunk builds. This branch will now be the development branch for the 4.2.x releases, at which point trunk will be the future development tree (and all gbuild related reversions required for the 4.2.x branch will be re-applied). So the process will be development on trunk w/ back ports to 42X. 4.2.0, 4.2.1, et.al. releases will be branched and tagged from the 42X branch.
>> Sound OK?
>
> seems so. When I understood this correct, then the following graphical explaination should support this. So, let me try:
>
>
>
> Trunk
> |
> |---> New branch for 4.2.0
> |     |
> |     |---> New branch for 4.2.1
> |           |
> |           |---> New branch for 4.2.2
> |                 |
> |                 |---> ...
> |
> |---> New branch for 4.3.0
> |     |
> |     |---> New branch for 4.3.1
> |           |
> |           |---> New branch for 4.3.2
> |                 |
> |                 |---> ...
> .
> .
> .
> |---> New branch for 5.0.0
> |     |
> |     |---> ...
> \/
>
>
>
> Ciao
>
> Marcus
>
>
>
>>> On Jan 9, 2019, at 10:02 AM, Jim Jagielski <[hidden email]> wrote:
>>>
>>> In another thread I mentioned a plan... Bringing it up here for a wider audience.
>>>
>>> My plan is to branch a 4.20 branch off of trunk as soon as it is relatively buildable on macOS.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: AOO 4.2.0-beta/alpha

Marcus (OOo)
Am 09.01.19 um 21:15 schrieb Jim Jagielski:

> Almost:
>
> Trunk
>    |
>    |
>    |----> New branch for 4.2.x
>    |         |
>    |         |---> Branch and/or Tag for 4.2.0
>    |         |
>    |         |---> Branch and/or Tag for 4.2.1
>
> etc

ah, OK. Good to have this now clarified. :-)

Thanks

Marcus



>> On Jan 9, 2019, at 3:07 PM, Marcus <[hidden email]> wrote:
>>
>> Am 09.01.19 um 16:12 schrieb Jim Jagielski:
>>> Let me go into more detail here :)
>>> So my plan is to create a 42X branch off of trunk once trunk builds. This branch will now be the development branch for the 4.2.x releases, at which point trunk will be the future development tree (and all gbuild related reversions required for the 4.2.x branch will be re-applied). So the process will be development on trunk w/ back ports to 42X. 4.2.0, 4.2.1, et.al. releases will be branched and tagged from the 42X branch.
>>> Sound OK?
>>
>> seems so. When I understood this correct, then the following graphical explaination should support this. So, let me try:
>>
>>
>>
>> Trunk
>> |
>> |---> New branch for 4.2.0
>> |     |
>> |     |---> New branch for 4.2.1
>> |           |
>> |           |---> New branch for 4.2.2
>> |                 |
>> |                 |---> ...
>> |
>> |---> New branch for 4.3.0
>> |     |
>> |     |---> New branch for 4.3.1
>> |           |
>> |           |---> New branch for 4.3.2
>> |                 |
>> |                 |---> ...
>> .
>> .
>> .
>> |---> New branch for 5.0.0
>> |     |
>> |     |---> ...
>> \/
>>
>>
>>
>> Ciao
>>
>> Marcus
>>
>>
>>
>>>> On Jan 9, 2019, at 10:02 AM, Jim Jagielski <[hidden email]> wrote:
>>>>
>>>> In another thread I mentioned a plan... Bringing it up here for a wider audience.
>>>>
>>>> My plan is to branch a 4.20 branch off of trunk as soon as it is relatively buildable on macOS.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: AOO 4.2.0-beta/alpha

Damjan Jovanovic
In reply to this post by Jim Jagielski
That register_extensions function that seems to break is in
main/solenv/bin/modules/installer/simplepackage.pm
I suggest changing it to print out some debugging info and then "build
--from instsetoo_native".

On Wed, Jan 9, 2019 at 7:34 PM Jim Jagielski <[hidden email]> wrote:

>
>
> > On Jan 9, 2019, at 12:18 PM, Jim Jagielski <[hidden email]> wrote:
> >
> > OK, so I *finally* got a version in which at least the thing builds, but
> I once again get hit with the instsetoo_native final packing problem that I
> had a few months ago...
> >
>
> Error: ERROR: /Users/jim/src/asf/AOO420/main/instsetoo_native/
> unxmaccx.pro/Apache_OpenOffice/dmg/install/ca-XR_inprogress/Apache_OpenOffice_4.2.0_MacOS_x86-64_install_ca-XR/OpenOffice.app/Contents/program/unopkg
> sync --verbose -env:UNO_JAVA_JFW_ENV_JREHOME=true 2>&1 | failed!
>
> **************************************************
> ERROR: ERROR: /Users/jim/src/asf/AOO420/main/instsetoo_native/
> unxmaccx.pro/Apache_OpenOffice/dmg/install/ca-XR_inprogress/Apache_OpenOffice_4.2.0_MacOS_x86-64_install_ca-XR/OpenOffice.app/Contents/program/unopkg
> sync --verbose -env:UNO_JAVA_JFW_ENV_JREHOME=true 2>&1 | failed!
> in function: register_extensions
> **************************************************
> in function: register_extensionsstopping log at Wed Jan  9 12:33:26 2019
> ... removing directory /Users/jim/src/asf/AOO420/main/instsetoo_native/
> unxmaccx.pro/Apache_OpenOffice/dmg/stripped/bg ...
> Error: ERROR: /Users/jim/src/asf/AOO420/main/instsetoo_native/
> unxmaccx.pro/Apache_OpenOffice/dmg/install/bg_inprogress/Apache_OpenOffice_4.2.0_MacOS_x86-64_install_bg/OpenOffice.app/Contents/program/unopkg
> sync --verbose -env:UNO_JAVA_JFW_ENV_JREHOME=true 2>&1 | failed!
>
> **************************************************
> ERROR: ERROR: /Users/jim/src/asf/AOO420/main/instsetoo_native/
> unxmaccx.pro/Apache_OpenOffice/dmg/install/bg_inprogress/Apache_OpenOffice_4.2.0_MacOS_x86-64_install_bg/OpenOffice.app/Contents/program/unopkg
> sync --verbose -env:UNO_JAVA_JFW_ENV_JREHOME=true 2>&1 | failed!
> in function: register_extensions
> **************************************************
> in function: register_extensionsstopping log at Wed Jan  9 12:33:26 2019
> dmake:  Error code 255, while making 'openoffice_ca-XR.dmg'
>
> 1 module(s):
>         instsetoo_native
> need(s) to be rebuilt
>
> Reason(s):
>
> ERROR: error 65280 occurred while making
> /Users/jim/src/asf/AOO420/main/instsetoo_native/util
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: AOO 4.2.0-beta/alpha

Mechtilde Stehmann-2
Hello

Am 10.01.19 um 03:05 schrieb Damjan Jovanovic:
> That register_extensions function that seems to break is in
> main/solenv/bin/modules/installer/simplepackage.pm
> I suggest changing it to print out some debugging info and then "build
> --from instsetoo_native".
>
My build under Debian 9 also breaks at instsetoo_native in function call_epm

Kind regards

--
Mechtilde Stehmann
## Apache OpenOffice
## Freie Office Suite für Linux, MacOSX, Windows
## Debian Developer
## PGP encryption welcome
## F0E3 7F3D C87A 4998 2899  39E7 F287 7BBA 141A AD7F


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: AOO 4.2.0-beta/alpha

Jim Jagielski
In reply to this post by Damjan Jovanovic
Ahh... something w/ the cppuhelper stuff. Obviously, some UDK issue I'm thinking...

  76.372903 : lang : ######################################################
  76.372943 : lang : Registering extensions:
  76.372991 : lang : ######################################################
  76.381173 : info : ... current dir: /Users/jim/src/asf/AOO42X/main/instsetoo_native/unxmaccx.pro/Apache_OpenOffice/dmg/install/en-US_inprogress/Apache_OpenOffice_4.2.0_MacOS_x86-64_install_en-US/OpenOffice.app/Contents/MacOS ...
  76.381393 : lang : Current dir: /Users/jim/src/asf/AOO42X/main/instsetoo_native/unxmaccx.pro/Apache_OpenOffice/dmg/install/en-US_inprogress/Apache_OpenOffice_4.2.0_MacOS_x86-64_install_en-US/OpenOffice.app/Contents/MacOS
  76.381469 : info : ... /Users/jim/src/asf/AOO42X/main/instsetoo_native/unxmaccx.pro/Apache_OpenOffice/dmg/install/en-US_inprogress/Apache_OpenOffice_4.2.0_MacOS_x86-64_install_en-US/OpenOffice.app/Contents/program/unopkg sync --verbose -env:UNO_JAVA_JFW_ENV_JREHOME=true 2>&1 | ...
  76.381565 : lang : Systemcall: /Users/jim/src/asf/AOO42X/main/instsetoo_native/unxmaccx.pro/Apache_OpenOffice/dmg/install/en-US_inprogress/Apache_OpenOffice_4.2.0_MacOS_x86-64_install_en-US/OpenOffice.app/Contents/program/unopkg sync --verbose -env:UNO_JAVA_JFW_ENV_JREHOME=true 2>&1 |
  76.395759 : lang : dyld: Library not loaded: @loader_path/libuno_cppuhelpers5abi.dylib
  76.395961 : lang :   Referenced from: /Users/jim/src/asf/AOO42X/main/instsetoo_native/unxmaccx.pro/Apache_OpenOffice/dmg/install/en-US_inprogress/Apache_OpenOffice_4.2.0_MacOS_x86-64_install_en-US/OpenOffice.app/Contents/program/libunopkgapp.dylib
  76.396012 : lang :   Reason: image not found
  76.396074 : lang : ERROR: Could not execute "/Users/jim/src/asf/AOO42X/main/instsetoo_native/unxmaccx.pro/Apache_OpenOffice/dmg/install/en-US_inprogress/Apache_OpenOffice_4.2.0_MacOS_x86-64_install_en-US/OpenOffice.app/Contents/program/unopkg sync --verbose -env:UNO_JAVA_JFW_ENV_JREHOME=true 2>&1 |"!
Exitcode: '6'

Yeppers... for sure it's the udk versioning, which is more a Linux thing than a macOS (or Windows) thing.

Will look into either hacking around it or something else. I thought I had fixed it. Obviously not :(

> On Jan 9, 2019, at 9:05 PM, Damjan Jovanovic <[hidden email]> wrote:
>
> That register_extensions function that seems to break is in
> main/solenv/bin/modules/installer/simplepackage.pm
> I suggest changing it to print out some debugging info and then "build
> --from instsetoo_native".
>
> On Wed, Jan 9, 2019 at 7:34 PM Jim Jagielski <[hidden email]> wrote:
>
>>
>>
>>> On Jan 9, 2019, at 12:18 PM, Jim Jagielski <[hidden email]> wrote:
>>>
>>> OK, so I *finally* got a version in which at least the thing builds, but
>> I once again get hit with the instsetoo_native final packing problem that I
>> had a few months ago...
>>>
>>
>> Error: ERROR: /Users/jim/src/asf/AOO420/main/instsetoo_native/
>> unxmaccx.pro/Apache_OpenOffice/dmg/install/ca-XR_inprogress/Apache_OpenOffice_4.2.0_MacOS_x86-64_install_ca-XR/OpenOffice.app/Contents/program/unopkg
>> sync --verbose -env:UNO_JAVA_JFW_ENV_JREHOME=true 2>&1 | failed!
>>
>> **************************************************
>> ERROR: ERROR: /Users/jim/src/asf/AOO420/main/instsetoo_native/
>> unxmaccx.pro/Apache_OpenOffice/dmg/install/ca-XR_inprogress/Apache_OpenOffice_4.2.0_MacOS_x86-64_install_ca-XR/OpenOffice.app/Contents/program/unopkg
>> sync --verbose -env:UNO_JAVA_JFW_ENV_JREHOME=true 2>&1 | failed!
>> in function: register_extensions
>> **************************************************
>> in function: register_extensionsstopping log at Wed Jan  9 12:33:26 2019
>> ... removing directory /Users/jim/src/asf/AOO420/main/instsetoo_native/
>> unxmaccx.pro/Apache_OpenOffice/dmg/stripped/bg ...
>> Error: ERROR: /Users/jim/src/asf/AOO420/main/instsetoo_native/
>> unxmaccx.pro/Apache_OpenOffice/dmg/install/bg_inprogress/Apache_OpenOffice_4.2.0_MacOS_x86-64_install_bg/OpenOffice.app/Contents/program/unopkg
>> sync --verbose -env:UNO_JAVA_JFW_ENV_JREHOME=true 2>&1 | failed!
>>
>> **************************************************
>> ERROR: ERROR: /Users/jim/src/asf/AOO420/main/instsetoo_native/
>> unxmaccx.pro/Apache_OpenOffice/dmg/install/bg_inprogress/Apache_OpenOffice_4.2.0_MacOS_x86-64_install_bg/OpenOffice.app/Contents/program/unopkg
>> sync --verbose -env:UNO_JAVA_JFW_ENV_JREHOME=true 2>&1 | failed!
>> in function: register_extensions
>> **************************************************
>> in function: register_extensionsstopping log at Wed Jan  9 12:33:26 2019
>> dmake:  Error code 255, while making 'openoffice_ca-XR.dmg'
>>
>> 1 module(s):
>>        instsetoo_native
>> need(s) to be rebuilt
>>
>> Reason(s):
>>
>> ERROR: error 65280 occurred while making
>> /Users/jim/src/asf/AOO420/main/instsetoo_native/util
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: AOO 4.2.0-beta/alpha

Andrea Pescetti-2
In reply to this post by Jim Jagielski
On 09/01/2019 Jim Jagielski wrote:
> Trunk
>    |----> New branch for 4.2.x
>    |         |---> Branch and/or Tag for 4.2.0
>    |         |---> Branch and/or Tag for 4.2.1
> That is, 4.2.2, for example, is not branched from 4.2.1 but rather from the ever existing 4.2.x branch.

This can work, provided we agree to always use "svn merge" to port
commits between branches, or writing commit logs appropriately in the
(hopefully few) cases when this is not possible.

(I'm still catching up with mail, so someone else may have already
suggested this; but I felt it was important to specify this, as we still
have some issues in 4.1.x due to replicating code without merging properly).

Regards,
   Andrea.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]