Native Language Confederation. Community Council

2018-07-04 Thread Алексей Евгеньевич Харламенков
Dear Colleagues! good afternoon.

The http://www.openoffice.org/native-lang/ "Native Language Confederation" in 
the NLC Mission refers to the Council of the Community and provides a link to 
the Council's website (http://council.openoffice.org/) and a list of selected 
members of the Council of the NLC (http://council.openoffice.org/#nlc)

The Community Council page gives an error of 404, because it does not exist.

Question:
Does the Community Council no longer exist?
Or is "Native Language Confederation" no longer relevant?

I think that the information on the official website should be up-to-date and 
error-free 404.


-- 
Yours faithfully,
Aleksey Evgenievich Harlamenkov.

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: Native Language Confederation. Community Council

2018-07-04 Thread Marcus

Am 04.07.2018 um 13:58 schrieb Алексей Евгеньевич Харламенков:

The http://www.openoffice.org/native-lang/ "Native Language Confederation" in 
the NLC Mission refers to the Council of the Community and provides a link to the 
Council's website (http://council.openoffice.org/) and a list of selected members of the 
Council of the NLC (http://council.openoffice.org/#nlc)

The Community Council page gives an error of 404, because it does not exist.

Question:
Does the Community Council no longer exist?
Or is "Native Language Confederation" no longer relevant?


both. Now it's only the L10N which counts.


I think that the information on the official website should be up-to-date and 
error-free 404.


Thanks for your hint. As the re-work is taking more time than we have at 
the moment, I've just deleted the dead links for now.


Marcus


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: A 4.1.6 Release

2018-07-04 Thread Marcus

Am 04.07.2018 um 08:23 schrieb Peter Kovacs:
I think Jim is referring to the gstreamer situation, where we decided 
that we skip CentOS6 more or less for 4.2.0.And one argument was, if 
they want something they should support us. This is not showing sympathy 
for a small user group that uses very old software for 2 more years 
until they have to move to CentOS 7. I personally think that the 
gstreamer Topic can be solved after we have released a beta version. 
Damjan and I have pointed out a lot of possible ways to deal with the 
issue. Just for now I think we have other problems then gstreamer in 
4.2.0. I think it is my fault that I put that argument so much in the 
front line, but that stuck for me.


In the last months we had a drop in activity. And more then one topic 
received not the attention it deserved. I would not conclude that anyone 
has stopped caring at this point in time.



Let us conclude for now:
4.1.x is still in maintenance. And in my opinion we could think of 
maintaining it until 2020 when CentOS6 drops out of maintenance. Some 
support from CentOS6 side would be nice. But we need to search someone 
for this.

I have that on my todo list, but did not manage to follow it up.


incl. gstreamer 0.1.0 that is now within the 4.1.x code.

PS:
CentOS 6 will be supported until Nov 2020; which means another ~2.5 years.

4.2.0 has I think 3 bugs we know about and that blocks a beta release. 
Current target for building with gstreamer is CentOS7. Building without 
gstreamer could be done on CentOS6. We should keep the code in trunc 
CentOS 6 compatible where ever we can for now. That will make it easy to 
back port patches to 4.1.x if we decide to maintain 4.1.x until EOL of 
CentOS6.


In 4.2.0 we can still keep gstreamer 0.1.0 or update to something newer. 
To be honest, I don't care *about this special topic*.


And it is only relevant on Linux, right?

IMHO more relevant is the baseline: When we increase the CentOS version 
we also raise the sysreq for Linux kernel, glibc, etc. This has a much 
bigger impact for our users.


My 2 ct.

Marcus




On 03.07.2018 23:50, Matthias Seidel wrote:

What impact has Ant 1.10.x exactly on older machines?
It is no problem for me to build the Windows version with Ant 1.9.12. As
long as we use Java 8.

But again, I just did a personal build to test AOO 4.1.x with Java 8.
Nothing else.
To be more precise: I was the only one who cared. No response from other
members!


Am 03.07.2018 um 23:19 schrieb Jim Jagielski:
The above made it appear that Ant 1.9.x was no longer supported plus 
had some sort of security related issue making it unsuited for AOO... 
ie, we *needed* to use Ant 1.10 not just that we now *can* use it.


How about showing some sympathy and understanding for those who may 
be stuck w/ older machines? After all, let's be real, our continued 
support for "older" systems is the only real thing we have going for 
us... It's these little things that make significant ripples in our 
eco-system and we seem to not really care about that anymore.


On Jul 3, 2018, at 4:02 PM, Matthias Seidel 
 wrote:


Am 03.07.2018 um 21:45 schrieb Jim Jagielski:

On Jul 1, 2018, at 11:27 AM, Peter Kovacs  wrote:

Hi everbody.


I would like to bring a 4.1.6 Release on the way in July. Even if 
we manage to get 4.2.0 ready it will only be a beta. And we have 
some stuff to get out to the people.


Matthias has created a suggestion for a 4.1.6 release on security. 
Containing some security fixes, plus



- Java 8 Update 172
- Apache Ant 1.10.3

What is wrong w/ Apache Ant 1.9.12? Why the need for 1.10.x?
What is wrong with Ant 1.10.x? If we build with Java 8 we can use 
it... ;-)
My test build was just a Proof-of-Concept what can be done with AOO 
4.1.x.


But of course we can build with 1.9.x if that is wanted?

Regards,
    Matthias



-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: A 4.1.6 Release

2018-07-04 Thread Kay Schenk
On Wed, Jul 4, 2018 at 1:00 PM, Marcus  wrote:

> Am 04.07.2018 um 08:23 schrieb Peter Kovacs:
>
>> I think Jim is referring to the gstreamer situation, where we decided
>> that we skip CentOS6 more or less for 4.2.0.And one argument was, if they
>> want something they should support us. This is not showing sympathy for a
>> small user group that uses very old software for 2 more years until they
>> have to move to CentOS 7. I personally think that the gstreamer Topic can
>> be solved after we have released a beta version. Damjan and I have pointed
>> out a lot of possible ways to deal with the issue. Just for now I think we
>> have other problems then gstreamer in 4.2.0. I think it is my fault that I
>> put that argument so much in the front line, but that stuck for me.
>>
>> In the last months we had a drop in activity. And more then one topic
>> received not the attention it deserved. I would not conclude that anyone
>> has stopped caring at this point in time.
>>
>>
>> Let us conclude for now:
>> 4.1.x is still in maintenance. And in my opinion we could think of
>> maintaining it until 2020 when CentOS6 drops out of maintenance. Some
>> support from CentOS6 side would be nice. But we need to search someone for
>> this.
>> I have that on my todo list, but did not manage to follow it up.
>>
>
> incl. gstreamer 0.1.0 that is now within the 4.1.x code.
>
> PS:
> CentOS 6 will be supported until Nov 2020; which means another ~2.5 years.
>
> 4.2.0 has I think 3 bugs we know about and that blocks a beta release.
>> Current target for building with gstreamer is CentOS7. Building without
>> gstreamer could be done on CentOS6. We should keep the code in trunc CentOS
>> 6 compatible where ever we can for now. That will make it easy to back port
>> patches to 4.1.x if we decide to maintain 4.1.x until EOL of CentOS6.
>>
>
> In 4.2.0 we can still keep gstreamer 0.1.0 or update to something newer.
> To be honest, I don't care *about this special topic*.
>
> And it is only relevant on Linux, right?
>
> IMHO more relevant is the baseline: When we increase the CentOS version we
> also raise the sysreq for Linux kernel, glibc, etc. This has a much bigger
> impact for our users.
>

​You are absolutely correct about this, Marcus. Monitoring the 32-bit Linux
downloads might help here. It does seem like AOO could be moving away from
32-bit for Linux and other operating systems. I don't know what impact this
will have overall though.

​


>
> My 2 ct.
>
> Marcus
>
>
>
>
> On 03.07.2018 23:50, Matthias Seidel wrote:
>>
>>> What impact has Ant 1.10.x exactly on older machines?
>>> It is no problem for me to build the Windows version with Ant 1.9.12. As
>>> long as we use Java 8.
>>>
>>> But again, I just did a personal build to test AOO 4.1.x with Java 8.
>>> Nothing else.
>>> To be more precise: I was the only one who cared. No response from other
>>> members!
>>>
>>>
>>> Am 03.07.2018 um 23:19 schrieb Jim Jagielski:
>>>
 The above made it appear that Ant 1.9.x was no longer supported plus
 had some sort of security related issue making it unsuited for AOO... ie,
 we *needed* to use Ant 1.10 not just that we now *can* use it.

 How about showing some sympathy and understanding for those who may be
 stuck w/ older machines? After all, let's be real, our continued support
 for "older" systems is the only real thing we have going for us... It's
 these little things that make significant ripples in our eco-system and we
 seem to not really care about that anymore.

 On Jul 3, 2018, at 4:02 PM, Matthias Seidel 
> wrote:
>
> Am 03.07.2018 um 21:45 schrieb Jim Jagielski:
>
>> On Jul 1, 2018, at 11:27 AM, Peter Kovacs  wrote:
>>>
>>> Hi everbody.
>>>
>>>
>>> I would like to bring a 4.1.6 Release on the way in July. Even if we
>>> manage to get 4.2.0 ready it will only be a beta. And we have some 
>>> stuff to
>>> get out to the people.
>>>
>>> Matthias has created a suggestion for a 4.1.6 release on security.
>>> Containing some security fixes, plus
>>>
>>>
>>> - Java 8 Update 172
>>> - Apache Ant 1.10.3
>>>
>> What is wrong w/ Apache Ant 1.9.12? Why the need for 1.10.x?
>>
> What is wrong with Ant 1.10.x? If we build with Java 8 we can use
> it... ;-)
> My test build was just a Proof-of-Concept what can be done with AOO
> 4.1.x.
>
> But of course we can build with 1.9.x if that is wanted?
>
> Regards,
> Matthias
>

>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>


-- 
--
MzK

"Less is MORE."


Re: A 4.1.6 Release

2018-07-04 Thread Marcus

Am 04.07.2018 um 22:46 schrieb Kay Schenk:

On Wed, Jul 4, 2018 at 1:00 PM, Marcus  wrote:


Am 04.07.2018 um 08:23 schrieb Peter Kovacs:


I think Jim is referring to the gstreamer situation, where we decided
that we skip CentOS6 more or less for 4.2.0.And one argument was, if they
want something they should support us. This is not showing sympathy for a
small user group that uses very old software for 2 more years until they
have to move to CentOS 7. I personally think that the gstreamer Topic can
be solved after we have released a beta version. Damjan and I have pointed
out a lot of possible ways to deal with the issue. Just for now I think we
have other problems then gstreamer in 4.2.0. I think it is my fault that I
put that argument so much in the front line, but that stuck for me.

In the last months we had a drop in activity. And more then one topic
received not the attention it deserved. I would not conclude that anyone
has stopped caring at this point in time.


Let us conclude for now:
4.1.x is still in maintenance. And in my opinion we could think of
maintaining it until 2020 when CentOS6 drops out of maintenance. Some
support from CentOS6 side would be nice. But we need to search someone for
this.
I have that on my todo list, but did not manage to follow it up.



incl. gstreamer 0.1.0 that is now within the 4.1.x code.

PS:
CentOS 6 will be supported until Nov 2020; which means another ~2.5 years.

4.2.0 has I think 3 bugs we know about and that blocks a beta release.

Current target for building with gstreamer is CentOS7. Building without
gstreamer could be done on CentOS6. We should keep the code in trunc CentOS
6 compatible where ever we can for now. That will make it easy to back port
patches to 4.1.x if we decide to maintain 4.1.x until EOL of CentOS6.



In 4.2.0 we can still keep gstreamer 0.1.0 or update to something newer.
To be honest, I don't care *about this special topic*.

And it is only relevant on Linux, right?

IMHO more relevant is the baseline: When we increase the CentOS version we
also raise the sysreq for Linux kernel, glibc, etc. This has a much bigger
impact for our users.


​You are absolutely correct about this, Marcus. Monitoring the 32-bit Linux
downloads might help here. It does seem like AOO could be moving away from
32-bit for Linux and other operating systems. I don't know what impact this
will have overall though.


I don't remember exactly, does the gstreamer 0.1.0 vs. 1.0.0 discussion 
is also connected to the Linux 32-bit builds? If so, a solution could be 
indeed to drop the 32-bit builds. From SF.net stats I get the following 
(2018-01-01 until today).


BTW:
Very likely it's the used OS the download is started from. And not the 
OS where OpenOffice should be installed on.


OS  %
---
Windows 86,1165
Macintosh7,8424
Unknown  4,9012
Linux1,0621
Android  0,0762
BSD  0,0011
Solaris  0,0006

But even then, I'm sure the most downloads from resp. for Linux will be 
for 64-bit.


Has anybody more exact numbers - or an idea how to get them?

Marcus




On 03.07.2018 23:50, Matthias Seidel wrote:



What impact has Ant 1.10.x exactly on older machines?
It is no problem for me to build the Windows version with Ant 1.9.12. As
long as we use Java 8.

But again, I just did a personal build to test AOO 4.1.x with Java 8.
Nothing else.
To be more precise: I was the only one who cared. No response from other
members!


Am 03.07.2018 um 23:19 schrieb Jim Jagielski:


The above made it appear that Ant 1.9.x was no longer supported plus
had some sort of security related issue making it unsuited for AOO... ie,
we *needed* to use Ant 1.10 not just that we now *can* use it.

How about showing some sympathy and understanding for those who may be
stuck w/ older machines? After all, let's be real, our continued support
for "older" systems is the only real thing we have going for us... It's
these little things that make significant ripples in our eco-system and we
seem to not really care about that anymore.

On Jul 3, 2018, at 4:02 PM, Matthias Seidel 

wrote:

Am 03.07.2018 um 21:45 schrieb Jim Jagielski:


On Jul 1, 2018, at 11:27 AM, Peter Kovacs  wrote:


Hi everbody.


I would like to bring a 4.1.6 Release on the way in July. Even if we
manage to get 4.2.0 ready it will only be a beta. And we have some stuff to
get out to the people.

Matthias has created a suggestion for a 4.1.6 release on security.
Containing some security fixes, plus


- Java 8 Update 172
- Apache Ant 1.10.3


What is wrong w/ Apache Ant 1.9.12? Why the need for 1.10.x?


What is wrong with Ant 1.10.x? If we build with Java 8 we can use
it... ;-)
My test build was just a Proof-of-Concept what can be done with AOO
4.1.x.

But of course we can build with 1.9.x if that is wanted?

Regards,
 Matthias



-
To unsubscribe, e-mail: dev-unsubscr...@

Re: A 4.1.6 Release

2018-07-04 Thread Kay Schenk
On Wed, Jul 4, 2018 at 2:45 PM, Marcus  wrote:

> Am 04.07.2018 um 22:46 schrieb Kay Schenk:
>
>> On Wed, Jul 4, 2018 at 1:00 PM, Marcus  wrote:
>>
>> Am 04.07.2018 um 08:23 schrieb Peter Kovacs:
>>>
>>> I think Jim is referring to the gstreamer situation, where we decided
 that we skip CentOS6 more or less for 4.2.0.And one argument was, if
 they
 want something they should support us. This is not showing sympathy for
 a
 small user group that uses very old software for 2 more years until they
 have to move to CentOS 7. I personally think that the gstreamer Topic
 can
 be solved after we have released a beta version. Damjan and I have
 pointed
 out a lot of possible ways to deal with the issue. Just for now I think
 we
 have other problems then gstreamer in 4.2.0. I think it is my fault
 that I
 put that argument so much in the front line, but that stuck for me.

 In the last months we had a drop in activity. And more then one topic
 received not the attention it deserved. I would not conclude that anyone
 has stopped caring at this point in time.


 Let us conclude for now:
 4.1.x is still in maintenance. And in my opinion we could think of
 maintaining it until 2020 when CentOS6 drops out of maintenance. Some
 support from CentOS6 side would be nice. But we need to search someone
 for
 this.
 I have that on my todo list, but did not manage to follow it up.


>>> incl. gstreamer 0.1.0 that is now within the 4.1.x code.
>>>
>>> PS:
>>> CentOS 6 will be supported until Nov 2020; which means another ~2.5
>>> years.
>>>
>>> 4.2.0 has I think 3 bugs we know about and that blocks a beta release.
>>>
 Current target for building with gstreamer is CentOS7. Building without
 gstreamer could be done on CentOS6. We should keep the code in trunc
 CentOS
 6 compatible where ever we can for now. That will make it easy to back
 port
 patches to 4.1.x if we decide to maintain 4.1.x until EOL of CentOS6.


>>> In 4.2.0 we can still keep gstreamer 0.1.0 or update to something newer.
>>> To be honest, I don't care *about this special topic*.
>>>
>>> And it is only relevant on Linux, right?
>>>
>>> IMHO more relevant is the baseline: When we increase the CentOS version
>>> we
>>> also raise the sysreq for Linux kernel, glibc, etc. This has a much
>>> bigger
>>> impact for our users.
>>>
>>
>> ​You are absolutely correct about this, Marcus. Monitoring the 32-bit
>> Linux
>> downloads might help here. It does seem like AOO could be moving away from
>> 32-bit for Linux and other operating systems. I don't know what impact
>> this
>> will have overall though.
>>
>
> I don't remember exactly, does the gstreamer 0.1.0 vs. 1.0.0 discussion is
> also connected to the Linux 32-bit builds?


​Somewhat, if we continue using CentOS for the Linux builds. Right now,
gstreamer 1.0 as opposed to 0.10 is only supplied in CentOS 7. CentOS 7.x
is supplied via the RH 7.x pipeline which is 64-bit only. There IS a CentOS
7.x - 32 bit provided by the CentOS community. I don't know if this stream
will continue.

​


> If so, a solution could be indeed to drop the 32-bit builds. From SF.net
> stats I get the following (2018-01-01 until today).
>
> BTW:
> Very likely it's the used OS the download is started from. And not the OS
> where OpenOffice should be installed on.
>

​Yes. It would be better if you could get counts per AOO package name
across all languages.
​


>
> OS  %
> ---
> Windows 86,1165
> Macintosh7,8424
> Unknown  4,9012
> Linux1,0621
> Android  0,0762
> BSD  0,0011
> Solaris  0,0006
>
> But even then, I'm sure the most downloads from resp. for Linux will be
> for 64-bit.
>
> Has anybody more exact numbers - or an idea how to get them?
>
>
> Marcus
>
>
>
> On 03.07.2018 23:50, Matthias Seidel wrote:
>>>

 What impact has Ant 1.10.x exactly on older machines?
> It is no problem for me to build the Windows version with Ant 1.9.12.
> As
> long as we use Java 8.
>
> But again, I just did a personal build to test AOO 4.1.x with Java 8.
> Nothing else.
> To be more precise: I was the only one who cared. No response from
> other
> members!
>
>
> Am 03.07.2018 um 23:19 schrieb Jim Jagielski:
>
> The above made it appear that Ant 1.9.x was no longer supported plus
>> had some sort of security related issue making it unsuited for AOO...
>> ie,
>> we *needed* to use Ant 1.10 not just that we now *can* use it.
>>
>> How about showing some sympathy and understanding for those who may be
>> stuck w/ older machines? After all, let's be real, our continued
>> support
>> for "older" systems is the only real thing we have going for us...
>> It's
>> these little things that make significant ripples in our eco-sy

Re: gstreamer status for 4.2.0-dev?

2018-07-04 Thread Andrea Pescetti

On 03/07/2018 Jim Jagielski wrote:

+1. I'll start on a CentOS7 VM.


Makes sense to me. So our indication for the Release Notes would be 
something like "OpenOffice 4.2.0 is built on CentOS 7 and is expected to 
run on Linux-based systems released in YEAR or later (CentOS 7, Ubuntu 
XYZ...)".


I'll check versions of glibc and the "YEAR" and "XYZ" placeholders above 
when I have time. We might also conclude that an Ubuntu LTS version is 
the best choice, but honestly CentOS 7 should definitely be "old enough" 
these days.



BTW, up to now I've been using VMware Fusion, but will likely start using Vbox 
instead... I'm assuming most people are using that anyway and it would be nice 
to be able to share the VMs with others.


I use KVM images. But indeed it's a wise idea to have something that we 
can share, and I believe Vbox images can be converted for use in KVM. 
I've done it in the past if I recall correctly.


Regards,
  Andrea.

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org