Re: a more sane way to override optimization flags in gbuild

2017-12-02 Thread Damjan Jovanovic
On Sun, Dec 3, 2017 at 2:25 AM, Jim Jagielski  wrote:

>
> > On Dec 2, 2017, at 5:56 PM, Andrea Pescetti  wrote:
> >
> > On 30/11/2017 Jim Jagielski wrote:
> >> I think for 4.2.x and later, we have deprecated CentOS5 as a supported
> >> build system... I ran into a LOT of issues.
> >
> > Such as, for example?
>
> for starters:
>   o zip 3.0.
>   o GIO
>
>
If you *really* need GIO, try adding --disable-gio --enable-gnome-vfs to
./configure.

The check for ZIP version 3.0 was added in revision 1755455, the gbuild
branch merge into trunk. Within that branch it was added in this commit:

r1409544 | arist | 2012-11-15 01:22:40 +0200 (Thu, 15 Nov 2012) | 9 lines
Changed paths:
   M /incubator/ooo/branches/gbuild/main/configure.in

gnumake4_047_ce56f9735b9c.patch
# HG changeset patch
# User Michael Stahl 
# Date 1301690824 0
# Node ID ce56f9735b9cd04f4e2724754fe7c11d9cec1ca9
# Parent  e37d17b6d8d93e87a4886268f338a2d4ea2a6304
gnumake4: configure.in: require Info-ZIP 3.0


apparently around the time they were adding support for Java in gbuild.
Maybe gbuild uses a ZIP 3 feature for JAR files? This is all we do with zip
in gbuild:

$(gb_Zip_ZIPCOMMAND) -rX -FS $(call gb_Zip_get_target,$*) $(FILES) )

are -rX or -FS new?

But can we please use another thread for such issues?

Damjan


Re: [PROPOSAL] Public Beta for 4.2

2017-12-02 Thread Don Lewis
On  1 Dec, Jim Jagielski wrote:
> I also like that we announce 4.1.5-GA at the same time we announce
> 4.2.0-B1.

I think we are still a ways from being ready for a Beta release.  For
instance, we need to do another sweep of the bundled software to see
what needs to be updated.  For instance, I recently saw a new CVE for
curl.  Unfortunately my time is pretty limited for the next month. There
are some other code quality issues that I've stumbled across that I want
to address.

In the meantime, I have no objection to better publicising our dev
builds for the brave to try out and find the problems.


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



Re: A more sane way to build - SCons, deCygwination and other hopes

2017-12-02 Thread Don Lewis
On  2 Dec, Damjan Jovanovic wrote:
> On Sat, Dec 2, 2017 at 4:19 PM, Jim Jagielski  wrote:
> 
>> Playing devils advocate, does it make sense to introduce
>> Yet Another Build System at this stage?
>>
>>
> I anticipated this question.
> 
> Firstly, we don't only have dmake and gbuild as our build systems. We also
> use Ant, meta-build tools like build.pl and co, Microsoft's nmake for
> main/icu on Windows, and probably more. The existing number of tools
> doesn't negatively affect development, so why should 1 more?
> 
> Secondly SCons can replace ./configure, so in all all-SCons world we would
> eliminate 3 tools, not just 2.
> 
> As for "sense . .. at this stage", we've hit several walls with gbuild at
> this stage:
> * It can't version libraries in the form of reg3.dll vs reg.so linking to
> reg.so.3 on *nix. Most of gbuild was written with the assumption libraries
> on *nix always end with .so. Even when we dangerously weaken those
> assumptions, and badly hack it, it doesn't deliver the link...

Other than for the benefit of extensions, I don't see much point in
versioning the libraries because they are otherwise private.  If add
versioning so that it is more obvious that an old extension won't work
with a new version of AOO, are we disiplined enough to do the
appropriate version bumps?

> * It already broke certain mixtures of build settings, eg. I think you
> can't both debug build and use precompiled headers on Windows, CFLAGS gets
> lost somewhere...

That should be fixable, but ...

> * Nobody knows gbuild. The syntax is atrocious. It uses obscure features of
> GNU make. We can't debug it. It takes days of work to investigate/fix any
> problem with it, work that could be better spent on a this vast project
> with few development resources.

Agreed 1000% here.

If you are doing a build with bundled python, how do you bootstrap?  If
you are on Windows and don't have python, how do you run the SCons
equivalent of configure and then use SCons to build python?

And a more recent question near and dear to my heart, how easy is it to
do per-target optimization flag overrides?


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



Re: a more sane way to override optimization flags in gbuild

2017-12-02 Thread Jim Jagielski

> On Dec 2, 2017, at 5:56 PM, Andrea Pescetti  wrote:
> 
> On 30/11/2017 Jim Jagielski wrote:
>> I think for 4.2.x and later, we have deprecated CentOS5 as a supported
>> build system... I ran into a LOT of issues.
> 
> Such as, for example?

for starters:
  o zip 3.0.
  o GIO

>  I think that the guide we have at
> https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Step_by_step#CentOS_5
> used to be the most solid procedure to build OpenOffice, while it is 
> well-known that building on Windows is complex and building on Mac is even 
> more complex and resulted in broken builds several times.
> 
> The reason I'm asking is not because CentOS 5 is particularly relevant (I 
> think we have agreement that we'll switch to CentOS 6 for 4.2.x and that the 
> next, if any, 4.1.x releases will cover major regressions only), but because 
> I think that an updated version (to CentOS 6) of that guide should be the 
> reference for our 4.2.x builds. So if there are issues that can be ironed 
> out, better to do it as soon as possible.

Isn't that exactly what I'm doing??? Or do you have some
other point to make?

Re: [PROPOSAL] Public Beta for 4.2

2017-12-02 Thread Andrea Pescetti

Jim Jagielski wrote:

I went ahead and copied the 4.1.4 page and created:
 https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.1.5
Of course, it needs to be further cleaned up. I can RM if that's OK
with everyone.


Fine with me, let's keep unchanged everything that worked well for 
4.1.4! Note: this includes the fact that Matthias (if available) should 
produce the Windows builds, since we've discovered with 4.1.4 that build 
issues are arcane to find at times, and we know that Matthias' Windows 
builds worked well for 4.1.4.


Regards,
  Andrea.

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



Re: [PROPOSAL] Public Beta for 4.2

2017-12-02 Thread Andrea Pescetti

On 01/12/2017 Jim Jagielski wrote:

I see that Pat has committed the security patches to trunk, which is fantastic!
Maybe we should take the next few business days and go thru Bugz
and see what, if anything, would be low-risk patches to trunk and
pencil in, say, Dec 7th as a "code freeze" date for builds...


Someone here is forgetting that the biggest chunk of work for 4.2.0 is 
with localization. We need to fix the code -> Pootle -> code process and 
this won't be trivial at all since we have scarce documentation, little 
knowledge and a half-broken situation in Pootle when the last import was 
done at some unspecified time. It is not impossible of course, but it 
does need some serious work.


So you can provide all the builds you wish, but I would expect that most 
of them display localization issues and a localization cycle in 40+ 
languages usually takes a couple months (once we have fixed the process).


I'm absolutely in favor of a public beta, well publicized and clearly 
marked as beta (with its own splash screen etc). This is not the point. 
Point is, if you want something out in 2017 then English+kid languages 
will be enough, and please call it Alpha or Beta-1 or something that 
makes it clear that there will have to be another Beta in a few months 
with working localized versions.


Regards,
  Andrea.

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



Re: [Issue 20819] add polynomial regression type

2017-12-02 Thread Andrea Pescetti

Peter Kovacs wrote:

https://bz.apache.org/ooo/show_bug.cgi?id=20819 ...
The best way imho is to let the users vote. How about follwing flow:
1) check if we can include the extention by license or find an
agreement with the maintainers.
2) Put a call to Vote if the package should be included or not on the
Forums, as sticky.
3) advertise the vote and have a discussion with the community.
(Announcement, Youtube, Googleplus, facebook, user mailing list
4) After a month we gather the results and follow the desicion.


Well, if you get past item 1 then you are done! Seriously, if new code 
is contributed and available I don't see reasons to keep it out (note: I 
see this as a reasonable feature for Calc).


Actually, there is an "item zero" which is preliminary to all this 
discussion, and it is:


0) Does the extension work with the latest OpenOffice release? Does it 
actually do what one would expect from the issue or not?


If the answer to item 0 is "no", then the entire discussion is 
pointless. I haven't tested and I don't have time now, but the latest 
release of that extension is quite old, so I wouldn't take for granted 
that it works.


Regards,
  Andrea.

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



Re: a more sane way to override optimization flags in gbuild

2017-12-02 Thread Andrea Pescetti

On 30/11/2017 Jim Jagielski wrote:

I think for 4.2.x and later, we have deprecated CentOS5 as a supported
build system... I ran into a LOT of issues.


Such as, for example? I think that the guide we have at
https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Step_by_step#CentOS_5
used to be the most solid procedure to build OpenOffice, while it is 
well-known that building on Windows is complex and building on Mac is 
even more complex and resulted in broken builds several times.


The reason I'm asking is not because CentOS 5 is particularly relevant 
(I think we have agreement that we'll switch to CentOS 6 for 4.2.x and 
that the next, if any, 4.1.x releases will cover major regressions 
only), but because I think that an updated version (to CentOS 6) of that 
guide should be the reference for our 4.2.x builds. So if there are 
issues that can be ironed out, better to do it as soon as possible.


Regards,
  Andrea.

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



Re: A more sane way to build - SCons, deCygwination and other hopes

2017-12-02 Thread Marcus

Am 02.12.2017 um 23:13 schrieb Jim Jagielski:



On Dec 2, 2017, at 1:59 PM, Damjan Jovanovic  wrote:

On Sat, Dec 2, 2017 at 4:19 PM, Jim Jagielski  wrote:


Playing devils advocate, does it make sense to introduce
Yet Another Build System at this stage?



I anticipated this question.


:)



Secondly SCons can replace ./configure, so in all all-SCons world we would
eliminate 3 tools, not just 2.


./configure seems to work fine.



* Nobody knows gbuild.


And more people know SCons?? :)

My point is that likely more people know make and gmake
and its obscure features than SCons.

What I don't want is some hybrid monstrosity like we
have now. Nor do I want work on the build system to hold
off release of 4.2.0.


relating to the last sentence:
For this there is the fantastic invention of branches. ;-)

OK, seriously:
At the moment we are talking more about a 4.2.0 release than all other 
posts in the past together. Therefore we should think of when the best 
time point is for creating a new 4.2.0 branch. IMHO it is coming really 
closer.


Then we can go on on Trunk with improving the build system without any 
effects for 4.2.0.


My 2ct.

Marcus


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



Re: A more sane way to build - SCons, deCygwination and other hopes

2017-12-02 Thread Jim Jagielski

> On Dec 2, 2017, at 1:59 PM, Damjan Jovanovic  wrote:
> 
> On Sat, Dec 2, 2017 at 4:19 PM, Jim Jagielski  wrote:
> 
>> Playing devils advocate, does it make sense to introduce
>> Yet Another Build System at this stage?
>> 
>> 
> I anticipated this question.

:)

> 
> Secondly SCons can replace ./configure, so in all all-SCons world we would
> eliminate 3 tools, not just 2.

./configure seems to work fine.

> 
> * Nobody knows gbuild.

And more people know SCons?? :)

My point is that likely more people know make and gmake
and its obscure features than SCons.

What I don't want is some hybrid monstrosity like we
have now. Nor do I want work on the build system to hold
off release of 4.2.0.

Just my own 2c and all the above IMHO


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



Re: A more sane way to build - SCons, deCygwination and other hopes

2017-12-02 Thread Damjan Jovanovic
On Sat, Dec 2, 2017 at 4:19 PM, Jim Jagielski  wrote:

> Playing devils advocate, does it make sense to introduce
> Yet Another Build System at this stage?
>
>
I anticipated this question.

Firstly, we don't only have dmake and gbuild as our build systems. We also
use Ant, meta-build tools like build.pl and co, Microsoft's nmake for
main/icu on Windows, and probably more. The existing number of tools
doesn't negatively affect development, so why should 1 more?

Secondly SCons can replace ./configure, so in all all-SCons world we would
eliminate 3 tools, not just 2.

As for "sense . .. at this stage", we've hit several walls with gbuild at
this stage:
* It can't version libraries in the form of reg3.dll vs reg.so linking to
reg.so.3 on *nix. Most of gbuild was written with the assumption libraries
on *nix always end with .so. Even when we dangerously weaken those
assumptions, and badly hack it, it doesn't deliver the link...
* It already broke certain mixtures of build settings, eg. I think you
can't both debug build and use precompiled headers on Windows, CFLAGS gets
lost somewhere...
* Nobody knows gbuild. The syntax is atrocious. It uses obscure features of
GNU make. We can't debug it. It takes days of work to investigate/fix any
problem with it, work that could be better spent on a this vast project
with few development resources.


> Also, there are a few projects that I know of that
> use SCons. In general, one of the most popular common
> threads related to them are "Why the hell are you using SCons?" :)
>
>
I'd like to see those discussions.

SCons as opposed to what?

Damjan


Re: [Issue 20819] add polynomial regression type

2017-12-02 Thread jonathon
On 12/01/2017 05:17 PM, Marcus wrote:
>>> This is absolutely a basic feature, i don't understand why there are
>>> more advanced regression types such as logaritmepic or poware when a
>>> polynomial regression is lacking.

> Maybe because we have an *Office* Suite and not a *Mathematical* Suite?

This type of thinking is why migrating from MSO can be problematic for
spreadsheet users.

> ;-) Seriously, I see  this as special mathematical feature and not a basic 
> feature for a software suite that contains also a word processor, drawing, a 
> presentation application and also database.

That would be acceptable if, and only if, there is zero expectation that
Calc is used for anything in the financial industry, or for any type of
forecasting, be it earthquakes, BitCoin Futures, or student grades.

jonathon



signature.asc
Description: OpenPGP digital signature


Re: [Issue 20819] add polynomial regression type

2017-12-02 Thread Marcus

Am 02.12.2017 um 16:51 schrieb Peter Kovacs:

Am Samstag, den 02.12.2017, 14:40 +0100 schrieb Marcus:



We said we would like to give our users a voice. Wouldn't it be
appropriate to give them exactly this voice? This is a clear
concept to
me.


maybe.

Sorry when this sounds too negative but thats my opinion. I think at
the
moment we should spend our time for more important features and
processes than this special thing.


I do not think your opinion is negative. And yea other things seem more
important.

Since the list is not such a good thing to remeber, I would like to
close the Issue existing with the argument that you have given, that
the extention covers the feature request.
I would also like to open a new Issue that contains the request to
deliver this Extention at default plus the current state of this
discussion.
So we can pick the discussion up at a later point.


maybe you can also add the mail address of the author(s) and a comment 
that the extension could be integrated into the core code as the users 
want to have it present by default.


Can we agree on this?


Sure :-)

Marcus


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



Re: A more sane way to build - SCons, deCygwination and other hopes

2017-12-02 Thread Peter Kovacs
Am Samstag, den 02.12.2017, 09:19 -0500 schrieb Jim Jagielski:
> Playing devils advocate, does it make sense to introduce
> Yet Another Build System at this stage?
I see it as for the search for the future build system. There is always
the discussion popping up what to use.
Gbuild seem to make some troubles. We have looked into Maven with no
good result.
So far satisfactory outcome. So you as the release team still use the
old one with the known difficulties.

I think we should give it a try. Well buts that me, as a noob I want to
try always all options and then decide where my favours are.
> 
> Also, there are a few projects that I know of that
> use SCons. In general, one of the most popular common
> threads related to them are "Why the hell are you using SCons?" :)

Do they bash or is there some serious arguments behind that?- I am
always interested in negative opinion as long as they have substance.


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



Re: [Issue 20819] add polynomial regression type

2017-12-02 Thread Peter Kovacs
Am Samstag, den 02.12.2017, 14:40 +0100 schrieb Marcus:
> 
> > We said we would like to give our users a voice. Wouldn't it be
> > appropriate to give them exactly this voice? This is a clear
> > concept to
> > me.
> 
> maybe.
> 
> Sorry when this sounds too negative but thats my opinion. I think at
> the 
> moment we should spend our time for more important features and 
> processes than this special thing.
> 
I do not think your opinion is negative. And yea other things seem more
important.

Since the list is not such a good thing to remeber, I would like to
close the Issue existing with the argument that you have given, that
the extention covers the feature request.
I would also like to open a new Issue that contains the request to
deliver this Extention at default plus the current state of this
discussion.
So we can pick the discussion up at a later point.

Can we agree on this?

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



Re: [PROPOSAL] Public Beta for 4.2

2017-12-02 Thread Matthias Seidel
Am 02.12.2017 um 15:56 schrieb Jim Jagielski:
> Thx... Look like packager-list is the easiest way.

This is my list (only Windows):
https://home.apache.org/~mseidel/AOO-builds/AOO-420-Beta/aoo-build-pack-beta.lst

>
>> On Dec 2, 2017, at 9:41 AM, Matthias Seidel  
>> wrote:
>>
>> I use "--with-packager-list=" in configure and define a pack list
>> according to:
>> https://svn.apache.org/repos/asf/openoffice/trunk/main/instsetoo_native/util/pack.lst
>>
>> Don't know if there is a better way...
>>
>> Maybe you can see more in:
>> https://svn.apache.org/repos/asf/openoffice/trunk/main/instsetoo_native/util/makefile.mk
>>
>> Regards, Matthias
>>
>>
>> Am 02.12.2017 um 15:33 schrieb Jim Jagielski:
>>> OK, so where do we specify that? Assuming:
>>>
>>>build --all -P -- -P
>>>
>>> Like this?
>>>
>>>build openofficebeta --all -P -- -P
>>>
>>> Or this?
>>>
>>>build --all openofficebeta -P -- -P
>>>
>>> Or here?
>>>
>>>build --all -P -- -P openofficebeta
>>>
>>> None seem to work :(
>>>
>>> =
>>> Building module solenv
>>> =
>>>
>>> Entering /Users/jim/src/asf/AOO420/main/solenv
>>>
>>> dmake:  Error: -- Don't know how to make `openofficebeta'
>>>
>>>
 On Dec 2, 2017, at 9:25 AM, Matthias Seidel  
 wrote:

 Am 02.12.2017 um 15:16 schrieb Jim Jagielski:
>> On Dec 2, 2017, at 8:44 AM, Matthias Seidel  
>> wrote:
>>
>> Am 02.12.2017 um 14:39 schrieb Marcus:
>>> Am 02.12.2017 um 13:22 schrieb Matthias Seidel:
 Despite of the name it could be the icon of the dmg file? I don't
 know where this icon set is visible... ;-)

 Apart from that: +1 for a public beta.

 But we should build "real" beta builds, with the appropriate
 naming/graphics:
 https://home.apache.org/~mseidel/AOO-builds/AOO-420-Beta/About%20OpenOffice%20Beta%204.2.0.png

>>> oh yes, good hint. IMHO the splash screen and start center graphic
>>> should show clearly that this is a beta release. Plus different
>>> filenames for the installation files.
>> That is all handled by building for target "openofficebeta"
>> (sdkoobeta/ooobetalanguagepack).
>>
> Wow. I had no idea that existed :)
 I stumbled upon the beta graphics by accident.

 We even have a "Dev" target... ;-)

>>> -
>>> 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: [PROPOSAL] Public Beta for 4.2

2017-12-02 Thread Jim Jagielski
Thx... Look like packager-list is the easiest way.

> On Dec 2, 2017, at 9:41 AM, Matthias Seidel  
> wrote:
> 
> I use "--with-packager-list=" in configure and define a pack list
> according to:
> https://svn.apache.org/repos/asf/openoffice/trunk/main/instsetoo_native/util/pack.lst
> 
> Don't know if there is a better way...
> 
> Maybe you can see more in:
> https://svn.apache.org/repos/asf/openoffice/trunk/main/instsetoo_native/util/makefile.mk
> 
> Regards, Matthias
> 
> 
> Am 02.12.2017 um 15:33 schrieb Jim Jagielski:
>> OK, so where do we specify that? Assuming:
>> 
>>build --all -P -- -P
>> 
>> Like this?
>> 
>>build openofficebeta --all -P -- -P
>> 
>> Or this?
>> 
>>build --all openofficebeta -P -- -P
>> 
>> Or here?
>> 
>>build --all -P -- -P openofficebeta
>> 
>> None seem to work :(
>> 
>> =
>> Building module solenv
>> =
>> 
>> Entering /Users/jim/src/asf/AOO420/main/solenv
>> 
>> dmake:  Error: -- Don't know how to make `openofficebeta'
>> 
>> 
>>> On Dec 2, 2017, at 9:25 AM, Matthias Seidel  
>>> wrote:
>>> 
>>> Am 02.12.2017 um 15:16 schrieb Jim Jagielski:
> On Dec 2, 2017, at 8:44 AM, Matthias Seidel  
> wrote:
> 
> Am 02.12.2017 um 14:39 schrieb Marcus:
>> Am 02.12.2017 um 13:22 schrieb Matthias Seidel:
>>> Despite of the name it could be the icon of the dmg file? I don't
>>> know where this icon set is visible... ;-)
>>> 
>>> Apart from that: +1 for a public beta.
>>> 
>>> But we should build "real" beta builds, with the appropriate
>>> naming/graphics:
>>> https://home.apache.org/~mseidel/AOO-builds/AOO-420-Beta/About%20OpenOffice%20Beta%204.2.0.png
>>> 
>> oh yes, good hint. IMHO the splash screen and start center graphic
>> should show clearly that this is a beta release. Plus different
>> filenames for the installation files.
> That is all handled by building for target "openofficebeta"
> (sdkoobeta/ooobetalanguagepack).
> 
 Wow. I had no idea that existed :)
>>> I stumbled upon the beta graphics by accident.
>>> 
>>> We even have a "Dev" target... ;-)
>>> 
 
>>> 
>> 
>> -
>> 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: FOSDEM 2018: Open Document Editors DevRoom

2017-12-02 Thread Andrea Pescetti
Reminder: 3 days left (Saturday, Sunday, Monday) for submitting your 
FOSDEM proposal. You just need a title and a short abstract for the 
moment. Submission instructions below.

Regards,
  Andrea.

Il 27/11/2017 08:42, Andrea Pescetti ha scritto:

Reminder: submission deadline for proposal is in 7 days (next Monday).
Anyone attending FOSDEM is welcome to prepare a short presentation.

The call is now published at
https://blogs.apache.org/OOo/entry/open-document-editors-devroom-at

Regards,
   Andrea.

On 19/11/2017 Andrea Pescetti wrote:

Andrea Pescetti wrote:

Important dates:
- Submission deadline: 4 Dec 2017
- FOSDEM: [3-]4 Feb 2018, Brussels, Belgium.


Just to avoid confusion about dates: FOSDEM is 3-4 February 2018 and
runs for the full day both days. The Open Document Editors (including
OpenOffice) devroom is on Saturday 3 February, full day. So if you can
stay only one day, make sure it is Saturday 3 February.

There will be an ASF booth running both days, and there will be many
other devrooms covering dozens of projects, so if you manage to be there
for both days, even better!

Regards,
   Andrea.

-
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: [PROPOSAL] Public Beta for 4.2

2017-12-02 Thread Matthias Seidel
I use "--with-packager-list=" in configure and define a pack list
according to:
https://svn.apache.org/repos/asf/openoffice/trunk/main/instsetoo_native/util/pack.lst

Don't know if there is a better way...

Maybe you can see more in:
https://svn.apache.org/repos/asf/openoffice/trunk/main/instsetoo_native/util/makefile.mk

Regards, Matthias


Am 02.12.2017 um 15:33 schrieb Jim Jagielski:
> OK, so where do we specify that? Assuming:
>
> build --all -P -- -P
>
> Like this?
>
> build openofficebeta --all -P -- -P
>
> Or this?
>
> build --all openofficebeta -P -- -P
>
> Or here?
>
> build --all -P -- -P openofficebeta
>
> None seem to work :(
>
> =
> Building module solenv
> =
>
> Entering /Users/jim/src/asf/AOO420/main/solenv
>
> dmake:  Error: -- Don't know how to make `openofficebeta'
>
>
>> On Dec 2, 2017, at 9:25 AM, Matthias Seidel  
>> wrote:
>>
>> Am 02.12.2017 um 15:16 schrieb Jim Jagielski:
 On Dec 2, 2017, at 8:44 AM, Matthias Seidel  
 wrote:

 Am 02.12.2017 um 14:39 schrieb Marcus:
> Am 02.12.2017 um 13:22 schrieb Matthias Seidel:
>> Despite of the name it could be the icon of the dmg file? I don't
>> know where this icon set is visible... ;-)
>>
>> Apart from that: +1 for a public beta.
>>
>> But we should build "real" beta builds, with the appropriate
>> naming/graphics:
>> https://home.apache.org/~mseidel/AOO-builds/AOO-420-Beta/About%20OpenOffice%20Beta%204.2.0.png
>>
> oh yes, good hint. IMHO the splash screen and start center graphic
> should show clearly that this is a beta release. Plus different
> filenames for the installation files.
 That is all handled by building for target "openofficebeta"
 (sdkoobeta/ooobetalanguagepack).

>>> Wow. I had no idea that existed :)
>> I stumbled upon the beta graphics by accident.
>>
>> We even have a "Dev" target... ;-)
>>
>>>
>>
>
> -
> 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: [PROPOSAL] Public Beta for 4.2

2017-12-02 Thread Jim Jagielski
OK, so where do we specify that? Assuming:

build --all -P -- -P

Like this?

build openofficebeta --all -P -- -P

Or this?

build --all openofficebeta -P -- -P

Or here?

build --all -P -- -P openofficebeta

None seem to work :(

=
Building module solenv
=

Entering /Users/jim/src/asf/AOO420/main/solenv

dmake:  Error: -- Don't know how to make `openofficebeta'


> On Dec 2, 2017, at 9:25 AM, Matthias Seidel  
> wrote:
> 
> Am 02.12.2017 um 15:16 schrieb Jim Jagielski:
>>> On Dec 2, 2017, at 8:44 AM, Matthias Seidel  
>>> wrote:
>>> 
>>> Am 02.12.2017 um 14:39 schrieb Marcus:
 Am 02.12.2017 um 13:22 schrieb Matthias Seidel:
> Despite of the name it could be the icon of the dmg file? I don't
> know where this icon set is visible... ;-)
> 
> Apart from that: +1 for a public beta.
> 
> But we should build "real" beta builds, with the appropriate
> naming/graphics:
> https://home.apache.org/~mseidel/AOO-builds/AOO-420-Beta/About%20OpenOffice%20Beta%204.2.0.png
> 
 oh yes, good hint. IMHO the splash screen and start center graphic
 should show clearly that this is a beta release. Plus different
 filenames for the installation files.
>>> That is all handled by building for target "openofficebeta"
>>> (sdkoobeta/ooobetalanguagepack).
>>> 
>> Wow. I had no idea that existed :)
> 
> I stumbled upon the beta graphics by accident.
> 
> We even have a "Dev" target... ;-)
> 
>> 
>> 
> 
> 


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



Re: [PROPOSAL] Public Beta for 4.2

2017-12-02 Thread Matthias Seidel
Am 02.12.2017 um 15:16 schrieb Jim Jagielski:
>> On Dec 2, 2017, at 8:44 AM, Matthias Seidel  
>> wrote:
>>
>> Am 02.12.2017 um 14:39 schrieb Marcus:
>>> Am 02.12.2017 um 13:22 schrieb Matthias Seidel:
 Despite of the name it could be the icon of the dmg file? I don't
 know where this icon set is visible... ;-)

 Apart from that: +1 for a public beta.

 But we should build "real" beta builds, with the appropriate
 naming/graphics:
 https://home.apache.org/~mseidel/AOO-builds/AOO-420-Beta/About%20OpenOffice%20Beta%204.2.0.png

>>> oh yes, good hint. IMHO the splash screen and start center graphic
>>> should show clearly that this is a beta release. Plus different
>>> filenames for the installation files.
>> That is all handled by building for target "openofficebeta"
>> (sdkoobeta/ooobetalanguagepack).
>>
> Wow. I had no idea that existed :)

I stumbled upon the beta graphics by accident.

We even have a "Dev" target... ;-)

>
>




smime.p7s
Description: S/MIME Cryptographic Signature


Re: A more sane way to build - SCons, deCygwination and other hopes

2017-12-02 Thread Jim Jagielski
Playing devils advocate, does it make sense to introduce
Yet Another Build System at this stage?

Also, there are a few projects that I know of that
use SCons. In general, one of the most popular common
threads related to them are "Why the hell are you using SCons?" :)

> On Dec 2, 2017, at 3:05 AM, Damjan Jovanovic  wrote:
> 
> Hi
> 
> After days of failing to add a few new simple features to gbuild, I've now
> reached my limits, and have begun experimenting with the SCons build system
> instead.
> 
> It's starting to work. Having ported some of gbuild.mk, LinkTarget.mk and
> platform/freebsd.mk to SCons, as well as a module's local gbuild files, I
> can now compile files and (badly) link them into libraries, and clean the
> build.
> 
> SCons is an advanced next-generation build system like gbuild, with high
> level declarative syntax in Python, support for multiple modules that build
> in parallel, header dependencies, file change detection through MD5 sums of
> contents instead of timestamps so rebuilds are faster, etc. It builds C,
> C++, Objective C, Java, Fortran, D, the sorely necessary Flex and Yacc that
> gbuild doesn't support. It supports tons of platforms and compilers,
> including OS/2. It's maintainable and usable, can print debugging info such
> as dependency trees, and is generally pleasant to work with. We've
> discussed it before on this list, but I never got to trying it until now.
> 
> Virtually everything gbuild does, is already done by SCons, and often done
> much better. The syntax for SCons files is similar/related to gbuild's
> syntax, so an automated conversion from gbuild to SCons might even be
> possible.
> 
> So far, I have defines, includes and C[XX]FLAGS working. I've structured it
> a bit better, with platform-specific files in classes that only provide
> variables to slot in higher up, instead of one giant set of globally
> mutable global variables like in gbuild. Linking still needs a bit of work.
> Windows is next on the list, as Cygwin will be the ultimate test of whether
> we can use it.
> 
> I am very hopeful. SCons has a long history and is used by other projects,
> while only OO.o derivatives use gbuild. It's well documented. It supports
> features we need which gbuild doesn't, like library version names and
> flex/yacc. It's supposed to work on Windows, both inside and outside of
> Cygwin and could help us build without Cygwin some day. It supports many
> versions of Visual Studio and could help us in upgrading to a new one. We
> will need to add custom builders to SCons for our custom file formats like
> IDL, but it's just Python, not my favorite language but infinitely better
> than GNU make.
> 
> It would help if someone could review my changes, as I am not very familiar
> with Python and there might be better ways to write some of the code. I'll
> post a patch for review after some further development.
> 
> Thank you
> Damjan


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



Re: [PROPOSAL] Public Beta for 4.2

2017-12-02 Thread Jim Jagielski

> On Dec 2, 2017, at 8:44 AM, Matthias Seidel  
> wrote:
> 
> Am 02.12.2017 um 14:39 schrieb Marcus:
>> Am 02.12.2017 um 13:22 schrieb Matthias Seidel:
>>> Despite of the name it could be the icon of the dmg file? I don't
>>> know where this icon set is visible... ;-)
>>> 
>>> Apart from that: +1 for a public beta.
>>> 
>>> But we should build "real" beta builds, with the appropriate
>>> naming/graphics:
>>> https://home.apache.org/~mseidel/AOO-builds/AOO-420-Beta/About%20OpenOffice%20Beta%204.2.0.png
>>> 
>> 
>> oh yes, good hint. IMHO the splash screen and start center graphic
>> should show clearly that this is a beta release. Plus different
>> filenames for the installation files.
> 
> That is all handled by building for target "openofficebeta"
> (sdkoobeta/ooobetalanguagepack).
> 

Wow. I had no idea that existed :)



Re: [PROPOSAL] Public Beta for 4.2

2017-12-02 Thread Marcus

Am 02.12.2017 um 14:44 schrieb Matthias Seidel:

Am 02.12.2017 um 14:39 schrieb Marcus:

Am 02.12.2017 um 13:22 schrieb Matthias Seidel:

Despite of the name it could be the icon of the dmg file? I don't
know where this icon set is visible... ;-)

Apart from that: +1 for a public beta.

But we should build "real" beta builds, with the appropriate
naming/graphics:
https://home.apache.org/~mseidel/AOO-builds/AOO-420-Beta/About%20OpenOffice%20Beta%204.2.0.png



oh yes, good hint. IMHO the splash screen and start center graphic
should show clearly that this is a beta release. Plus different
filenames for the installation files.


That is all handled by building for target "openofficebeta"
(sdkoobeta/ooobetalanguagepack).


oha, the last beta is bloody long ago that I've forgotten that this 
build target already exists. ;-)


Marcus




Am 01.12.2017 um 20:08 schrieb Jim Jagielski:

My latest 4.2.0-dev builds are available at

  http://home.apache.org/~jim/AOO-builds/AOO-4.2.0-dev-r1816768/


But these are dmg's not installers.


On Dec 1, 2017, at 11:58 AM, Matthias
Seidel  wrote:

Hi Jim,

Did you have the opportunity to install 4.2.0 on macOS?

I would be interested if the new icon does show up:
https://svn.apache.org/repos/asf/openoffice/trunk/main/setup_native/source/mac/ooo3_installer.icns


I created it on Windows with a program called "iConvertIcons" and
had no
chance to test it.

Regards, Matthias


Am 01.12.2017 um 03:41 schrieb Jim Jagielski:

I like it. I already have Linux, Windows and macOS 4.2.0-dev
builds available
(http://home.apache.org/~jim/AOO-builds/
) for some langs



On Nov 30, 2017, at 5:15 PM, Marcus  wrote:

Am 30.11.2017 um 21:26 schrieb Dave Fisher:

In light of our current situation with getting builds together
but not having a lot of people doing more than simple QA what
does the team think about releasing a Public Beta for 4.2.0? I
think that this would be an advantage for the project and might
serve to bring in more of the community as QA volunteers.

I thought it's without discussion that we need a (long) beta test
phase for 4.2.0. So, yes for your proposal.

We can create a new entry on the download webpage, some
advertising areas on the other webpages, and other fine things to
make it visible.

And - also this should be clear already - we need several builds
of 4.2.0 with further included bugfixes; to show an increasing
quality towards the final release build.

For me the real question is " *When* do we start the beta? ". ;-)
I would like to have a specific level of quality that we give to
our users. Otherwise we will get spammed by bug reports which
nobody wants to handle.

Marcus



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



Re: [PROPOSAL] Public Beta for 4.2

2017-12-02 Thread Matthias Seidel
Am 02.12.2017 um 14:39 schrieb Marcus:
> Am 02.12.2017 um 13:22 schrieb Matthias Seidel:
>> Despite of the name it could be the icon of the dmg file? I don't
>> know where this icon set is visible... ;-)
>>
>> Apart from that: +1 for a public beta.
>>
>> But we should build "real" beta builds, with the appropriate
>> naming/graphics:
>> https://home.apache.org/~mseidel/AOO-builds/AOO-420-Beta/About%20OpenOffice%20Beta%204.2.0.png
>>
>
> oh yes, good hint. IMHO the splash screen and start center graphic
> should show clearly that this is a beta release. Plus different
> filenames for the installation files.

That is all handled by building for target "openofficebeta"
(sdkoobeta/ooobetalanguagepack).

I am just uploading a fresh Beta build for Windows:
https://home.apache.org/~mseidel/AOO-builds/AOO-420-Beta/

Regards, Matthias

>
> Marcus
>
>
>
>> Am 01.12.2017 um 20:08 schrieb Jim Jagielski:
>>> My latest 4.2.0-dev builds are available at
>>>
>>>  http://home.apache.org/~jim/AOO-builds/AOO-4.2.0-dev-r1816768/ 
>>> 
>>>
>>> But these are dmg's not installers.
>>>
 On Dec 1, 2017, at 11:58 AM, Matthias
 Seidel  wrote:

 Hi Jim,

 Did you have the opportunity to install 4.2.0 on macOS?

 I would be interested if the new icon does show up:
 https://svn.apache.org/repos/asf/openoffice/trunk/main/setup_native/source/mac/ooo3_installer.icns


 I created it on Windows with a program called "iConvertIcons" and
 had no
 chance to test it.

 Regards, Matthias


 Am 01.12.2017 um 03:41 schrieb Jim Jagielski:
> I like it. I already have Linux, Windows and macOS 4.2.0-dev
> builds available
> (http://home.apache.org/~jim/AOO-builds/ 
> ) for some langs
>
>
>> On Nov 30, 2017, at 5:15 PM, Marcus  wrote:
>>
>> Am 30.11.2017 um 21:26 schrieb Dave Fisher:
>>> In light of our current situation with getting builds together
>>> but not having a lot of people doing more than simple QA what
>>> does the team think about releasing a Public Beta for 4.2.0? I
>>> think that this would be an advantage for the project and might
>>> serve to bring in more of the community as QA volunteers.
>> I thought it's without discussion that we need a (long) beta test
>> phase for 4.2.0. So, yes for your proposal.
>>
>> We can create a new entry on the download webpage, some
>> advertising areas on the other webpages, and other fine things to
>> make it visible.
>>
>> And - also this should be clear already - we need several builds
>> of 4.2.0 with further included bugfixes; to show an increasing
>> quality towards the final release build.
>>
>> For me the real question is " *When* do we start the beta? ". ;-)
>> I would like to have a specific level of quality that we give to
>> our users. Otherwise we will get spammed by bug reports which
>> nobody wants to handle.
>>
>> Marcus
>
>
> -
> 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: [Issue 20819] add polynomial regression type

2017-12-02 Thread Marcus

Am 02.12.2017 um 11:22 schrieb Peter Kovacs:

Am Freitag, den 01.12.2017, 18:17 +0100 schrieb Marcus:

Am 01.12.2017 um 18:09 schrieb Peter Kovacs:

For me the existance is not a strong argument. The bug is with 149
votes
quite popular. The discussion there is a repeatance that this is
basic
feature.


but we don't know from when the votes are. Or is there a possiblity
to
see in Bugzilla? The issue report is old as we can see on the ID.
The
extension could have been created after all or the most votes were
done.

Since you can not renew your vote have to assume the vote goes to
provide a feature. It is difficult to dstinguish. However it is a
strongly requested feature that we can read from it.

The best way imho is to let the users vote. How about follwing flow:
1) check if we can include the extention by license or find an
agreement with the maintainers.
2) Put a call to Vote if the package should be included or not on the
Forums, as sticky.
3) advertise the vote and have a discussion with the community.
(Announcement, Youtube, Googleplus, facebook, user mailing list
4) After a month we gather the results and follow the desicion.

To be clear, I am not favoured for or against inclusion of an
extention. But for me it is crucial that people can see a concept
behind our decisions.

We said we would like to give our users a voice. Wouldn't it be
appropriate to give them exactly this voice? This is a clear concept to
me.


maybe.

Sorry when this sounds too negative but thats my opinion. I think at the 
moment we should spend our time for more important features and 
processes than this special thing.


Marcus


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



Re: [PROPOSAL] Public Beta for 4.2

2017-12-02 Thread Marcus

Am 02.12.2017 um 13:22 schrieb Matthias Seidel:
Despite of the name it could be the icon of the dmg file? I don't know 
where this icon set is visible... ;-)


Apart from that: +1 for a public beta.

But we should build "real" beta builds, with the appropriate 
naming/graphics:

https://home.apache.org/~mseidel/AOO-builds/AOO-420-Beta/About%20OpenOffice%20Beta%204.2.0.png


oh yes, good hint. IMHO the splash screen and start center graphic 
should show clearly that this is a beta release. Plus different 
filenames for the installation files.


Marcus




Am 01.12.2017 um 20:08 schrieb Jim Jagielski:

My latest 4.2.0-dev builds are available at

 http://home.apache.org/~jim/AOO-builds/AOO-4.2.0-dev-r1816768/  


But these are dmg's not installers.


On Dec 1, 2017, at 11:58 AM, Matthias Seidel  wrote:

Hi Jim,

Did you have the opportunity to install 4.2.0 on macOS?

I would be interested if the new icon does show up:
https://svn.apache.org/repos/asf/openoffice/trunk/main/setup_native/source/mac/ooo3_installer.icns

I created it on Windows with a program called "iConvertIcons" and had no
chance to test it.

Regards, Matthias


Am 01.12.2017 um 03:41 schrieb Jim Jagielski:

I like it. I already have Linux, Windows and macOS 4.2.0-dev builds available
(http://home.apache.org/~jim/AOO-builds/  
) for some langs



On Nov 30, 2017, at 5:15 PM, Marcus  wrote:

Am 30.11.2017 um 21:26 schrieb Dave Fisher:

In light of our current situation with getting builds together but not having a 
lot of people doing more than simple QA what does the team think about 
releasing a Public Beta for 4.2.0? I think that this would be an advantage for 
the project and might serve to bring in more of the community as QA volunteers.

I thought it's without discussion that we need a (long) beta test phase for 
4.2.0. So, yes for your proposal.

We can create a new entry on the download webpage, some advertising areas on 
the other webpages, and other fine things to make it visible.

And - also this should be clear already - we need several builds of 4.2.0 with 
further included bugfixes; to show an increasing quality towards the final 
release build.

For me the real question is " *When* do we start the beta? ". ;-) I would like 
to have a specific level of quality that we give to our users. Otherwise we will get 
spammed by bug reports which nobody wants to handle.

Marcus



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



Re: [PROPOSAL] Public Beta for 4.2

2017-12-02 Thread Matthias Seidel
Despite of the name it could be the icon of the dmg file? I don't know
where this icon set is visible... ;-)

Apart from that: +1 for a public beta.

But we should build "real" beta builds, with the appropriate
naming/graphics:
https://home.apache.org/~mseidel/AOO-builds/AOO-420-Beta/About%20OpenOffice%20Beta%204.2.0.png

Regards, Matthias


Am 01.12.2017 um 20:08 schrieb Jim Jagielski:
> My latest 4.2.0-dev builds are available at
>
> http://home.apache.org/~jim/AOO-builds/AOO-4.2.0-dev-r1816768/ 
> 
>
> But these are dmg's not installers.
>
>> On Dec 1, 2017, at 11:58 AM, Matthias Seidel  
>> wrote:
>>
>> Hi Jim,
>>
>> Did you have the opportunity to install 4.2.0 on macOS?
>>
>> I would be interested if the new icon does show up:
>> https://svn.apache.org/repos/asf/openoffice/trunk/main/setup_native/source/mac/ooo3_installer.icns
>>
>> I created it on Windows with a program called "iConvertIcons" and had no
>> chance to test it.
>>
>> Regards, Matthias
>>
>>
>> Am 01.12.2017 um 03:41 schrieb Jim Jagielski:
>>> I like it. I already have Linux, Windows and macOS 4.2.0-dev builds 
>>> available
>>> (http://home.apache.org/~jim/AOO-builds/ 
>>> ) for some langs
>>>
>>>
 On Nov 30, 2017, at 5:15 PM, Marcus  wrote:

 Am 30.11.2017 um 21:26 schrieb Dave Fisher:
> In light of our current situation with getting builds together but not 
> having a lot of people doing more than simple QA what does the team think 
> about releasing a Public Beta for 4.2.0? I think that this would be an 
> advantage for the project and might serve to bring in more of the 
> community as QA volunteers.
 I thought it's without discussion that we need a (long) beta test phase 
 for 4.2.0. So, yes for your proposal.

 We can create a new entry on the download webpage, some advertising areas 
 on the other webpages, and other fine things to make it visible.

 And - also this should be clear already - we need several builds of 4.2.0 
 with further included bugfixes; to show an increasing quality towards the 
 final release build.

 For me the real question is " *When* do we start the beta? ". ;-) I would 
 like to have a specific level of quality that we give to our users. 
 Otherwise we will get spammed by bug reports which nobody wants to handle.

 Marcus


 -
 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: AOO 4.2.0 (Verschoben von user-de)

2017-12-02 Thread Matthias Seidel
Moin Josef,

Am 02.12.2017 um 12:12 schrieb Josef Latt:
> Hi Matthias,
>
> habe den Build getestet, gleiches Problem.

Meine Vermutung, dass es am Build-System liegen könnte hat sich somit
nicht bestätigt.
Wir hatten bei den 4.1.4 mac-Builds die gleichen Meldungen, da haben wir
zumindest einen Ansatzpunkt (libxml/libxslt).

> BTW, an und für sich sollte mein Posting auf die dev-de.
> Habe mich da vertan.

Kein Problem... ;-)

Gruß, Matthias

>
> Gruß Josef
>
>
> Am 02.12.2017 um 10:08 schrieb Matthias Seidel:
>> Moin Josef,
>>
>> Das ist der aktuelle Build vom Buildbot (Ubuntu 14.04)?
>>
>> Vielleicht kannst du noch diesen Build probieren, der ist auf CentOS
>> erstellt:
>> https://home.apache.org/~jim/AOO-builds/AOO-4.2.0-dev-r1816311/de/Apache_OpenOffice_4.2.0_Linux_x86-64_install-deb_de.tar.gz
>>
>> Ansonsten ist die Problematik bekannt:
>> https://bz.apache.org/ooo/show_bug.cgi?id=127315
>>
>> Gruß, Matthias
>>
>>
>> Am 02.12.2017 um 09:07 schrieb Josef Latt:
>>> Hi,
>>>
>>> habe mal AOO 4.2.0
>>> (Apache_OpenOffice_4.2.0_Linux_x86-64_install-deb_de_2017-12-01_04_16_00_1816793)
>>> über die 4.1.5
>>> installiert und folgendes festgestellt:
>>>
>>> - Writer zeigt beim Start / Öffnen einer Datei eine Nachricht
>>> 'Allgemeiner Fehler' (Screenshot: Writer.png). Mit neuem Userverzeichnis
>>> nur beim Öffnen einer Datei.
>>>
>>> -Calc zeigt beim Öffnen einer Datei eine Nachricht 'Es können nicht alle
>>> Eigenschaften gelesen werden' (Screenshot: Calc.png).
>>>
>>> Nach quittieren der Nachricht funktionieren die Programme soweit problemlos.
>>>
>>> Gruß
>>> Josef
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: users-de-unsubscr...@openoffice.apache.org
>>> For additional commands, e-mail: users-de-h...@openoffice.apache.org
> -
> To unsubscribe, e-mail: users-de-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: users-de-h...@openoffice.apache.org
>




smime.p7s
Description: S/MIME Cryptographic Signature


Re: [Issue 20819] add polynomial regression type

2017-12-02 Thread Peter Kovacs
Am Freitag, den 01.12.2017, 18:17 +0100 schrieb Marcus:
> Am 01.12.2017 um 18:09 schrieb Peter Kovacs:
> > For me the existance is not a strong argument. The bug is with 149
> > votes 
> > quite popular. The discussion there is a repeatance that this is
> > basic 
> > feature.
> 
> but we don't know from when the votes are. Or is there a possiblity
> to 
> see in Bugzilla? The issue report is old as we can see on the ID.
> The 
> extension could have been created after all or the most votes were
> done.
Since you can not renew your vote have to assume the vote goes to
provide a feature. It is difficult to dstinguish. However it is a
strongly requested feature that we can read from it.

The best way imho is to let the users vote. How about follwing flow:
1) check if we can include the extention by license or find an
agreement with the maintainers.
2) Put a call to Vote if the package should be included or not on the
Forums, as sticky.
3) advertise the vote and have a discussion with the community.
(Announcement, Youtube, Googleplus, facebook, user mailing list
4) After a month we gather the results and follow the desicion.

To be clear, I am not favoured for or against inclusion of an
extention. But for me it is crucial that people can see a concept
behind our decisions. 

We said we would like to give our users a voice. Wouldn't it be
appropriate to give them exactly this voice? This is a clear concept to
me.

[...]
> So what is basic and what is not? If we do not integrate this
> > extention 
> > into Open Office then we need to explain this.
> 
> Maybe because we have an *Office* Suite and not a *Mathematical*
> Suite? 
> ;-) Seriously, I see  this as special mathematical featute and not a 
> basic feature for a software suite that contains also a word
> processor, 
> drawing, a presentation application and also database.
calc is the mathematical processor in our suite.
Which sense does it make if declare math as advanced? ;)
> > clear 
> > out any impression that there are 2 class developers.
> > Imho we must try to incorperate extention developers closer to the
> > core 
> > team. If we want new people, there is the source of volunteers.
> 
> OK, this is a very good point that we can follow. Maybe we can
> indeed 
> get some people that are willing to stay longer and to help us with
> the 
> core application.
Yay! :-D
More opinions please!

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



Re: A more sane way to build - SCons, deCygwination and other hopes

2017-12-02 Thread Peter Kovacs
sounds great from what you write. Lets try SCons build system.
Where can I find your changes so I can help? Have you checked them into
trunk?

I have some expreience with python, which will come in handy.

Meanwhile I read Scons Documentation.

Am Samstag, den 02.12.2017, 10:05 +0200 schrieb Damjan Jovanovic:
> Hi
> 
> After days of failing to add a few new simple features to gbuild,
> I've now
> reached my limits, and have begun experimenting with the SCons build
> system
> instead.
> 
> It's starting to work. Having ported some of gbuild.mk, LinkTarget.mk
> and
> platform/freebsd.mk to SCons, as well as a module's local gbuild
> files, I
> can now compile files and (badly) link them into libraries, and clean
> the
> build.
> 
> SCons is an advanced next-generation build system like gbuild, with
> high
> level declarative syntax in Python, support for multiple modules that
> build
> in parallel, header dependencies, file change detection through MD5
> sums of
> contents instead of timestamps so rebuilds are faster, etc. It builds
> C,
> C++, Objective C, Java, Fortran, D, the sorely necessary Flex and
> Yacc that
> gbuild doesn't support. It supports tons of platforms and compilers,
> including OS/2. It's maintainable and usable, can print debugging
> info such
> as dependency trees, and is generally pleasant to work with. We've
> discussed it before on this list, but I never got to trying it until
> now.
> 
> Virtually everything gbuild does, is already done by SCons, and often
> done
> much better. The syntax for SCons files is similar/related to
> gbuild's
> syntax, so an automated conversion from gbuild to SCons might even be
> possible.
> 
> So far, I have defines, includes and C[XX]FLAGS working. I've
> structured it
> a bit better, with platform-specific files in classes that only
> provide
> variables to slot in higher up, instead of one giant set of globally
> mutable global variables like in gbuild. Linking still needs a bit of
> work.
> Windows is next on the list, as Cygwin will be the ultimate test of
> whether
> we can use it.
> 
> I am very hopeful. SCons has a long history and is used by other
> projects,
> while only OO.o derivatives use gbuild. It's well documented. It
> supports
> features we need which gbuild doesn't, like library version names and
> flex/yacc. It's supposed to work on Windows, both inside and outside
> of
> Cygwin and could help us build without Cygwin some day. It supports
> many
> versions of Visual Studio and could help us in upgrading to a new
> one. We
> will need to add custom builders to SCons for our custom file formats
> like
> IDL, but it's just Python, not my favorite language but infinitely
> better
> than GNU make.
> 
> It would help if someone could review my changes, as I am not very
> familiar
> with Python and there might be better ways to write some of the code.
> I'll
> post a patch for review after some further development.
> 
> Thank you
> Damjan

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



A more sane way to build - SCons, deCygwination and other hopes

2017-12-02 Thread Damjan Jovanovic
Hi

After days of failing to add a few new simple features to gbuild, I've now
reached my limits, and have begun experimenting with the SCons build system
instead.

It's starting to work. Having ported some of gbuild.mk, LinkTarget.mk and
platform/freebsd.mk to SCons, as well as a module's local gbuild files, I
can now compile files and (badly) link them into libraries, and clean the
build.

SCons is an advanced next-generation build system like gbuild, with high
level declarative syntax in Python, support for multiple modules that build
in parallel, header dependencies, file change detection through MD5 sums of
contents instead of timestamps so rebuilds are faster, etc. It builds C,
C++, Objective C, Java, Fortran, D, the sorely necessary Flex and Yacc that
gbuild doesn't support. It supports tons of platforms and compilers,
including OS/2. It's maintainable and usable, can print debugging info such
as dependency trees, and is generally pleasant to work with. We've
discussed it before on this list, but I never got to trying it until now.

Virtually everything gbuild does, is already done by SCons, and often done
much better. The syntax for SCons files is similar/related to gbuild's
syntax, so an automated conversion from gbuild to SCons might even be
possible.

So far, I have defines, includes and C[XX]FLAGS working. I've structured it
a bit better, with platform-specific files in classes that only provide
variables to slot in higher up, instead of one giant set of globally
mutable global variables like in gbuild. Linking still needs a bit of work.
Windows is next on the list, as Cygwin will be the ultimate test of whether
we can use it.

I am very hopeful. SCons has a long history and is used by other projects,
while only OO.o derivatives use gbuild. It's well documented. It supports
features we need which gbuild doesn't, like library version names and
flex/yacc. It's supposed to work on Windows, both inside and outside of
Cygwin and could help us build without Cygwin some day. It supports many
versions of Visual Studio and could help us in upgrading to a new one. We
will need to add custom builders to SCons for our custom file formats like
IDL, but it's just Python, not my favorite language but infinitely better
than GNU make.

It would help if someone could review my changes, as I am not very familiar
with Python and there might be better ways to write some of the code. I'll
post a patch for review after some further development.

Thank you
Damjan