Re: Update to python-2.17
Hi again; On 2020-01-04 05:16, Matthias Seidel wrote: > Hi Pedro, > > Thanks! > > Unfortunately the build process just stops at some point (on Windows), > no error codes I could give you. The problems are usually related to getting the patches applied correctly. There can be no hunks or mismatches. I tested them one by one and they should be OK now. Same place: https://people.apache.org/~pfg/patches/patch-python-2.17.diff > According to https://www.python.org/downloads/release/python-2717/ this > is the "penultimate" release, so maybe there will be a final 2.7.18? Yes, there will be a final release in a couple of months, but most linux distributions (and FreeBSD) are already deprecating py27 and anything that depends on it. Thanks for your patience! Pedro. > Regards, > > Matthias > > Am 04.01.20 um 02:41 schrieb Pedro Giffuni: >> Hi Matthias; >> >> Sorry about that. I could've tested better the patch. I will fix the >> obvious issues and will let you guys know. >> >> >> Pedro. >> >> ps. It may take me a while though, I am getting busy very fast :( >> >> On 2020-01-01 21:30, Pedro Giffuni wrote: >>> Hello AOO devs and best wishes for the New Year! >>> >>> Well ... time has passed and Python 2 is now deprecated! >>> >>> I have a patch here to update AOO 4.2's version of Python to the latest >>> (perhaps last) release in that line: >>> >>> http://people.apache.org/~pfg/patches/patch-python-2.17.diff >>> >>> This is a remake of the previous update that I had made for >>> cpython-2.16, but which no one tested ! I currently lack an AOO setup >>> with git so please someone else will have to test and commit. >>> >>> On the near term, we really should update to Python 3, but that will be >>> challenging for the build system since it requires a newer version of >>> the MS compiler. >>> >>> Building with an external python is also currently broken for python >>> versions >= 3.6. >>> >>> Regards, >>> >>> Pedro. >>> - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: OpenOffice trunc Assertion Error
+1
> On Jan 8, 2020, at 9:02 PM, Patricia Shanahan wrote:
>
> On 1/8/2020 5:55 PM, Dave Fisher wrote:
>> Hi -
>> See inline
>> Sent from my iPhone
>>> On Jan 8, 2020, at 3:44 PM, Peter Kovacs wrote:
>>>
>>> Hello again,
>>>
>>> hope I do not annoy anyone, with my questions.
>>> I have looked deeper in the issue using OpenGrok.
>>>
>>> Now the Issue seems pretty clear.
>>> We have only the function signatures:
>>>
>>> file: atkwrapper.hxx
>>> 85 AtkObject *atk_object_wrapper_new(
>>> 86 const ::com::sun::star::uno::Reference<
>>> ::com::sun::star::accessibility::XAccessible >& rxAccessible,
>>> 87 AtkObject* parent = NULL );
>>>
>>> And we have the call for the Function just above this one
>>> (file:atkwrapper.cxx):
>>> AtkObject *
>>> atk_object_wrapper_ref( const uno::Reference< accessibility::XAccessible >
>>> &rxAccessible, bool create )
>>> {
>>>g_return_val_if_fail( rxAccessible.get() != NULL, NULL );
>>>
>>>AtkObject *obj = ooo_wrapper_registry_get(rxAccessible);
>>>if( obj )
>>>{
>>>g_object_ref( obj );
>>>return obj;
>>>}
>>>
>>>if( create )
>>>return atk_object_wrapper_new( rxAccessible );
>>>
>>>return NULL;
>>> }
>>>
>>> So this is a bit confusing.
>>>
>>> Anyone objects if I refactor the above code so we have only one return
>>> statement at the end of the function? I think it is annoying and you
>>> quickly miss the exitpoints of the function.
>> You are doing this to make a code quality tool quiet?
>> You will need to carefully understand how to add else clauses to the code.
>> If the functions is long it will be tedious. Bad clauses will create very
>> subtle bugs. I would want to build often
>> Such changes may also make these functions slightly slower.
>> If you do this then I think you’ll want someone to review the diff.
>
> For some functions, single return is natural and clear. For others, the code
> is simpler, more readable, and clearer with multiple returns. I think this
> may be a case where I would prefer multiple returns, but I would be
> interested in seeing what it looks like if refactored, and open to the
> possibility that it might be clearer.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
Re: Time for some test tarballs/developer releases for 4.1.8-dev and 4.2.0-devm2
Hi Jim, Am 08.01.20 um 14:42 schrieb Jim Jagielski: >> On Jan 7, 2020, at 11:35 AM, Matthias Seidel >> wrote: >> >> Back to the topic: >> >> Personally I don't see a reason for a 4.1.8 dev release. >> It is only a micro update and I do build test versions (for Windows) on >> a regular base [1]. > I agree that from a development/bug/security PoV, a 4.1.8 is likely "not > needed". However, since we are now able to sign macOS releases and, I think, > Windows ones as well, doing a 4.1.8 simply to have current signed versions of > 4.1.x available does have some allure. I also would prefer to sign a Windows dev build (be it 4.1.X or 4.2.X) before we do that in a release situation. But remember, Windows signing costs money. Regards, Matthias >> But I am OK with 4.2.0 dev2, although I would like to have one >> additional release blocker [2] fixed for that. >> However we should include some new languages in the release process >> (this list can be discussed): >> >> - Armenian (100% UI) >> - Estonian (100% UI) >> - Kabyle (95% UI) >> - Ukrainian (85% UI) >> - Oromo (85% UI) >> >> Regards, >> >>Matthias >> >> [1] https://home.apache.org/~mseidel/AOO-builds/AOO-418-Test/ >> [2] https://s.apache.org/gL35 >> >> Am 07.01.20 um 00:14 schrieb Matthias Seidel: >>> Hi all, >>> >>> On Ubuntu 19.10 this could be solved by installing openjdk-8-jdk. (I >>> also installed mesa-utils but I don't think it is needed) >>> >>> Normally I would think that AOO can operate without Java, but that is >>> definitely something for the Release Notes. >>> >>> Regards, >>> >>>Matthias >>> >>> Am 06.01.20 um 16:54 schrieb Matthias Seidel: Hi Jim, Am 06.01.20 um 16:18 schrieb Jim Jagielski: > Hmmm... Is this using one of our test builds, something from our > buildbots, or your own build? In my case (Ubuntu 19.10) it was a build from our bots. I am just setting up a new VM and will do further tests. On Ubuntu 18.04 there are no problems, but 20.04 will be released in April. Regards, Matthias >> On Jan 5, 2020, at 2:31 PM, Matthias Seidel >> wrote: >> >> Hi Jim, >> >> Just a short note: >> >> It seems that AOO crashes immediately at startup on newer Linux distros >> like CentOS 8, Fedora 31 or Ubuntu 19.10. >> >> We should investigate that before we think of new DevBuild. >> >> Regards, >> >> Matthias >> >> Am 03.01.20 um 18:22 schrieb Jim Jagielski: >>> Sub sez it all. Yeah, I know we have some bugz to squash, but maybe >>> getingt some feedback on the current state is helpful too. >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >>> For additional commands, e-mail: dev-h...@openoffice.apache.org >>> >>> > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > smime.p7s Description: S/MIME Cryptographic Signature
Re: OpenOffice trunc Assertion Error
At least checking bz and documenting the findings should be done.
And the refactoring I want to do. I already know how the code should look like.
Am 9. Januar 2020 10:57:46 MEZ schrieb Patricia Shanahan :
>What happens if you ignore the assertion and carry on?
>
>I had to do that for several assertions when debugging some security
>problems - the problems I was working were higher priority.
>
>On 1/9/2020 1:35 AM, Peter Kovacs wrote:
>> Hi,
>>
>> To be clear the Assert is a different issue and needs more research.
>> The Assert claims a different object is to be used for top level
>objects. Since the issue pops up on top-level object, right at start, I
>assume something is not as it should be designed. The answers on the
>list suggest that the knowledge is not present. So I need to do digging
>first before I can say what to do. I think it may be worth open an
>issue and collect all informations there.
>>
>> Thanks pat for the review support I appreciate it.
>>
>>
>> All the best
>> Peter
>>
>> Am 9. Januar 2020 02:55:04 MEZ schrieb Dave Fisher
>:
>>> Hi -
>>>
>>> See inline
>>>
>>> Sent from my iPhone
>>>
On Jan 8, 2020, at 3:44 PM, Peter Kovacs wrote:
Hello again,
hope I do not annoy anyone, with my questions.
I have looked deeper in the issue using OpenGrok.
Now the Issue seems pretty clear.
We have only the function signatures:
file: atkwrapper.hxx
85 AtkObject *atk_object_wrapper_new(
86 const ::com::sun::star::uno::Reference<
>>> ::com::sun::star::accessibility::XAccessible >& rxAccessible,
87 AtkObject* parent = NULL );
And we have the call for the Function just above this one
>>> (file:atkwrapper.cxx):
AtkObject *
atk_object_wrapper_ref( const uno::Reference<
>>> accessibility::XAccessible > &rxAccessible, bool create )
{
g_return_val_if_fail( rxAccessible.get() != NULL, NULL );
AtkObject *obj = ooo_wrapper_registry_get(rxAccessible);
if( obj )
{
g_object_ref( obj );
return obj;
}
if( create )
return atk_object_wrapper_new( rxAccessible );
return NULL;
}
So this is a bit confusing.
Anyone objects if I refactor the above code so we have only one
>>> return statement at the end of the function? I think it is annoying
>and
>>> you quickly miss the exitpoints of the function.
>>>
>>> You are doing this to make a code quality tool quiet?
>>>
>>> You will need to carefully understand how to add else clauses to the
>>> code. If the functions is long it will be tedious. Bad clauses will
>>> create very subtle bugs. I would want to build often
>>>
>>> Such changes may also make these functions slightly slower.
>>>
>>> If you do this then I think you’ll want someone to review the diff.
>>>
>>> Apologies if I’m being negative or discouraging.
>>>
>>> Best Regards,
>>> Dave
>>>
All the Best
Peter
> On 2020/01/07 21:27:44, Peter Kovacs
>wrote:
>>>
> Hello all,
>
> I have build OpenOffice from trunc with debug options. When
>started
>>> I
> get an Assertion Error.
> Error: assertion failed!
> From File /home/legine/AOO/main/vcl/unx/gtk/a11y/atkwrapper.cxx
>at
>>> Line
> 874
> Abort ? (Yes=abort / No=ignore / Cancel=core dump)
>
> Code in Question is:
> /* gail_focus_tracker remembers the focused object at the first
> * parent in the hierarchy that is a Gtk+ widget, but
>at
>>> the
> time the
> * event gets processed (at idle), it may be too late
>to
>>>
> create the
> * hierarchy, so doing it now ..
> */
> uno::Reference< accessibility::XAccessible > xParent(
> xContext->getAccessibleParent() );
>
> /* The top-level objects should never be of this
>class
>>> */
> OSL_ASSERT( xParent.is() );
>
>
> The Wrapper is not an object right? Only a collection of functions
>>> or do
> I read this wrong?
>
> Thx for some help.
>
> All the Best
> Peter
>
>
>>>
>-
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>
>-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
>>>
>>>
>>>
>-
>>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>
>
>-
>To unsubscribe, e-mail
Re: OpenOffice trunc Assertion Error
What happens if you ignore the assertion and carry on?
I had to do that for several assertions when debugging some security
problems - the problems I was working were higher priority.
On 1/9/2020 1:35 AM, Peter Kovacs wrote:
Hi,
To be clear the Assert is a different issue and needs more research.
The Assert claims a different object is to be used for top level objects. Since
the issue pops up on top-level object, right at start, I assume something is
not as it should be designed. The answers on the list suggest that the
knowledge is not present. So I need to do digging first before I can say what
to do. I think it may be worth open an issue and collect all informations there.
Thanks pat for the review support I appreciate it.
All the best
Peter
Am 9. Januar 2020 02:55:04 MEZ schrieb Dave Fisher :
Hi -
See inline
Sent from my iPhone
On Jan 8, 2020, at 3:44 PM, Peter Kovacs wrote:
Hello again,
hope I do not annoy anyone, with my questions.
I have looked deeper in the issue using OpenGrok.
Now the Issue seems pretty clear.
We have only the function signatures:
file: atkwrapper.hxx
85 AtkObject *atk_object_wrapper_new(
86 const ::com::sun::star::uno::Reference<
::com::sun::star::accessibility::XAccessible >& rxAccessible,
87 AtkObject* parent = NULL );
And we have the call for the Function just above this one
(file:atkwrapper.cxx):
AtkObject *
atk_object_wrapper_ref( const uno::Reference<
accessibility::XAccessible > &rxAccessible, bool create )
{
g_return_val_if_fail( rxAccessible.get() != NULL, NULL );
AtkObject *obj = ooo_wrapper_registry_get(rxAccessible);
if( obj )
{
g_object_ref( obj );
return obj;
}
if( create )
return atk_object_wrapper_new( rxAccessible );
return NULL;
}
So this is a bit confusing.
Anyone objects if I refactor the above code so we have only one
return statement at the end of the function? I think it is annoying and
you quickly miss the exitpoints of the function.
You are doing this to make a code quality tool quiet?
You will need to carefully understand how to add else clauses to the
code. If the functions is long it will be tedious. Bad clauses will
create very subtle bugs. I would want to build often
Such changes may also make these functions slightly slower.
If you do this then I think you’ll want someone to review the diff.
Apologies if I’m being negative or discouraging.
Best Regards,
Dave
All the Best
Peter
On 2020/01/07 21:27:44, Peter Kovacs wrote:
Hello all,
I have build OpenOffice from trunc with debug options. When started
I
get an Assertion Error.
Error: assertion failed!
From File /home/legine/AOO/main/vcl/unx/gtk/a11y/atkwrapper.cxx at
Line
874
Abort ? (Yes=abort / No=ignore / Cancel=core dump)
Code in Question is:
/* gail_focus_tracker remembers the focused object at the first
* parent in the hierarchy that is a Gtk+ widget, but at
the
time the
* event gets processed (at idle), it may be too late to
create the
* hierarchy, so doing it now ..
*/
uno::Reference< accessibility::XAccessible > xParent(
xContext->getAccessibleParent() );
/* The top-level objects should never be of this class
*/
OSL_ASSERT( xParent.is() );
The Wrapper is not an object right? Only a collection of functions
or do
I read this wrong?
Thx for some help.
All the Best
Peter
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: OpenOffice trunc Assertion Error
Hi,
To be clear the Assert is a different issue and needs more research.
The Assert claims a different object is to be used for top level objects. Since
the issue pops up on top-level object, right at start, I assume something is
not as it should be designed. The answers on the list suggest that the
knowledge is not present. So I need to do digging first before I can say what
to do. I think it may be worth open an issue and collect all informations
there.
Thanks pat for the review support I appreciate it.
All the best
Peter
Am 9. Januar 2020 02:55:04 MEZ schrieb Dave Fisher :
>Hi -
>
>See inline
>
>Sent from my iPhone
>
>> On Jan 8, 2020, at 3:44 PM, Peter Kovacs wrote:
>>
>> Hello again,
>>
>> hope I do not annoy anyone, with my questions.
>> I have looked deeper in the issue using OpenGrok.
>>
>> Now the Issue seems pretty clear.
>> We have only the function signatures:
>>
>> file: atkwrapper.hxx
>> 85 AtkObject *atk_object_wrapper_new(
>> 86 const ::com::sun::star::uno::Reference<
>::com::sun::star::accessibility::XAccessible >& rxAccessible,
>> 87 AtkObject* parent = NULL );
>>
>> And we have the call for the Function just above this one
>(file:atkwrapper.cxx):
>> AtkObject *
>> atk_object_wrapper_ref( const uno::Reference<
>accessibility::XAccessible > &rxAccessible, bool create )
>> {
>>g_return_val_if_fail( rxAccessible.get() != NULL, NULL );
>>
>>AtkObject *obj = ooo_wrapper_registry_get(rxAccessible);
>>if( obj )
>>{
>>g_object_ref( obj );
>>return obj;
>>}
>>
>>if( create )
>>return atk_object_wrapper_new( rxAccessible );
>>
>>return NULL;
>> }
>>
>> So this is a bit confusing.
>>
>> Anyone objects if I refactor the above code so we have only one
>return statement at the end of the function? I think it is annoying and
>you quickly miss the exitpoints of the function.
>
>You are doing this to make a code quality tool quiet?
>
>You will need to carefully understand how to add else clauses to the
>code. If the functions is long it will be tedious. Bad clauses will
>create very subtle bugs. I would want to build often
>
>Such changes may also make these functions slightly slower.
>
>If you do this then I think you’ll want someone to review the diff.
>
>Apologies if I’m being negative or discouraging.
>
>Best Regards,
>Dave
>
>>
>> All the Best
>> Peter
>>
>>> On 2020/01/07 21:27:44, Peter Kovacs wrote:
>
>>> Hello all,
>>>
>>> I have build OpenOffice from trunc with debug options. When started
>I
>>> get an Assertion Error.
>>> Error: assertion failed!
>>> From File /home/legine/AOO/main/vcl/unx/gtk/a11y/atkwrapper.cxx at
>Line
>>> 874
>>> Abort ? (Yes=abort / No=ignore / Cancel=core dump)
>>>
>>> Code in Question is:
>>> /* gail_focus_tracker remembers the focused object at the first
>>> * parent in the hierarchy that is a Gtk+ widget, but at
>the
>>> time the
>>> * event gets processed (at idle), it may be too late to
>
>>> create the
>>> * hierarchy, so doing it now ..
>>> */
>>> uno::Reference< accessibility::XAccessible > xParent(
>>> xContext->getAccessibleParent() );
>>>
>>> /* The top-level objects should never be of this class
>*/
>>> OSL_ASSERT( xParent.is() );
>>>
>>>
>>> The Wrapper is not an object right? Only a collection of functions
>or do
>>> I read this wrong?
>>>
>>> Thx for some help.
>>>
>>> All the Best
>>> Peter
>>>
>>>
>-
>>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>>
>>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>
>
>
>-
>To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>For additional commands, e-mail: dev-h...@openoffice.apache.org
