Re: [PR] Blog post about development on trunk branch [openoffice-project]

[via GitHub]

ardovm merged PR #11:
URL: https://github.com/apache/openoffice-project/pull/11


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


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

[PR] Blog post about development on trunk branch [openoffice-project]

[via GitHub]

ardovm opened a new pull request, #11:
URL: https://github.com/apache/openoffice-project/pull/11

   Proposal for blog post about our latest development on the trunk branch.
   
   **Note**: The post is dated 2 April.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


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

Re: ODF 1.3 development

[Keith N. McKenna]

Gavin McDonald wrote:

Hi Keith,

On Tue, Jan 16, 2024 at 5:32 PM Keith N. McKenna 
wrote:


Marcus wrote:

I would like to move the other Wiki content into Confluence as
management is better there. However, it's may too much for my free time.


Even if you could move it, the mwiki would need to stay active as it
does not appear that cwiki has a file upload to use it to distribute or
documentation.



Can I get an example of what you mean please Keith, so I can compare and at
least
take a look on the cwiki side.

  Thanks

Gav...



Regards
Keith






Gavin;

The mwiki has a file upload function that we use to upload PDF ODT files 
of our uder guides. We then link those files to specific pages of the 
wiki from which users can can download them.


For example for The Getting Started Guided we first upload the book file 
to the wikiAnd then link to the Apache OpenOffice 4.1 User Guides (PDF) 
page.


I hope this helps, if not let me know.

Regards
Keith



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

Re: ODF 1.3 development

[Marcus]

Am 16.01.24 um 17:32 schrieb Keith N. McKenna:

Marcus wrote:
I would like to move the other Wiki content into Confluence as 
management is better there. However, it's may too much for my free time.


Even if you could move it, the mwiki would need to stay active as it 
does not appear that cwiki has a file upload to use it to distribute or 
documentation.


sure, I don't meant to move everything, so that it is empty.
It's more the "normal" documentation on the pages itself. ;-)

Marcus


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

Re: ODF 1.3 development

[Gavin McDonald]

Hi Keith,

On Tue, Jan 16, 2024 at 5:32 PM Keith N. McKenna 
wrote:

> Marcus wrote:
> > I would like to move the other Wiki content into Confluence as
> > management is better there. However, it's may too much for my free time.
>
> Even if you could move it, the mwiki would need to stay active as it
> does not appear that cwiki has a file upload to use it to distribute or
> documentation.
>

Can I get an example of what you mean please Keith, so I can compare and at
least
take a look on the cwiki side.

 Thanks

Gav...


> Regards
> Keith
>
>
>

Re: ODF 1.3 development

[Keith N. McKenna]

Marcus wrote:
I would like to move the other Wiki content into Confluence as 
management is better there. However, it's may too much for my free time.


Even if you could move it, the mwiki would need to stay active as it 
does not appear that cwiki has a file upload to use it to distribute or 
documentation.


Regards
Keith


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

Re: ODF 1.3 development

[Marcus]

Am 14.01.24 um 18:44 schrieb Damjan Jovanovic:

On Fri, Jan 12, 2024 at 7:23 PM Marcus  wrote:

Am 12.01.24 um 19:19 schrieb Marcus:

Am 10.01.24 um 06:36 schrieb Damjan Jovanovic:

[...]

Can someone please create such a Wiki page, or give me access to do so?

[...]


that's a good idea. I'll create a new page in our Confluence Wiki.


please have look here:

https://cwiki.apache.org/confluence/display/OOOUSERS/ODF+1.3+Changes

You should have access to the page, so you can finish the first items
yourself.


Thank you. I was hoping to use Mediawiki. I don't know why anyone uses
Confluence. It's terrible, bloated, slow, expensive, messy, proprietary and
closed source. The ASF is probably only getting it for free as a form of
marketing.


I cannot see the most as disadvantages, especially together with JIRA 
it's great - which we are not using.



Anyway since so much was added to Confluence already, I've decided to
continue there, and have added the part 2 and part 4 tasks as well now, and
updated the items I already looked at.


I would like to move the other Wiki content into Confluence as 
management is better there. However, it's may too much for my free time.


Marcus


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

Re: ODF 1.3 development

[Damjan Jovanovic]

On Fri, Jan 12, 2024 at 7:23 PM Marcus  wrote:

> Am 12.01.24 um 19:19 schrieb Marcus:
> > Am 10.01.24 um 06:36 schrieb Damjan Jovanovic:
> >> [...]
> >>
> >> Can someone please create such a Wiki page, or give me access to do so?
> >>
> >> [...]
> >
> > that's a good idea. I'll create a new page in our Confluence Wiki.
>
> please have look here:
>
> https://cwiki.apache.org/confluence/display/OOOUSERS/ODF+1.3+Changes
>
> You should have access to the page, so you can finish the first items
> yourself.
>
>
Thank you. I was hoping to use Mediawiki. I don't know why anyone uses
Confluence. It's terrible, bloated, slow, expensive, messy, proprietary and
closed source. The ASF is probably only getting it for free as a form of
marketing.

Anyway since so much was added to Confluence already, I've decided to
continue there, and have added the part 2 and part 4 tasks as well now, and
updated the items I already looked at.

Thank you
Damjan

Re: ODF 1.3 development

[Matthias Seidel]

Hi Marcus,

Am 12.01.24 um 20:23 schrieb Marcus:

Am 12.01.24 um 19:19 schrieb Marcus:

Am 10.01.24 um 06:36 schrieb Damjan Jovanovic:

[...]

Can someone please create such a Wiki page, or give me access to do so?

[...]


that's a good idea. I'll create a new page in our Confluence Wiki.


please have look here:

https://cwiki.apache.org/confluence/display/OOOUSERS/ODF+1.3+Changes


That looks great!

Matthias



You should have access to the page, so you can finish the first items 
yourself.


Marcus


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



smime.p7s
Description: Kryptografische S/MIME-Signatur

Re: ODF 1.3 development

[Marcus]

Am 12.01.24 um 19:19 schrieb Marcus:

Am 10.01.24 um 06:36 schrieb Damjan Jovanovic:

[...]

Can someone please create such a Wiki page, or give me access to do so?

[...]


that's a good idea. I'll create a new page in our Confluence Wiki.


please have look here:

https://cwiki.apache.org/confluence/display/OOOUSERS/ODF+1.3+Changes

You should have access to the page, so you can finish the first items 
yourself.


Marcus


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

Re: ODF 1.3 development

[Marcus]

Am 10.01.24 um 06:36 schrieb Damjan Jovanovic:

[...]

Can someone please create such a Wiki page, or give me access to do so?

[...]


that's a good idea. I'll create a new page in our Confluence Wiki.

Marcus


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

ODF 1.3 development

[Damjan Jovanovic]

Hi

I've started looking at how to add ODF 1.3 support to OpenOffice.

If you scroll to the end of the monstrously long part 3 of the ODF 1.3
specification at
https://docs.oasis-open.org/office/OpenDocument/v1.3/os/part3-schema/OpenDocument-v1.3-os-part3-schema.html
where you'll see "Appendix G: Changes From ODF 1.2 (Non Normative)".
Then examine:

"Document Fields – General 7.3.1 Office-3783"

and you follow that link to "Office-3783" and have a read, you'll see that
all it does is *fix a typo*:
Section 7.3.1 used to contain "OpenDocument fields display information
about the current document or about a specific part of the current
document.," - note the superfluous comma at the end - and now ends without
that comma!

So that item can immediately be ticked off as completed, because there is
nothing we have to do.

The same is also true for at least:
"table:table-background 19.733 Office-3954"

And:
"Normative References 1.3 Office-3868"
updates the  tag to refer to RFC6838 instead of the
older RFC4288, which also might require no work to implement.

So what we need is a table in our Wiki, with all "Changes From ODF 1.2"
items from all the 1.3 documents (there's several), and then to read over
them and mark off the ones that are irrelevant or complete, and track
progress on the other items where we do have some development to do on our
side.

Can someone please create such a Wiki page, or give me access to do so?

And out of interest, how do you find how and where we use an XML element or
attribute? For example let's examine:
 10.4.7 Office-2044
which is deprecated by ODF 1.3.
First remember our XML parsing doesn't work on strings, that would be too
slow. Rather strings are converted to unique integers, and then we do fast
integer comparisons.
So if you go to main/xmloff and "grep applet * -R" you'll see:
source/core/xmltoken.cxx:TOKEN( "applet",
 XML_APPLET ),
where XML_APPLET is an integer constant (from an enum) that the "applet"
element will be converted to.
Then go to OpenGrok and do a "Full Search" for "XML_APPLET", and you can
see where that's used.

I've also created a local odf-1.3 Git branch for any development, but at
present it only has 1 small patch to stop the version upgrade warning:

---snip---
diff --git a/main/sfx2/source/doc/objstor.cxx
b/main/sfx2/source/doc/objstor.cxx
index d794747b60..89ab8e1ca3 100644
--- a/main/sfx2/source/doc/objstor.cxx
+++ b/main/sfx2/source/doc/objstor.cxx
@@ -856,8 +856,8 @@ sal_Bool SfxObjectShell::DoLoad( SfxMedium *pMed )
 if ( sVersion.getLength() )
 {
 double nVersion = sVersion.toDouble();
-if ( nVersion > 1.20001  &&
SfxObjectShell_Impl::NeedsOfficeUpdateDialog() )
-// ODF version greater than 1.2 - added some
decimal places to be safe against floating point conversion errors (hack)
+if ( nVersion > 1.30001  &&
SfxObjectShell_Impl::NeedsOfficeUpdateDialog() )
+// ODF version greater than 1.3 - added some
decimal places to be safe against floating point conversion errors (hack)
 {
 ::rtl::OUString sDocumentURL(
pMedium->GetOrigURL() );
 ::rtl::OUString aSystemFileURL;
---snip---

If others want to help, I'd rather push that branch upstream soon, so we
can work on it together?

Regards
Damjan

Re: [www] Website Development

[Peter Kovacs]

Hello Rizwan,

Thank you for taking interest in the OpenOffice Project.

We are not really organized in an industrial way. We are volunteers 
working on this project for the public welfare.


However we have always need for volunteers. One main difference is that 
we do not use hierarchical structures unlike common in industry.


We move by consent and meritocracy principles.


You know best how your skills are used. It is up to you how you engage.

 I see following topics in web sphere, without any priority applied:

 * robot.txt for mediawiki, forum (maybe better title is outtakes
   mediawiki & forum)
 * migration pootle
 * update mediawiki
 * migration blog to pelican
 * update opengrok
 * migration to container based services (actually I see that as part
   of above points)
 * we need to do something with the extension page
 * forum maintenance

anyone has more points web related?


All the best

Peter

Am 13.05.23 um 08:46 schrieb rizwan riaz:

Hey Everyone!

I wanted to take a moment to express my enthusiasm for joining the
OpenOffice developers community and contributing to shaping the OpenOffice
website. As an undergraduate university student expected to graduate next
year, I am eager to gain real-world experience that can complement my
academic knowledge and help me grow in the industry.

I bring a range of skills to the table that I believe could be valuable for
the OpenOffice project. I am proficient in *HTML5, CSS3, TailwindCSS,
JavaScript, Python, and C++*. Additionally, I have hands-on experience
building websites using *Django, Django Rest, and ReactJS*. I have taken
the initiative to create various projects and have showcased them on my
GitHub profile:https://github.com/iamrizwan077.

Joining the OpenOffice developers community would provide me with an
incredible opportunity to contribute to an open-source project and
collaborate with talented individuals who share a passion for software
development. I am excited to contribute my skills and knowledge to enhance
the OpenOffice website and make it even more user-friendly and functional.

I am confident that working with the OpenOffice developers community will
not only help me gain invaluable industry experience but also provide me
with the chance to learn from experienced developers and improve my
abilities in a collaborative environment.

Thank you for considering my application. I look forward to the possibility
of joining the OpenOffice developers community and making a meaningful
contribution to the project.

Best regards,

Rizwan

[www] Website Development

[rizwan riaz]

Hey Everyone!

I wanted to take a moment to express my enthusiasm for joining the
OpenOffice developers community and contributing to shaping the OpenOffice
website. As an undergraduate university student expected to graduate next
year, I am eager to gain real-world experience that can complement my
academic knowledge and help me grow in the industry.

I bring a range of skills to the table that I believe could be valuable for
the OpenOffice project. I am proficient in *HTML5, CSS3, TailwindCSS,
JavaScript, Python, and C++*. Additionally, I have hands-on experience
building websites using *Django, Django Rest, and ReactJS*. I have taken
the initiative to create various projects and have showcased them on my
GitHub profile: https://github.com/iamrizwan077.

Joining the OpenOffice developers community would provide me with an
incredible opportunity to contribute to an open-source project and
collaborate with talented individuals who share a passion for software
development. I am excited to contribute my skills and knowledge to enhance
the OpenOffice website and make it even more user-friendly and functional.

I am confident that working with the OpenOffice developers community will
not only help me gain invaluable industry experience but also provide me
with the chance to learn from experienced developers and improve my
abilities in a collaborative environment.

Thank you for considering my application. I look forward to the possibility
of joining the OpenOffice developers community and making a meaningful
contribution to the project.

Best regards,

Rizwan

Re: How do I sign up for Apache Open Office development contributor ?

[Peter Kovacs]

Hi Chris,


Am 03.11.22 um 22:56 schrieb chris deen:

Hey thanks Peter I really appreciate it.

At the risk of showing my ignorance I will say that if you can provide 
a link demonstrating what you mean by working with mailing list that 
would be a help.


No problem, you are welcome. check out 
https://openoffice.apache.org/mailing-lists.html


important for development is the dev mailing list you already 
communicate with. if you have questions or ideas feel free to share.


btw. there is also a archive. check this mail from damjan:

https://lists.apache.org/list?dev@openoffice.apache.org:lte=1M:expat

maybe another nice starting point.



Other than that I'm comfortable with GitHub and doing actual coding, 
of course.


I look forward to working on the projects!


I hope we can make more steps forward.




On Thu, Nov 3, 2022, 5:45 PM Peter Kovacs  wrote:

Hi Chris,

this is the right email mailing list. Do you know how to work with
mailing lists?

best way to hand in your work is through GitHub [1]. you can
submit your work there for review.

our priority list [2]

how to build AOO [3]

if you have questions just ask away...


all the best

Peter

[1] https://github.com/apache/openoffice
<https://github.com/apache/openoffice-org>

[2]
https://cwiki.apache.org/confluence/display/OOOUSERS/Blocker+issues+4.2.0

[3] https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO

Am 03.11.22 um 22:11 schrieb chris deen:

Hello!
I am trying to locate the correct email address to get involved
in working on Apache OpenOffice. I am trying to bring my C++
skills up to date and am looking for volunteer opportunities to
do so. This sounds like the perfect way to do so!

I followed the link from this page:
https://www.openoffice.org/download/

image.png


Thanks !

Re: How do I sign up for Apache Open Office development contributor ?

[chris deen]

Hey thanks Peter I really appreciate it.

At the risk of showing my ignorance I will say that if you can provide a
link demonstrating what you mean by working with mailing list that would be
a help.

Other than that I'm comfortable with GitHub and doing actual coding, of
course.

I look forward to working on the projects!


On Thu, Nov 3, 2022, 5:45 PM Peter Kovacs  wrote:

> Hi Chris,
>
> this is the right email mailing list. Do you know how to work with mailing
> lists?
>
> best way to hand in your work is through GitHub [1]. you can submit your
> work there for review.
>
> our priority list [2]
>
> how to build AOO [3]
>
> if you have questions just ask away...
>
>
> all the best
>
> Peter
>
> [1] https://github.com/apache/openoffice
> 
>
> [2]
> https://cwiki.apache.org/confluence/display/OOOUSERS/Blocker+issues+4.2.0
>
> [3] https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO
> Am 03.11.22 um 22:11 schrieb chris deen:
>
> Hello!
> I am trying to locate the correct email address to get involved in working
> on Apache OpenOffice. I am trying to bring my C++ skills up to date and am
> looking for volunteer opportunities to do so. This sounds like the perfect
> way to do so!
>
> I followed the link from this page:
> https://www.openoffice.org/download/
>
> [image: image.png]
>
>
> Thanks !
>
>
>

Re: How do I sign up for Apache Open Office development contributor ?

[Peter Kovacs]

Hi Chris,

this is the right email mailing list. Do you know how to work with 
mailing lists?


best way to hand in your work is through GitHub [1]. you can submit your 
work there for review.


our priority list [2]

how to build AOO [3]

if you have questions just ask away...


all the best

Peter

[1] https://github.com/apache/openoffice

[2] 
https://cwiki.apache.org/confluence/display/OOOUSERS/Blocker+issues+4.2.0


[3] https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO

Am 03.11.22 um 22:11 schrieb chris deen:

Hello!
I am trying to locate the correct email address to get involved in 
working on Apache OpenOffice. I am trying to bring my C++ skills up to 
date and am looking for volunteer opportunities to do so. This sounds 
like the perfect way to do so!


I followed the link from this page:
https://www.openoffice.org/download/

image.png


Thanks !

How do I sign up for Apache Open Office development contributor ?

[chris deen]

Hello!
I am trying to locate the correct email address to get involved in working
on Apache OpenOffice. I am trying to bring my C++ skills up to date and am
looking for volunteer opportunities to do so. This sounds like the perfect
way to do so!

I followed the link from this page:
https://www.openoffice.org/download/

[image: image.png]


Thanks !

Re: catalina branch waiting for reviews [Was: [Mini] Setup of development environment]

[Matthias Seidel]

Hi Jim,

Am 20.07.21 um 17:21 schrieb Jim Jagielski:
>
>> On Jul 19, 2021, at 10:26 AM, Matthias Seidel  
>> wrote:
>>
>> Hi Jim,
>>
>> People need macOS builds more frequently to test.
>>
> Agreed. But every time I seem to encourage a test macOS build, it seems that 
> people want to hold off...

I do my Windows builds frequently.

Nobody holds me off... ;-)

> -
> 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: catalina branch waiting for reviews [Was: [Mini] Setup of development environment]

[Jim Jagielski]

> On Jul 19, 2021, at 10:26 AM, Matthias Seidel  
> wrote:
> 
> Hi Jim,
> 
> People need macOS builds more frequently to test.
> 

Agreed. But every time I seem to encourage a test macOS build, it seems that 
people want to hold off...
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: catalina branch waiting for reviews [Was: [Mini] Setup of development environment]

[Matthias Seidel]

Hi Jim,

Nothing is wrong, but we have this machine from MacStadium and we can
set it up as a build bot.
People need macOS builds more frequently to test.

It is also good when Arrigo is able to build for macOS (as he can now
build for Windows).

Regards,

   Matthias

Am 19.07.21 um 16:14 schrieb Jim Jagielski:
> What is wrong w/ using the build stuff that we have used for years?
>
>> On Jul 18, 2021, at 9:00 AM, Arrigo Marchiori  
>> wrote:
>>
>> Dear All,
>>
>> On Sat, Jul 17, 2021 at 03:27:54PM +0200, Arrigo Marchiori wrote:
>>
>>> Dear All,
>>>
>>> I just committed the "catalina" branch:
>>> https://github.com/apache/openoffice/tree/catalina
>>>
>>> The required environment variables on our Mac Mini are the following:
>>>
>>> export LC_CTYPE=en_US.UTF-8
>>> export LANG=en_US.UTF-8
>>> export 
>>> PATH=${HOME}/bin:/opt/local/bin:/opt/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:$PATH
>>> export LIBRARY_PATH=/usr/local/lib
>>> export C_INCLUDE_PATH=/usr/local/include
>>> export CPLUS_INCLUDE_PATH=/usr/local/include
>>> export MACOSX_DEPLOYMENT_TARGET=10.7 
>>> export 
>>> SDKROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk
>>> export CFLAGS="$CFLAGS -mmacosx-version-min=10.7 -isysroot $SDKROOT" 
>>> export CXXFLAGS="$CXXFLAGS -mmacosx-version-min=10.7 -isysroot $SDKROOT"
>>> export LDFLAGS="$LDFLAGS -mmacosx-version-min=10.7 -isysroot $SDKROOT"
>>> export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig
>>>
>>> I am testing the branch under Linux, and next Windows if I will find
>>> time, to make sure I did not break anything.
>> I could build the branch successfully under Linux and Windows.
>>
>>> Reviews are very welcome.
>> Anyone with a Mac is invited to kindly test this build:
>> http://home.apache.org/~ardovm/openoffice/catalina/2021-07-18/
>>
>> I opened a PR on GitHub:
>> https://github.com/apache/openoffice/pull/135
>> that gives a clear overview of all the edits.
>>
>> The following note remains valid:
>>
 I met a problem with the writerfilter module. It was given by the
 proposed libxml and libxslt pair by the build script [1].
 The problem was reported here: [2].

 Solution: use libxslt 1.34 instead of 1.33.
 Let's not forget to update the build script [1].

 References:

  1: 
 https://svn.apache.org/viewvc/openoffice/devtools/build-scripts/4.1.10/unxmacos/build_aoo64bit_on_macos.sh?view=markup

  2: https://gitlab.gnome.org/GNOME/libxml2/-/issues/66
>> Best regards,
>> -- 
>> Arrigo
>>
>> -
>> 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: catalina branch waiting for reviews [Was: [Mini] Setup of development environment]

[Jim Jagielski]

What is wrong w/ using the build stuff that we have used for years?

> On Jul 18, 2021, at 9:00 AM, Arrigo Marchiori  wrote:
> 
> Dear All,
> 
> On Sat, Jul 17, 2021 at 03:27:54PM +0200, Arrigo Marchiori wrote:
> 
>> Dear All,
>> 
>> I just committed the "catalina" branch:
>> https://github.com/apache/openoffice/tree/catalina
>> 
>> The required environment variables on our Mac Mini are the following:
>> 
>> export LC_CTYPE=en_US.UTF-8
>> export LANG=en_US.UTF-8
>> export 
>> PATH=${HOME}/bin:/opt/local/bin:/opt/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:$PATH
>> export LIBRARY_PATH=/usr/local/lib
>> export C_INCLUDE_PATH=/usr/local/include
>> export CPLUS_INCLUDE_PATH=/usr/local/include
>> export MACOSX_DEPLOYMENT_TARGET=10.7 
>> export 
>> SDKROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk
>> export CFLAGS="$CFLAGS -mmacosx-version-min=10.7 -isysroot $SDKROOT" 
>> export CXXFLAGS="$CXXFLAGS -mmacosx-version-min=10.7 -isysroot $SDKROOT"
>> export LDFLAGS="$LDFLAGS -mmacosx-version-min=10.7 -isysroot $SDKROOT"
>> export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig
>> 
>> I am testing the branch under Linux, and next Windows if I will find
>> time, to make sure I did not break anything.
> 
> I could build the branch successfully under Linux and Windows.
> 
>> Reviews are very welcome.
> 
> Anyone with a Mac is invited to kindly test this build:
> http://home.apache.org/~ardovm/openoffice/catalina/2021-07-18/
> 
> I opened a PR on GitHub:
> https://github.com/apache/openoffice/pull/135
> that gives a clear overview of all the edits.
> 
> The following note remains valid:
> 
>>> I met a problem with the writerfilter module. It was given by the
>>> proposed libxml and libxslt pair by the build script [1].
>>> The problem was reported here: [2].
>>> 
>>> Solution: use libxslt 1.34 instead of 1.33.
>>> Let's not forget to update the build script [1].
>>> 
>>> References:
>>> 
>>>  1: 
>>> https://svn.apache.org/viewvc/openoffice/devtools/build-scripts/4.1.10/unxmacos/build_aoo64bit_on_macos.sh?view=markup
>>> 
>>>  2: https://gitlab.gnome.org/GNOME/libxml2/-/issues/66
> 
> Best regards,
> -- 
> Arrigo
> 
> -
> 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: catalina branch waiting for reviews [Was: [Mini] Setup of development environment]

[Arrigo Marchiori]

On Sun, Jul 18, 2021 at 04:41:09PM +0200, Matthias Seidel wrote:

> Hi Arrigo,
> 
> I did a short test and it seems that
> 
> https://bz.apache.org/ooo/show_bug.cgi?id=127154
> 
> is fixed in that build?

Thank you for the pointer... I tried to reproduce it and unfortunately
AOO hung on the dialog asking to confirm the installation.
So my findings are: the bug seems to still be there.

> However, "Checking for Updates" did crash AOO (once).

This is new to me... as well as the whole macOS ecosystem :-P
Did this also happen with the official build?

Best regards,
-- 
Arrigo

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

Re: catalina branch waiting for reviews [Was: [Mini] Setup of development environment]

[Matthias Seidel]

Hi Arrigo,

I did a short test and it seems that

https://bz.apache.org/ooo/show_bug.cgi?id=127154

is fixed in that build?

However, "Checking for Updates" did crash AOO (once).

Regards,

   Matthias

Am 18.07.21 um 15:00 schrieb Arrigo Marchiori:
> Dear All,
>
> On Sat, Jul 17, 2021 at 03:27:54PM +0200, Arrigo Marchiori wrote:
>
>> Dear All,
>>
>> I just committed the "catalina" branch:
>> https://github.com/apache/openoffice/tree/catalina
>>
>> The required environment variables on our Mac Mini are the following:
>>
>> export LC_CTYPE=en_US.UTF-8
>> export LANG=en_US.UTF-8
>> export 
>> PATH=${HOME}/bin:/opt/local/bin:/opt/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:$PATH
>> export LIBRARY_PATH=/usr/local/lib
>> export C_INCLUDE_PATH=/usr/local/include
>> export CPLUS_INCLUDE_PATH=/usr/local/include
>> export MACOSX_DEPLOYMENT_TARGET=10.7 
>> export 
>> SDKROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk
>> export CFLAGS="$CFLAGS -mmacosx-version-min=10.7 -isysroot $SDKROOT" 
>> export CXXFLAGS="$CXXFLAGS -mmacosx-version-min=10.7 -isysroot $SDKROOT"
>> export LDFLAGS="$LDFLAGS -mmacosx-version-min=10.7 -isysroot $SDKROOT"
>> export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig
>>
>> I am testing the branch under Linux, and next Windows if I will find
>> time, to make sure I did not break anything.
> I could build the branch successfully under Linux and Windows.
>
>> Reviews are very welcome.
> Anyone with a Mac is invited to kindly test this build:
> http://home.apache.org/~ardovm/openoffice/catalina/2021-07-18/
>
> I opened a PR on GitHub:
> https://github.com/apache/openoffice/pull/135
> that gives a clear overview of all the edits.
>
> The following note remains valid:
>
>>> I met a problem with the writerfilter module. It was given by the
>>> proposed libxml and libxslt pair by the build script [1].
>>> The problem was reported here: [2].
>>>
>>> Solution: use libxslt 1.34 instead of 1.33.
>>> Let's not forget to update the build script [1].
>>>
>>> References:
>>>
>>>   1: 
>>> https://svn.apache.org/viewvc/openoffice/devtools/build-scripts/4.1.10/unxmacos/build_aoo64bit_on_macos.sh?view=markup
>>>
>>>   2: https://gitlab.gnome.org/GNOME/libxml2/-/issues/66
> Best regards,



smime.p7s
Description: S/MIME Cryptographic Signature

Re: catalina branch waiting for reviews [Was: [Mini] Setup of development environment]

[Pedro Lino]

Hi Arrigo

I do not have any Apple devices :)

Did you build any Linux binaries (DEBs)? Can you share a link?

Thanks!
Pedro

> On 07/18/2021 2:00 PM Arrigo Marchiori  wrote:
> 
>  
> Dear All,
> 
> On Sat, Jul 17, 2021 at 03:27:54PM +0200, Arrigo Marchiori wrote:
> 
> > Dear All,
> > 
> > I just committed the "catalina" branch:
> > https://github.com/apache/openoffice/tree/catalina
> > 
> > The required environment variables on our Mac Mini are the following:
> > 
> > export LC_CTYPE=en_US.UTF-8
> > export LANG=en_US.UTF-8
> > export 
> > PATH=${HOME}/bin:/opt/local/bin:/opt/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:$PATH
> > export LIBRARY_PATH=/usr/local/lib
> > export C_INCLUDE_PATH=/usr/local/include
> > export CPLUS_INCLUDE_PATH=/usr/local/include
> > export MACOSX_DEPLOYMENT_TARGET=10.7 
> > export 
> > SDKROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk
> > export CFLAGS="$CFLAGS -mmacosx-version-min=10.7 -isysroot $SDKROOT" 
> > export CXXFLAGS="$CXXFLAGS -mmacosx-version-min=10.7 -isysroot $SDKROOT"
> > export LDFLAGS="$LDFLAGS -mmacosx-version-min=10.7 -isysroot $SDKROOT"
> > export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig
> > 
> > I am testing the branch under Linux, and next Windows if I will find
> > time, to make sure I did not break anything.
> 
> I could build the branch successfully under Linux and Windows.
> 
> > Reviews are very welcome.
> 
> Anyone with a Mac is invited to kindly test this build:
> http://home.apache.org/~ardovm/openoffice/catalina/2021-07-18/
> 
> I opened a PR on GitHub:
> https://github.com/apache/openoffice/pull/135
> that gives a clear overview of all the edits.
> 
> The following note remains valid:
> 
> > > I met a problem with the writerfilter module. It was given by the
> > > proposed libxml and libxslt pair by the build script [1].
> > > The problem was reported here: [2].
> > > 
> > > Solution: use libxslt 1.34 instead of 1.33.
> > > Let's not forget to update the build script [1].
> > > 
> > > References:
> > > 
> > >   1: 
> > > https://svn.apache.org/viewvc/openoffice/devtools/build-scripts/4.1.10/unxmacos/build_aoo64bit_on_macos.sh?view=markup
> > > 
> > >   2: https://gitlab.gnome.org/GNOME/libxml2/-/issues/66
> 
> Best regards,
> -- 
> Arrigo
> 
> -
> 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

catalina branch waiting for reviews [Was: [Mini] Setup of development environment]

[Arrigo Marchiori]

Dear All,

On Sat, Jul 17, 2021 at 03:27:54PM +0200, Arrigo Marchiori wrote:

> Dear All,
> 
> I just committed the "catalina" branch:
> https://github.com/apache/openoffice/tree/catalina
> 
> The required environment variables on our Mac Mini are the following:
> 
> export LC_CTYPE=en_US.UTF-8
> export LANG=en_US.UTF-8
> export 
> PATH=${HOME}/bin:/opt/local/bin:/opt/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:$PATH
> export LIBRARY_PATH=/usr/local/lib
> export C_INCLUDE_PATH=/usr/local/include
> export CPLUS_INCLUDE_PATH=/usr/local/include
> export MACOSX_DEPLOYMENT_TARGET=10.7 
> export 
> SDKROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk
> export CFLAGS="$CFLAGS -mmacosx-version-min=10.7 -isysroot $SDKROOT" 
> export CXXFLAGS="$CXXFLAGS -mmacosx-version-min=10.7 -isysroot $SDKROOT"
> export LDFLAGS="$LDFLAGS -mmacosx-version-min=10.7 -isysroot $SDKROOT"
> export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig
> 
> I am testing the branch under Linux, and next Windows if I will find
> time, to make sure I did not break anything.

I could build the branch successfully under Linux and Windows.

> Reviews are very welcome.

Anyone with a Mac is invited to kindly test this build:
http://home.apache.org/~ardovm/openoffice/catalina/2021-07-18/

I opened a PR on GitHub:
https://github.com/apache/openoffice/pull/135
that gives a clear overview of all the edits.

The following note remains valid:

> > I met a problem with the writerfilter module. It was given by the
> > proposed libxml and libxslt pair by the build script [1].
> > The problem was reported here: [2].
> > 
> > Solution: use libxslt 1.34 instead of 1.33.
> > Let's not forget to update the build script [1].
> > 
> > References:
> > 
> >   1: 
> > https://svn.apache.org/viewvc/openoffice/devtools/build-scripts/4.1.10/unxmacos/build_aoo64bit_on_macos.sh?view=markup
> > 
> >   2: https://gitlab.gnome.org/GNOME/libxml2/-/issues/66

Best regards,
-- 
Arrigo

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

Re: [Mini] Setup of development environment

[Arrigo Marchiori]

Dear All,

I just committed the "catalina" branch:
https://github.com/apache/openoffice/tree/catalina

The required environment variables on our Mac Mini are the following:

export LC_CTYPE=en_US.UTF-8
export LANG=en_US.UTF-8
export 
PATH=${HOME}/bin:/opt/local/bin:/opt/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:$PATH
export LIBRARY_PATH=/usr/local/lib
export C_INCLUDE_PATH=/usr/local/include
export CPLUS_INCLUDE_PATH=/usr/local/include
export MACOSX_DEPLOYMENT_TARGET=10.7 
export 
SDKROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk
export CFLAGS="$CFLAGS -mmacosx-version-min=10.7 -isysroot $SDKROOT" 
export CXXFLAGS="$CXXFLAGS -mmacosx-version-min=10.7 -isysroot $SDKROOT"
export LDFLAGS="$LDFLAGS -mmacosx-version-min=10.7 -isysroot $SDKROOT"
export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig

I am testing the branch under Linux, and next Windows if I will find
time, to make sure I did not break anything.

Reviews are very welcome.

Best regards.

On Fri, Jul 16, 2021 at 09:43:50PM +0200, Arrigo Marchiori wrote:

> Hello,
> 
> On Thu, Jul 15, 2021 at 04:52:13PM +0200, Matthias Seidel wrote:
> 
> > Hi Arrigo,
> > 
> > Thank you for the work!
> > 
> > Indeed, we need macOS builds more often to let people test...
> 
> I hope I am close to the end.
> 
> I met a problem with the writerfilter module. It was given by the
> proposed libxml and libxslt pair by the build script [1].
> The problem was reported here: [2].
> 
> Solution: use libxslt 1.34 instead of 1.33.
> Let's not forget to update the build script [1].
> 
> References:
> 
>   1: 
> https://svn.apache.org/viewvc/openoffice/devtools/build-scripts/4.1.10/unxmacos/build_aoo64bit_on_macos.sh?view=markup
> 
>   2: https://gitlab.gnome.org/GNOME/libxml2/-/issues/66
> 
> -- 
> Arrigo
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
> 

-- 
Arrigo

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

Re: [Mini] Setup of development environment

[Arrigo Marchiori]

Hello,

On Thu, Jul 15, 2021 at 04:52:13PM +0200, Matthias Seidel wrote:

> Hi Arrigo,
> 
> Thank you for the work!
> 
> Indeed, we need macOS builds more often to let people test...

I hope I am close to the end.

I met a problem with the writerfilter module. It was given by the
proposed libxml and libxslt pair by the build script [1].
The problem was reported here: [2].

Solution: use libxslt 1.34 instead of 1.33.
Let's not forget to update the build script [1].

References:

  1: 
https://svn.apache.org/viewvc/openoffice/devtools/build-scripts/4.1.10/unxmacos/build_aoo64bit_on_macos.sh?view=markup

  2: https://gitlab.gnome.org/GNOME/libxml2/-/issues/66

-- 
Arrigo

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

Re: [Mini] Setup of development environment

[Matthias Seidel]

Hi Arrigo,

Thank you for the work!

Indeed, we need macOS builds more often to let people test...

Regards,

   Matthias

Am 13.07.21 um 22:24 schrieb Arrigo Marchiori:
> Dear All,
>
> this is to inform you that I am trying to make our shared Mac Mini
> able to build AOO41X.
>
> The sources of information on this topic are:
>
>  - the Building guide on our Wiki [1] and [2],
>
>  - the build script for AOO 4.1.10 [3].
>
> I am a bit struggling behind the differences between the two
> documents, in terms of what should come from macports and what should
> be compiled and installed into /usr/local. If someone (Jim?) could
> help me merging them, I would be grateful.
>
> As AOO 4.1.X should target MacOS 10.7, I installed Xcode 12.0.1 and
> used XcodeLegacy.sh to install the SDK for Xcode 10.11. This seems the
> only way to achieve the goal under macOS Catalina. Some environment
> variables have to be set -- I can share them with anyone interested.
>
> I started with a macports-only approach, but the compilation got stuck
> at the jvmfwk module with a very obscure error about the iconv's
> dynamic libraries' RPATH.  I will send more information if my current
> attempt fails again.
>
> The AOO41X branch did not compile as-is. In particular, all configure
> scripts fail when compiling test programs using exit(3) and sometimes
> even printf(3). The fix consists of including the proper headers,
> stdlib.h and stdio.h respectively. I will fork a branch when I will
> have reached a meaningful state.
>
> I will keep you up to date. I am open to questions, comments,
> complaints etc.
>
> References:
>
>  1: https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO
>
>  2: 
> https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Building_on_MacOsX
>
>  3: 
> https://svn.apache.org/viewvc/openoffice/devtools/build-scripts/4.1.10/unxmacos/build_aoo64bit_on_macos.sh?view=markup



smime.p7s
Description: S/MIME Cryptographic Signature

[Mini] Setup of development environment

[Arrigo Marchiori]

Dear All,

this is to inform you that I am trying to make our shared Mac Mini
able to build AOO41X.

The sources of information on this topic are:

 - the Building guide on our Wiki [1] and [2],

 - the build script for AOO 4.1.10 [3].

I am a bit struggling behind the differences between the two
documents, in terms of what should come from macports and what should
be compiled and installed into /usr/local. If someone (Jim?) could
help me merging them, I would be grateful.

As AOO 4.1.X should target MacOS 10.7, I installed Xcode 12.0.1 and
used XcodeLegacy.sh to install the SDK for Xcode 10.11. This seems the
only way to achieve the goal under macOS Catalina. Some environment
variables have to be set -- I can share them with anyone interested.

I started with a macports-only approach, but the compilation got stuck
at the jvmfwk module with a very obscure error about the iconv's
dynamic libraries' RPATH.  I will send more information if my current
attempt fails again.

The AOO41X branch did not compile as-is. In particular, all configure
scripts fail when compiling test programs using exit(3) and sometimes
even printf(3). The fix consists of including the proper headers,
stdlib.h and stdio.h respectively. I will fork a branch when I will
have reached a meaningful state.

I will keep you up to date. I am open to questions, comments,
complaints etc.

References:

 1: https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO

 2: 
https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Building_on_MacOsX

 3: 
https://svn.apache.org/viewvc/openoffice/devtools/build-scripts/4.1.10/unxmacos/build_aoo64bit_on_macos.sh?view=markup
-- 
Arrigo

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

Re: Contribution to open office development

[Matthias Seidel]

Hi Juan,

Welcome!

Am 19.02.21 um 16:28 schrieb juan francisco Minor:
> I can help with any of them. Wherever help is needed. Some assistance in 
> understanding the code base would be appreciated. 

I would like to have a nasty issue fixed on Windows:

https://bz.apache.org/ooo/show_bug.cgi?id=128310

I would be happy to help you walk through that since i cannot code
myself... ;-)

Regards,

   Matthias

>
> BR,
> Juan M. 
>
> Sent from my iPhone
>
>> On Feb 19, 2021, at 8:09 AM, Bidouille  wrote:
>>
>> Hello Juan,
>> Which application in OpenOffice could you help?
>>
>> - Mail original -
>>> De: "Juan Minor" 
>>> À: dev@openoffice.apache.org
>>> Envoyé: Vendredi 19 Février 2021 00:48:13
>>> Objet: Contribution to open office development
>>>
>>> Howdy,
>>>
>>> My name is Juan Minor. I am a computer engineer with experience in
>>> C/C++. I would like to volunteer my time to help out with this
>>> project
>>> should any help be needed.
>>>
>>> Best Regards,
>>>
>>> Juan M.
>>>
>>>
>>> -
>>> 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: Contribution to open office development

[Peter Kovacs]

On 20.02.21 19:10, Dave Fisher wrote:

Hi -


On Feb 20, 2021, at 9:58 AM, Peter Kovacs  wrote:


On 20.02.21 16:59, Bidouille wrote:

A top-priority will be to work on OOXML Interoperability
Enhance existing import filter (lot of issues)
And create export filter
https://bz.apache.org/ooo/show_bug.cgi?id=88355

We have played around with the Idea instead of updating the code we have to 
implement Apache POI.

POI is Java based -
https://poi.apache.org
https://poi.apache.org/components/index.html
https://poi.apache.org/devel/index.html

The Apache POI PMC also manages Apache XMLBeans which is a core dependency for 
OOXML since the project first undertook support for OOXML about 2007/2008.

I recently saw JCC which is used by Apache Lucene’s pyLucene to wrap Java with 
C++
https://lucene.apache.org/pylucene/jcc/index.html

FYI - I’ve been a POI PMC member since 2008. If there are features lacking that 
we need it is possible to extend.


Thanks the info Dave.

When we discussed, I saw Damjan did some work. But I did not look at it. 
Plus I would look up out some Wiki guides on implementing filters.



All the best

Peter



All The Best,
Dave


If there is interest I can look up some resources to get started.

All the best

Peter


- Mail original -

De: "juan francisco Minor" 
À: dev@openoffice.apache.org
Envoyé: Vendredi 19 Février 2021 16:28:50
Objet: Re: Contribution to open office development

I can help with any of them. Wherever help is needed. Some assistance
in understanding the code base would be appreciated.

BR,
Juan M.

Sent from my iPhone


On Feb 19, 2021, at 8:09 AM, Bidouille  wrote:

Hello Juan,
Which application in OpenOffice could you help?

- Mail original -

De: "Juan Minor" 
À: dev@openoffice.apache.org
Envoyé: Vendredi 19 Février 2021 00:48:13
Objet: Contribution to open office development

Howdy,

My name is Juan Minor. I am a computer engineer with experience in
C/C++. I would like to volunteer my time to help out with this
project
should any help be needed.

Best Regards,

Juan M.


-
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


--
This is the Way! http://www.apache.org/theapacheway/index.html

-
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


--
This is the Way! http://www.apache.org/theapacheway/index.html

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

Re: Contribution to open office development

[Dave Fisher]

Hi -

> On Feb 20, 2021, at 9:58 AM, Peter Kovacs  wrote:
> 
> 
> On 20.02.21 16:59, Bidouille wrote:
>> A top-priority will be to work on OOXML Interoperability
>> Enhance existing import filter (lot of issues)
>> And create export filter
>> https://bz.apache.org/ooo/show_bug.cgi?id=88355
> 
> We have played around with the Idea instead of updating the code we have to 
> implement Apache POI.

POI is Java based - 
https://poi.apache.org
https://poi.apache.org/components/index.html
https://poi.apache.org/devel/index.html

The Apache POI PMC also manages Apache XMLBeans which is a core dependency for 
OOXML since the project first undertook support for OOXML about 2007/2008.

I recently saw JCC which is used by Apache Lucene’s pyLucene to wrap Java with 
C++
https://lucene.apache.org/pylucene/jcc/index.html

FYI - I’ve been a POI PMC member since 2008. If there are features lacking that 
we need it is possible to extend.

All The Best,
Dave

> 
> If there is interest I can look up some resources to get started.
> 
> All the best
> 
> Peter
> 
>> 
>> - Mail original -
>>> De: "juan francisco Minor" 
>>> À: dev@openoffice.apache.org
>>> Envoyé: Vendredi 19 Février 2021 16:28:50
>>> Objet: Re: Contribution to open office development
>>> 
>>> I can help with any of them. Wherever help is needed. Some assistance
>>> in understanding the code base would be appreciated.
>>> 
>>> BR,
>>> Juan M.
>>> 
>>> Sent from my iPhone
>>> 
>>>> On Feb 19, 2021, at 8:09 AM, Bidouille  wrote:
>>>> 
>>>> Hello Juan,
>>>> Which application in OpenOffice could you help?
>>>> 
>>>> - Mail original -
>>>>> De: "Juan Minor" 
>>>>> À: dev@openoffice.apache.org
>>>>> Envoyé: Vendredi 19 Février 2021 00:48:13
>>>>> Objet: Contribution to open office development
>>>>> 
>>>>> Howdy,
>>>>> 
>>>>> My name is Juan Minor. I am a computer engineer with experience in
>>>>> C/C++. I would like to volunteer my time to help out with this
>>>>> project
>>>>> should any help be needed.
>>>>> 
>>>>> Best Regards,
>>>>> 
>>>>> Juan M.
>>>>> 
>>>>> 
>>>>> -
>>>>> 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
>> 
> -- 
> This is the Way! http://www.apache.org/theapacheway/index.html
> 
> -
> 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: Contribution to open office development

[Peter Kovacs]

On 20.02.21 16:59, Bidouille wrote:

A top-priority will be to work on OOXML Interoperability
Enhance existing import filter (lot of issues)
And create export filter
https://bz.apache.org/ooo/show_bug.cgi?id=88355


We have played around with the Idea instead of updating the code we have 
to implement Apache POI.


If there is interest I can look up some resources to get started.

All the best

Peter



- Mail original -

De: "juan francisco Minor" 
À: dev@openoffice.apache.org
Envoyé: Vendredi 19 Février 2021 16:28:50
Objet: Re: Contribution to open office development

I can help with any of them. Wherever help is needed. Some assistance
in understanding the code base would be appreciated.

BR,
Juan M.

Sent from my iPhone


On Feb 19, 2021, at 8:09 AM, Bidouille  wrote:

Hello Juan,
Which application in OpenOffice could you help?

- Mail original -

De: "Juan Minor" 
À: dev@openoffice.apache.org
Envoyé: Vendredi 19 Février 2021 00:48:13
Objet: Contribution to open office development

Howdy,

My name is Juan Minor. I am a computer engineer with experience in
C/C++. I would like to volunteer my time to help out with this
project
should any help be needed.

Best Regards,

Juan M.


-
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


--
This is the Way! http://www.apache.org/theapacheway/index.html

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

Re: Contribution to open office development

[Keith N. McKenna]

On 2/19/2021 12:34 PM, F Campos Costero wrote:
> Hi Juan,
> I am not a developer but I have often seen the suggestion that new
> developers try to build OpenOffice from the source so they can begin to
> contribute. The build process could be politely described by "nontrivial"
> from what I have seen on this list. There is a guide here
> <https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO>. Note
> the platform specific instructions near the bottom. What is your preferred
> platform?
> I hope I am not misrepresenting anything in the above.
> Thanks for volunteering!
> Francis
> 
Francis;

I am not a developer either, but you hit the nail right on the head as
far as advice given by many of the developers. I am cc'ing Juan on this
as he is not subscribed to dev@ and would not have seen your excellent
advice.

The only thing I would add is for you to subscribe to this mailing list
by sending an e-mail to dev-subscr...@openoffice.apache.org You will
receive a reply (also check your spam folder) just click reply to it and
you should get a reply that you are that you are subscribed (again it
could end up in your spam folder). This is the best place to get help or
questions answered by the developers, and also were decisions affecting
the project get made.

Regards
Keith


> On Fri, Feb 19, 2021 at 9:48 AM juan francisco Minor 
> wrote:
> 
>> I can help with any of them. Wherever help is needed. Some assistance in
>> understanding the code base would be appreciated.
>>
>> BR,
>> Juan M.
>>
>> Sent from my iPhone
>>
>>> On Feb 19, 2021, at 8:09 AM, Bidouille  wrote:
>>>
>>> Hello Juan,
>>> Which application in OpenOffice could you help?
>>>
>>> - Mail original -
>>>> De: "Juan Minor" 
>>>> À: dev@openoffice.apache.org
>>>> Envoyé: Vendredi 19 Février 2021 00:48:13
>>>> Objet: Contribution to open office development
>>>>
>>>> Howdy,
>>>>
>>>> My name is Juan Minor. I am a computer engineer with experience in
>>>> C/C++. I would like to volunteer my time to help out with this
>>>> project
>>>> should any help be needed.
>>>>
>>>> Best Regards,
>>>>
>>>> Juan M.
>>>>
>>>>
>>>> -
>>>> 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
>>
>>






signature.asc
Description: OpenPGP digital signature

Re: Contribution to open office development

[F Campos Costero]

Hi Juan,
I am not a developer but I have often seen the suggestion that new
developers try to build OpenOffice from the source so they can begin to
contribute. The build process could be politely described by "nontrivial"
from what I have seen on this list. There is a guide here
<https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO>. Note
the platform specific instructions near the bottom. What is your preferred
platform?
I hope I am not misrepresenting anything in the above.
Thanks for volunteering!
Francis

On Fri, Feb 19, 2021 at 9:48 AM juan francisco Minor 
wrote:

> I can help with any of them. Wherever help is needed. Some assistance in
> understanding the code base would be appreciated.
>
> BR,
> Juan M.
>
> Sent from my iPhone
>
> > On Feb 19, 2021, at 8:09 AM, Bidouille  wrote:
> >
> > Hello Juan,
> > Which application in OpenOffice could you help?
> >
> > - Mail original -
> >> De: "Juan Minor" 
> >> À: dev@openoffice.apache.org
> >> Envoyé: Vendredi 19 Février 2021 00:48:13
> >> Objet: Contribution to open office development
> >>
> >> Howdy,
> >>
> >> My name is Juan Minor. I am a computer engineer with experience in
> >> C/C++. I would like to volunteer my time to help out with this
> >> project
> >> should any help be needed.
> >>
> >> Best Regards,
> >>
> >> Juan M.
> >>
> >>
> >> -
> >> 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: Contribution to open office development

[juan francisco Minor]

I can help with any of them. Wherever help is needed. Some assistance in 
understanding the code base would be appreciated. 

BR,
Juan M. 

Sent from my iPhone

> On Feb 19, 2021, at 8:09 AM, Bidouille  wrote:
> 
> Hello Juan,
> Which application in OpenOffice could you help?
> 
> - Mail original -
>> De: "Juan Minor" 
>> À: dev@openoffice.apache.org
>> Envoyé: Vendredi 19 Février 2021 00:48:13
>> Objet: Contribution to open office development
>> 
>> Howdy,
>> 
>> My name is Juan Minor. I am a computer engineer with experience in
>> C/C++. I would like to volunteer my time to help out with this
>> project
>> should any help be needed.
>> 
>> Best Regards,
>> 
>> Juan M.
>> 
>> 
>> -
>> 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: Contribution to open office development

[Bidouille]

Hello Juan,
Which application in OpenOffice could you help?

- Mail original -
> De: "Juan Minor" 
> À: dev@openoffice.apache.org
> Envoyé: Vendredi 19 Février 2021 00:48:13
> Objet: Contribution to open office development
> 
> Howdy,
> 
> My name is Juan Minor. I am a computer engineer with experience in
> C/C++. I would like to volunteer my time to help out with this
> project
> should any help be needed.
> 
> Best Regards,
> 
> Juan M.
> 
> 
> -
> 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

Contribution to open office development

[Juan Minor]

Howdy,

My name is Juan Minor. I am a computer engineer with experience in 
C/C++. I would like to volunteer my time to help out with this project 
should any help be needed.


Best Regards,

Juan M.


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

Re: SCONS development state

[Hao Wang]

Thank you, Peter. I'll follow through this part.

I'm currently getting stuck with ./boostrap part of the installation process. 
My machine gets hanged at the following point :

downloading to 
/home/ubuntu/aoo-4.1.8/ext_sources/067201ea8b126597670b5eff72e1f66c-mythes-1.2.0.tar.gz.part

The downloading part is never finished in the previous tries on the machine.


From: Dylan Pham 
Sent: Sunday, January 17, 2021 4:08 AM
To: Peter Kovacs 
Cc: dev@openoffice.apache.org ; hao...@live.com 

Subject: Re: SCONS development state

Thank you Peter, this will be very helpful.

Dylan

On Sat, Jan 16, 2021 at 10:33 AM Peter Kovacs 
mailto:pe...@apache.org>> wrote:
Hello Dylan,

Hello Ho Wang,


I am sorry it took me a while. But here Damjan explains all about the
SCONS implementation. Please if still time and interest is there have a
look.

https://lists.apache.org/thread.html/r911b40a582019f641e93253df07341370cb9aeb9d1dc50474e48aa09%40%3Cdev.openoffice.apache.org%3E


I hope this helps

All the Best

Peter

--
This is the Way! http://www.apache.org/theapacheway/index.html

Re: SCONS development state

[Dylan Pham]

Thank you Peter, this will be very helpful.

Dylan

On Sat, Jan 16, 2021 at 10:33 AM Peter Kovacs  wrote:

> Hello Dylan,
>
> Hello Ho Wang,
>
>
> I am sorry it took me a while. But here Damjan explains all about the
> SCONS implementation. Please if still time and interest is there have a
> look.
>
>
> https://lists.apache.org/thread.html/r911b40a582019f641e93253df07341370cb9aeb9d1dc50474e48aa09%40%3Cdev.openoffice.apache.org%3E
>
>
> I hope this helps
>
> All the Best
>
> Peter
>
> --
> This is the Way! http://www.apache.org/theapacheway/index.html
>

SCONS development state

[Peter Kovacs]

Hello Dylan,

Hello Ho Wang,


I am sorry it took me a while. But here Damjan explains all about the 
SCONS implementation. Please if still time and interest is there have a 
look.


https://lists.apache.org/thread.html/r911b40a582019f641e93253df07341370cb9aeb9d1dc50474e48aa09%40%3Cdev.openoffice.apache.org%3E


I hope this helps

All the Best

Peter

--
This is the Way! http://www.apache.org/theapacheway/index.html

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

Re: about build environment development

[Peter Kovacs]

fixed my issues.

Jim, I had an install issue with latest trunk of your epm repo:


make: INSTALL@: Befehl nicht gefunden (command not found)
Makefile:153: die Regel für Ziel „install“ scheiterte (install failed)
make: *** [install] Fehler 127


I think some sort of typo maybe? 4.4.2 works good.


All the best

Peter

Am 23.04.20 um 15:48 schrieb Jim Jagielski:

IMO, dmake is simply a build-and-compile dependency. Considering that we pull 
in lots of other external dependencies, keeping or dropping dmake will likely 
not make any real difference in the people we can attract to help develop, test 
and build AOO. At the very least, we know what dmake is good at, and what it is 
NOT good at; so I support porting as much as possible to gmake, and just using 
dmake as the last step.

And, FWIW, I am keeping dmake up-to-date and even FreeBSD are using my repo 
now: https://github.com/jimjag/dmake


On Apr 17, 2020, at 8:53 AM, Peter Kovacs  wrote:

The goal is to move away from dmake. I do struggle with your point of view, 
saying moving away from dmake is unimportant, and should be stopped.

I disagree with this position.


Am 16.04.20 um 23:04 schrieb Patricia Shanahan:


On 4/15/2020 10:08 AM, Damjan Jovanovic wrote:

On Wed, Apr 15, 2020 at 3:15 PM Jim Jagielski  wrote:




On Apr 15, 2020, at 3:01 AM, Damjan Jovanovic  wrote:


We are also thin on new contributors, and I recall you saying they're
largely scared off by the current build system.


Two points:

1. I doubt that by the time we finish porting to a whole new build
system, we will even have anyone *wanting* to contribute. With each delay
and push-out on releases, and more time spent working on the build system
instead of AOO itself, we become less and less relevant. Is that really a
priority we should be focusing on? Are the number of people knowledgeable
around scons really greater than what we have now? But I could be wrong,
which leads me to #2...



What would you recommend we focus on instead then?

I would recommend going for robustness, rather than new features. I know of 
some areas for potential improvement:

Array bounds checking, especially during input processing.

Memory allocation checking.

Debug profile corruption.


Ideally, new contributors wouldn't need to be knowledgeable about scons.
The build should be easier to perform, hopefully just "./configure"
followed by "scons" (and scons even implements features that can subsume
./configure too). Already, scons doesn't need the "source winenv.set.sh"
and "cd instsetoo_native" steps to build its modules.



2. "The conversion from gbuild to scons would largely be automated, fast
and correct." If that is the case, let's test that theory right now.


This has been possible for some time. In the scons-build branch, you can do
the following:

$ cd gotoSCons
$ mvn package
$ java -cp target/gotoSCons-0.1-SNAPSHOT.jar
org.apache.openoffice.gotoSCons.GBuildConverter parsingAnalysis ../main
(per-module output)
Could parse: [MathMLDTD, UnoControls, animations, cosv, cppcanvas,
drawinglayer, eventattacher, fileaccess, i18nutil, idl, io, rdbmaker,
registry, remotebridges, sane, store, svgio, twain, ucbhelper, unixODBC,
xmlreader, xmlscript]
22 out of 105 gbuild modules are parseable

That means 22 modules can already be converted, completely and correctly.
As we add more features to the converter (AllLangResTarget, UnoApi, Junit,
GoogleTest, etc.), that 22 will increase.

The per-module gbuild files are easy to parse. Parsing the syntax takes
only 3 methods and < 100 lines of Java. The non-deterministic ones with
"ifeq ($(GUIBASE),aqua)" require some manual work, but even there, a lot
can be automated. There is some more work involved in semantic conversion:
understanding and converting specific gbuild commands, converting paths to
scons format, etc. but even so, we're on just 1913 lines of code in total
for the converter.

The hard part is to convert gbuild functions in main/solenv/gbuild into
scons, for example, the worst case scenario is AllLangResTarget, for which
this monstrous dependency tree needs to be implemented, with 4 layers of
intermediate targets and complex actions with side effects and header
dependencies (not shown):

#  AllLangResTarget(name)
#  (meta-target; delivers an empty timestamp file)
#^ ^
#   /   \
#  / \
# /   \
#  ResTarget(nameen-US,name,en-US)
ResTarget(nameen-GB,name,en-GB)
#  $(WORKDIR)/ResTarget/$(resName).res
$(WORKDIR)/ResTarget/$(resName).res
#  $(WORKDIR)/ResTarget/nameen-US.res
   $(WORKDIR)/ResTarget/nameen-GB.res
#^ ^^
#| rsc ||
#| ||
#  SrsTarget   SrsTarget
SrsTarget
#  $(WORKDIR)/SrsTarget/$(srsName).srs
#  

Re: about build environment development

[Kay Schenk]

On 4/23/20 10:44 AM, Peter Kovacs wrote:

Hi Jim,


dmake is not simple. I do know nothing Jim Jagielski...

Today the build system enjoys me with


checking whether the found dmake is the right dmake... configure: 
WARNING: no


or

configure: error: no URL for dmake source code specified, either. Use 
--with-dmake-url to supply an URL; run configure with the --help 
option for a list of possible URLs.
./configure.sh: Zeile 22: 
--with-dmake-url=https://sourceforge.net/projects/oooextras.mirror/files/dmake-4.12.tar.bz2: 
Datei oder Verzeichnis nicht gefunden


but:

wget 
https://sourceforge.net/projects/oooextras.mirror/files/dmake-4.12.tar.bz2
dmake-4.12.tar.bz2 
100%[==>] 
490,31K  92,2KB/s    in 5,3s



I am frustrated and will continue, when I had a break. Maybe then I 
figure out what stupidity I do not see.



All the Best

Peter



Maybe some useful information on dmake?

https://docs.oracle.com/cd/E19422-01/819-3697/dmake.html

Regards,

Kay



Am 23.04.20 um 15:48 schrieb Jim Jagielski:
IMO, dmake is simply a build-and-compile dependency. Considering that 
we pull in lots of other external dependencies, keeping or dropping 
dmake will likely not make any real difference in the people we can 
attract to help develop, test and build AOO. At the very least, we 
know what dmake is good at, and what it is NOT good at; so I support 
porting as much as possible to gmake, and just using dmake as the 
last step.


And, FWIW, I am keeping dmake up-to-date and even FreeBSD are using 
my repo now: https://github.com/jimjag/dmake



On Apr 17, 2020, at 8:53 AM, Peter Kovacs  wrote:

The goal is to move away from dmake. I do struggle with your point 
of view, saying moving away from dmake is unimportant, and should be 
stopped.


I disagree with this position.


Am 16.04.20 um 23:04 schrieb Patricia Shanahan:


On 4/15/2020 10:08 AM, Damjan Jovanovic wrote:
On Wed, Apr 15, 2020 at 3:15 PM Jim Jagielski  
wrote:




On Apr 15, 2020, at 3:01 AM, Damjan Jovanovic 
 wrote:



We are also thin on new contributors, and I recall you saying 
they're

largely scared off by the current build system.


Two points:

    1. I doubt that by the time we finish porting to a whole new 
build
system, we will even have anyone *wanting* to contribute. With 
each delay
and push-out on releases, and more time spent working on the 
build system
instead of AOO itself, we become less and less relevant. Is that 
really a
priority we should be focusing on? Are the number of people 
knowledgeable
around scons really greater than what we have now? But I could be 
wrong,

which leads me to #2...



What would you recommend we focus on instead then?
I would recommend going for robustness, rather than new features. I 
know of some areas for potential improvement:


Array bounds checking, especially during input processing.

Memory allocation checking.

Debug profile corruption.

Ideally, new contributors wouldn't need to be knowledgeable about 
scons.

The build should be easier to perform, hopefully just "./configure"
followed by "scons" (and scons even implements features that can 
subsume
./configure too). Already, scons doesn't need the "source 
winenv.set.sh"

and "cd instsetoo_native" steps to build its modules.


    2. "The conversion from gbuild to scons would largely be 
automated, fast

and correct." If that is the case, let's test that theory right now.

This has been possible for some time. In the scons-build branch, 
you can do

the following:

$ cd gotoSCons
$ mvn package
$ java -cp target/gotoSCons-0.1-SNAPSHOT.jar
org.apache.openoffice.gotoSCons.GBuildConverter parsingAnalysis 
../main

(per-module output)
Could parse: [MathMLDTD, UnoControls, animations, cosv, cppcanvas,
drawinglayer, eventattacher, fileaccess, i18nutil, idl, io, rdbmaker,
registry, remotebridges, sane, store, svgio, twain, ucbhelper, 
unixODBC,

xmlreader, xmlscript]
22 out of 105 gbuild modules are parseable

That means 22 modules can already be converted, completely and 
correctly.
As we add more features to the converter (AllLangResTarget, 
UnoApi, Junit,

GoogleTest, etc.), that 22 will increase.

The per-module gbuild files are easy to parse. Parsing the syntax 
takes
only 3 methods and < 100 lines of Java. The non-deterministic ones 
with
"ifeq ($(GUIBASE),aqua)" require some manual work, but even there, 
a lot
can be automated. There is some more work involved in semantic 
conversion:
understanding and converting specific gbuild commands, converting 
paths to
scons format, etc. but even so, we're on just 1913 lines of code 
in total

for the converter.

The hard part is to convert gbuild functions in main/solenv/gbuild 
into
scons, for example, the worst case scenario is AllLangResTarget, 
for which
this monstrous dependency tree needs to be implemented, with 4 
layers of

intermediate 

Re: about build environment development

[Peter Kovacs]

Hi Jim,


dmake is not simple. I do know nothing Jim Jagielski...

Today the build system enjoys me with


checking whether the found dmake is the right dmake... configure: 
WARNING: no


or

configure: error: no URL for dmake source code specified, either. Use 
--with-dmake-url to supply an URL; run configure with the --help option 
for a list of possible URLs.
./configure.sh: Zeile 22: 
--with-dmake-url=https://sourceforge.net/projects/oooextras.mirror/files/dmake-4.12.tar.bz2: 
Datei oder Verzeichnis nicht gefunden


but:

wget 
https://sourceforge.net/projects/oooextras.mirror/files/dmake-4.12.tar.bz2
dmake-4.12.tar.bz2 
100%[==>] 
490,31K  92,2KB/s    in 5,3s



I am frustrated and will continue, when I had a break. Maybe then I 
figure out what stupidity I do not see.



All the Best

Peter

Am 23.04.20 um 15:48 schrieb Jim Jagielski:

IMO, dmake is simply a build-and-compile dependency. Considering that we pull 
in lots of other external dependencies, keeping or dropping dmake will likely 
not make any real difference in the people we can attract to help develop, test 
and build AOO. At the very least, we know what dmake is good at, and what it is 
NOT good at; so I support porting as much as possible to gmake, and just using 
dmake as the last step.

And, FWIW, I am keeping dmake up-to-date and even FreeBSD are using my repo 
now: https://github.com/jimjag/dmake


On Apr 17, 2020, at 8:53 AM, Peter Kovacs  wrote:

The goal is to move away from dmake. I do struggle with your point of view, 
saying moving away from dmake is unimportant, and should be stopped.

I disagree with this position.


Am 16.04.20 um 23:04 schrieb Patricia Shanahan:


On 4/15/2020 10:08 AM, Damjan Jovanovic wrote:

On Wed, Apr 15, 2020 at 3:15 PM Jim Jagielski  wrote:




On Apr 15, 2020, at 3:01 AM, Damjan Jovanovic  wrote:


We are also thin on new contributors, and I recall you saying they're
largely scared off by the current build system.


Two points:

1. I doubt that by the time we finish porting to a whole new build
system, we will even have anyone *wanting* to contribute. With each delay
and push-out on releases, and more time spent working on the build system
instead of AOO itself, we become less and less relevant. Is that really a
priority we should be focusing on? Are the number of people knowledgeable
around scons really greater than what we have now? But I could be wrong,
which leads me to #2...



What would you recommend we focus on instead then?

I would recommend going for robustness, rather than new features. I know of 
some areas for potential improvement:

Array bounds checking, especially during input processing.

Memory allocation checking.

Debug profile corruption.


Ideally, new contributors wouldn't need to be knowledgeable about scons.
The build should be easier to perform, hopefully just "./configure"
followed by "scons" (and scons even implements features that can subsume
./configure too). Already, scons doesn't need the "source winenv.set.sh"
and "cd instsetoo_native" steps to build its modules.



2. "The conversion from gbuild to scons would largely be automated, fast
and correct." If that is the case, let's test that theory right now.


This has been possible for some time. In the scons-build branch, you can do
the following:

$ cd gotoSCons
$ mvn package
$ java -cp target/gotoSCons-0.1-SNAPSHOT.jar
org.apache.openoffice.gotoSCons.GBuildConverter parsingAnalysis ../main
(per-module output)
Could parse: [MathMLDTD, UnoControls, animations, cosv, cppcanvas,
drawinglayer, eventattacher, fileaccess, i18nutil, idl, io, rdbmaker,
registry, remotebridges, sane, store, svgio, twain, ucbhelper, unixODBC,
xmlreader, xmlscript]
22 out of 105 gbuild modules are parseable

That means 22 modules can already be converted, completely and correctly.
As we add more features to the converter (AllLangResTarget, UnoApi, Junit,
GoogleTest, etc.), that 22 will increase.

The per-module gbuild files are easy to parse. Parsing the syntax takes
only 3 methods and < 100 lines of Java. The non-deterministic ones with
"ifeq ($(GUIBASE),aqua)" require some manual work, but even there, a lot
can be automated. There is some more work involved in semantic conversion:
understanding and converting specific gbuild commands, converting paths to
scons format, etc. but even so, we're on just 1913 lines of code in total
for the converter.

The hard part is to convert gbuild functions in main/solenv/gbuild into
scons, for example, the worst case scenario is AllLangResTarget, for which
this monstrous dependency tree needs to be implemented, with 4 layers of
intermediate targets and complex actions with side effects and header
dependencies (not shown):

#  AllLangResTarget(name)
#  (meta-target; delivers an empty timestamp 

Re: about build environment development

[Jim Jagielski]

IMO, dmake is simply a build-and-compile dependency. Considering that we pull 
in lots of other external dependencies, keeping or dropping dmake will likely 
not make any real difference in the people we can attract to help develop, test 
and build AOO. At the very least, we know what dmake is good at, and what it is 
NOT good at; so I support porting as much as possible to gmake, and just using 
dmake as the last step.

And, FWIW, I am keeping dmake up-to-date and even FreeBSD are using my repo 
now: https://github.com/jimjag/dmake

> On Apr 17, 2020, at 8:53 AM, Peter Kovacs  wrote:
> 
> The goal is to move away from dmake. I do struggle with your point of view, 
> saying moving away from dmake is unimportant, and should be stopped.
> 
> I disagree with this position.
> 
> 
> Am 16.04.20 um 23:04 schrieb Patricia Shanahan:
>> 
>> 
>> On 4/15/2020 10:08 AM, Damjan Jovanovic wrote:
>>> On Wed, Apr 15, 2020 at 3:15 PM Jim Jagielski  wrote:
>>> 
 
 
> On Apr 15, 2020, at 3:01 AM, Damjan Jovanovic  wrote:
> 
> 
> We are also thin on new contributors, and I recall you saying they're
> largely scared off by the current build system.
> 
 
 Two points:
 
1. I doubt that by the time we finish porting to a whole new build
 system, we will even have anyone *wanting* to contribute. With each delay
 and push-out on releases, and more time spent working on the build system
 instead of AOO itself, we become less and less relevant. Is that really a
 priority we should be focusing on? Are the number of people knowledgeable
 around scons really greater than what we have now? But I could be wrong,
 which leads me to #2...
 
 
>>> What would you recommend we focus on instead then?
>> 
>> I would recommend going for robustness, rather than new features. I know of 
>> some areas for potential improvement:
>> 
>> Array bounds checking, especially during input processing.
>> 
>> Memory allocation checking.
>> 
>> Debug profile corruption.
>> 
>>> 
>>> Ideally, new contributors wouldn't need to be knowledgeable about scons.
>>> The build should be easier to perform, hopefully just "./configure"
>>> followed by "scons" (and scons even implements features that can subsume
>>> ./configure too). Already, scons doesn't need the "source winenv.set.sh"
>>> and "cd instsetoo_native" steps to build its modules.
>>> 
>>> 
2. "The conversion from gbuild to scons would largely be automated, fast
 and correct." If that is the case, let's test that theory right now.
 
>>> 
>>> This has been possible for some time. In the scons-build branch, you can do
>>> the following:
>>> 
>>> $ cd gotoSCons
>>> $ mvn package
>>> $ java -cp target/gotoSCons-0.1-SNAPSHOT.jar
>>> org.apache.openoffice.gotoSCons.GBuildConverter parsingAnalysis ../main
>>> (per-module output)
>>> Could parse: [MathMLDTD, UnoControls, animations, cosv, cppcanvas,
>>> drawinglayer, eventattacher, fileaccess, i18nutil, idl, io, rdbmaker,
>>> registry, remotebridges, sane, store, svgio, twain, ucbhelper, unixODBC,
>>> xmlreader, xmlscript]
>>> 22 out of 105 gbuild modules are parseable
>>> 
>>> That means 22 modules can already be converted, completely and correctly.
>>> As we add more features to the converter (AllLangResTarget, UnoApi, Junit,
>>> GoogleTest, etc.), that 22 will increase.
>>> 
>>> The per-module gbuild files are easy to parse. Parsing the syntax takes
>>> only 3 methods and < 100 lines of Java. The non-deterministic ones with
>>> "ifeq ($(GUIBASE),aqua)" require some manual work, but even there, a lot
>>> can be automated. There is some more work involved in semantic conversion:
>>> understanding and converting specific gbuild commands, converting paths to
>>> scons format, etc. but even so, we're on just 1913 lines of code in total
>>> for the converter.
>>> 
>>> The hard part is to convert gbuild functions in main/solenv/gbuild into
>>> scons, for example, the worst case scenario is AllLangResTarget, for which
>>> this monstrous dependency tree needs to be implemented, with 4 layers of
>>> intermediate targets and complex actions with side effects and header
>>> dependencies (not shown):
>>> 
>>> #  AllLangResTarget(name)
>>> #  (meta-target; delivers an empty timestamp file)
>>> #^ ^
>>> #   /   \
>>> #  / \
>>> # /   \
>>> #  ResTarget(nameen-US,name,en-US)
>>> ResTarget(nameen-GB,name,en-GB)
>>> #  $(WORKDIR)/ResTarget/$(resName).res
>>> $(WORKDIR)/ResTarget/$(resName).res
>>> #  $(WORKDIR)/ResTarget/nameen-US.res
>>>   $(WORKDIR)/ResTarget/nameen-GB.res
>>> #^ ^^
>>> #| rsc ||
>>> #| ||
>>> #  SrsTarget   SrsTarget
>>> 

Re: about build environment development

[Peter Kovacs]

The goal is to move away from dmake. I do struggle with your point of 
view, saying moving away from dmake is unimportant, and should be stopped.


I disagree with this position.


Am 16.04.20 um 23:04 schrieb Patricia Shanahan:



On 4/15/2020 10:08 AM, Damjan Jovanovic wrote:

On Wed, Apr 15, 2020 at 3:15 PM Jim Jagielski  wrote:




On Apr 15, 2020, at 3:01 AM, Damjan Jovanovic  
wrote:



We are also thin on new contributors, and I recall you saying they're
largely scared off by the current build system.



Two points:

   1. I doubt that by the time we finish porting to a whole new build
system, we will even have anyone *wanting* to contribute. With each 
delay
and push-out on releases, and more time spent working on the build 
system
instead of AOO itself, we become less and less relevant. Is that 
really a
priority we should be focusing on? Are the number of people 
knowledgeable
around scons really greater than what we have now? But I could be 
wrong,

which leads me to #2...



What would you recommend we focus on instead then?


I would recommend going for robustness, rather than new features. I 
know of some areas for potential improvement:


Array bounds checking, especially during input processing.

Memory allocation checking.

Debug profile corruption.



Ideally, new contributors wouldn't need to be knowledgeable about scons.
The build should be easier to perform, hopefully just "./configure"
followed by "scons" (and scons even implements features that can subsume
./configure too). Already, scons doesn't need the "source winenv.set.sh"
and "cd instsetoo_native" steps to build its modules.


   2. "The conversion from gbuild to scons would largely be 
automated, fast

and correct." If that is the case, let's test that theory right now.



This has been possible for some time. In the scons-build branch, you 
can do

the following:

$ cd gotoSCons
$ mvn package
$ java -cp target/gotoSCons-0.1-SNAPSHOT.jar
org.apache.openoffice.gotoSCons.GBuildConverter parsingAnalysis ../main
(per-module output)
Could parse: [MathMLDTD, UnoControls, animations, cosv, cppcanvas,
drawinglayer, eventattacher, fileaccess, i18nutil, idl, io, rdbmaker,
registry, remotebridges, sane, store, svgio, twain, ucbhelper, unixODBC,
xmlreader, xmlscript]
22 out of 105 gbuild modules are parseable

That means 22 modules can already be converted, completely and 
correctly.
As we add more features to the converter (AllLangResTarget, UnoApi, 
Junit,

GoogleTest, etc.), that 22 will increase.

The per-module gbuild files are easy to parse. Parsing the syntax takes
only 3 methods and < 100 lines of Java. The non-deterministic ones with
"ifeq ($(GUIBASE),aqua)" require some manual work, but even there, a lot
can be automated. There is some more work involved in semantic 
conversion:
understanding and converting specific gbuild commands, converting 
paths to
scons format, etc. but even so, we're on just 1913 lines of code in 
total

for the converter.

The hard part is to convert gbuild functions in main/solenv/gbuild into
scons, for example, the worst case scenario is AllLangResTarget, for 
which

this monstrous dependency tree needs to be implemented, with 4 layers of
intermediate targets and complex actions with side effects and header
dependencies (not shown):

#  AllLangResTarget(name)
#  (meta-target; delivers an empty timestamp file)
#    ^ ^
#   /   \
#  / \
# /   \
#  ResTarget(nameen-US,name,en-US)
ResTarget(nameen-GB,name,en-GB)
#  $(WORKDIR)/ResTarget/$(resName).res
$(WORKDIR)/ResTarget/$(resName).res
#  $(WORKDIR)/ResTarget/nameen-US.res
  $(WORKDIR)/ResTarget/nameen-GB.res
#    ^ ^    ^
#    | rsc |    |
#    | |    |
#  SrsTarget   SrsTarget
SrsTarget
#  $(WORKDIR)/SrsTarget/$(srsName).srs
#  $(WORKDIR)/SrsTarget/uui/res.srs
#    ^
#    | concatenate
#    +--+
#    |   \
#    |    \
#  SrcPartTarget   SrcPartTarget
#  $(WORKDIR)/SrsPartTarget/$(srsPartName)
# $(WORKDIR)/SrsPartTarget/uui/source/ids.src
#    ^   ^
#    | rsc   | rsc
#    |   |
# (when not translating) |   | (when translating)
#    |   |
#    |    SrcPartMergeTarget
#    | $(WORKDIR)/SrsPartMergeTarget/$(1)
#    |
  $(WORKDIR)/SrsPartMergeTarget/uui/source/ids.src
#    | ^
#    |    /
#    |   / transex3
#    |  / (when 

Re: about build environment development

[Patricia Shanahan]

On 4/15/2020 10:08 AM, Damjan Jovanovic wrote:

On Wed, Apr 15, 2020 at 3:15 PM Jim Jagielski  wrote:





On Apr 15, 2020, at 3:01 AM, Damjan Jovanovic  wrote:


We are also thin on new contributors, and I recall you saying they're
largely scared off by the current build system.



Two points:

   1. I doubt that by the time we finish porting to a whole new build
system, we will even have anyone *wanting* to contribute. With each delay
and push-out on releases, and more time spent working on the build system
instead of AOO itself, we become less and less relevant. Is that really a
priority we should be focusing on? Are the number of people knowledgeable
around scons really greater than what we have now? But I could be wrong,
which leads me to #2...



What would you recommend we focus on instead then?


I would recommend going for robustness, rather than new features. I know 
of some areas for potential improvement:


Array bounds checking, especially during input processing.

Memory allocation checking.

Debug profile corruption.



Ideally, new contributors wouldn't need to be knowledgeable about scons.
The build should be easier to perform, hopefully just "./configure"
followed by "scons" (and scons even implements features that can subsume
./configure too). Already, scons doesn't need the "source winenv.set.sh"
and "cd instsetoo_native" steps to build its modules.



   2. "The conversion from gbuild to scons would largely be automated, fast
and correct." If that is the case, let's test that theory right now.



This has been possible for some time. In the scons-build branch, you can do
the following:

$ cd gotoSCons
$ mvn package
$ java -cp target/gotoSCons-0.1-SNAPSHOT.jar
org.apache.openoffice.gotoSCons.GBuildConverter parsingAnalysis ../main
(per-module output)
Could parse: [MathMLDTD, UnoControls, animations, cosv, cppcanvas,
drawinglayer, eventattacher, fileaccess, i18nutil, idl, io, rdbmaker,
registry, remotebridges, sane, store, svgio, twain, ucbhelper, unixODBC,
xmlreader, xmlscript]
22 out of 105 gbuild modules are parseable

That means 22 modules can already be converted, completely and correctly.
As we add more features to the converter (AllLangResTarget, UnoApi, Junit,
GoogleTest, etc.), that 22 will increase.

The per-module gbuild files are easy to parse. Parsing the syntax takes
only 3 methods and < 100 lines of Java. The non-deterministic ones with
"ifeq ($(GUIBASE),aqua)" require some manual work, but even there, a lot
can be automated. There is some more work involved in semantic conversion:
understanding and converting specific gbuild commands, converting paths to
scons format, etc. but even so, we're on just 1913 lines of code in total
for the converter.

The hard part is to convert gbuild functions in main/solenv/gbuild into
scons, for example, the worst case scenario is AllLangResTarget, for which
this monstrous dependency tree needs to be implemented, with 4 layers of
intermediate targets and complex actions with side effects and header
dependencies (not shown):

#  AllLangResTarget(name)
#  (meta-target; delivers an empty timestamp file)
#^ ^
#   /   \
#  / \
# /   \
#  ResTarget(nameen-US,name,en-US)
ResTarget(nameen-GB,name,en-GB)
#  $(WORKDIR)/ResTarget/$(resName).res
$(WORKDIR)/ResTarget/$(resName).res
#  $(WORKDIR)/ResTarget/nameen-US.res
  $(WORKDIR)/ResTarget/nameen-GB.res
#^   ^^
#| rsc   ||
#|   ||
#  SrsTarget   SrsTarget
SrsTarget
#  $(WORKDIR)/SrsTarget/$(srsName).srs
#  $(WORKDIR)/SrsTarget/uui/res.srs
#^
#| concatenate
#+--+
#|   \
#|\
#  SrcPartTarget   SrcPartTarget
#  $(WORKDIR)/SrsPartTarget/$(srsPartName)
#  $(WORKDIR)/SrsPartTarget/uui/source/ids.src
#^   ^
#| rsc   | rsc
#|   |
# (when not translating) |   | (when translating)
#|   |
#|SrcPartMergeTarget
#|$(WORKDIR)/SrsPartMergeTarget/$(1)
#|
  $(WORKDIR)/SrsPartMergeTarget/uui/source/ids.src
#| ^
#|/
#|   / transex3
#|  / (when translating)
#  $(srsPartName)  /
#  uuid/source/ids.src
#

Re: about build environment development

[Kay Schenk]

On 4/14/20 9:46 PM, Peter Kovacs wrote:
If one wants to tap in our build system he needs to understand Perl, 
shell, make, ant, XML, configure, ...


This is just way to complicated, especially if you want to bring in an 
IDE to ease code development.



Damjan is not very happy with the features gmake offers. I am not sure 
where exactly the Issue is.


He is opting for SCONs, with the option to extend the build system 
with python. And IMHO on Damjan


Side he is quite serious about it.


Everyone else has not expressed any opinion on this development, so I 
am not sure everyone is aware. The last discussion on this topic,


consent has been strongly to make gmake work.

Another objection is that we got some heavy negative experience report 
from the serf community about SCONS.


Which are switching from, SCONS to cmake.


HA! I guess I missed this. I was wondering if cmake might be acceptable 
option, and I guess it is! :)


On Carl's original question. There WERE dependency specs in dmake. Since 
I'm not a gbuild guru, I couldn't figure how this was handled in gbuild.






So in the end we do not have Consent where we want to go. And 
currently it is heavily influenced by Damjan. And this is imho very thin.


I am still like the Idea most to go in the direction of ant / maven, 
despite its flaws. But I am not negative on SCONS either. My main 
point is we need something that


offers a better architecture and is easier to handled and maintained.


Also what we could try is making use of something like portage. 
Portage is pretty easy to use repostory manager used by gentoo, whioch 
also had a community prior to homebrew on mac. It is not very 
difficult to setup.  But it is build to make different build system 
work together. So we could have a build repository, that builds our 
dependencies. We reconstruct our monolith in smaller build libraries, 
like UNOcore, OOFrame, UNOGUI, OOapp, OOpython, StarBasic, OOwizards, 
extentionXYZ (Just saying something), and pick the best build system 
(cmake, gmake, ant, maven, SCONS) for each library. Also we could 
think on incubating Starbasic or UNO, as own Project if they become 
more interesting. Since Portage is made for source build, but can also 
handle binaries, maybe we could add some features that will make it 
easy to export towards specific distributions, making it easy for 
distributors to export to their system. BTW, portage is build on 
python, so it should work on all systems we target. Sorry if this Idea 
is to crazy for you. It is only an idea.



Maybe it is a good time now to bring this topic up in everyones mind.


All the Best

Peter


Am 15.04.20 um 01:14 schrieb Carl Marcum:



On 4/14/20 5:53 PM, Kay Schenk wrote:


On 4/14/20 1:46 PM, Carl Marcum wrote:



On 4/14/20 3:57 PM, Peter Kovacs wrote:
You could try to build only the module, by going into the folder 
and execute make directly.


Hi Peter,

Yes but that doesn't solve my problem with targets not running in 
order or how I can enforce it if possible.

I don't want to break the build if my change ever makes it to trunk.

Eventually if I can get Ant to build the Jar exactly as gbuild does 
I can use that one and my problem goes away.
But until then I was wanting to use the current one that gbuild 
builds.


Thanks,
Carl


Hi Carl --

From your first post in this thread...

When I build with "build --all" everything works as expected.
When I build with "build --all -P2 -- -P2" the file copy fails 
because the juh.jar file isn't completed.


I recall having issues with the second part -- -P2.

You might try omitting that, and just use "build --all -P2" or maybe 
"build --all -P4"


ref...

https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO#Building_2 



The build will take a longer but you shouldn't run into the 
"non-completion" issue you're having.


Hope this helps,

Kay


Hi Kay,

Thanks for pointing out what the second parameter meant :)

It would still be good to know if it's possible to declare 
dependencies between targets in gbuild somehow like you can with Ant 
builds.


I'm guessing any final solution that gets into trunk has to build 
with multiple threads per module.


My best option is probably to do the jar build along with the other 
tasks in Ant so I can control when it happens.


Were already using Ant to build java jars in ridljar, jurt, 
officebean, and probably other modules.


I didn't mention it but I'm working on creating the necessary 
javadoc, source, and library jars for distribution through Apache 
Nexus [1].
But during the build process to avoid the need for a separate Vote 
next time around.


[1] https://wiki.openoffice.org/wiki/Uno/Java/MavenBundles

Thanks again,
Carl



-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additiona

Re: about build environment development (was: declaring gbuild target dependencies)

[Damjan Jovanovic]

On Wed, Apr 15, 2020 at 3:15 PM Jim Jagielski  wrote:

>
>
> > On Apr 15, 2020, at 3:01 AM, Damjan Jovanovic  wrote:
> >
> >
> > We are also thin on new contributors, and I recall you saying they're
> > largely scared off by the current build system.
> >
>
> Two points:
>
>   1. I doubt that by the time we finish porting to a whole new build
> system, we will even have anyone *wanting* to contribute. With each delay
> and push-out on releases, and more time spent working on the build system
> instead of AOO itself, we become less and less relevant. Is that really a
> priority we should be focusing on? Are the number of people knowledgeable
> around scons really greater than what we have now? But I could be wrong,
> which leads me to #2...
>
>
What would you recommend we focus on instead then?

Ideally, new contributors wouldn't need to be knowledgeable about scons.
The build should be easier to perform, hopefully just "./configure"
followed by "scons" (and scons even implements features that can subsume
./configure too). Already, scons doesn't need the "source winenv.set.sh"
and "cd instsetoo_native" steps to build its modules.


>   2. "The conversion from gbuild to scons would largely be automated, fast
> and correct." If that is the case, let's test that theory right now.
>

This has been possible for some time. In the scons-build branch, you can do
the following:

$ cd gotoSCons
$ mvn package
$ java -cp target/gotoSCons-0.1-SNAPSHOT.jar
org.apache.openoffice.gotoSCons.GBuildConverter parsingAnalysis ../main
(per-module output)
Could parse: [MathMLDTD, UnoControls, animations, cosv, cppcanvas,
drawinglayer, eventattacher, fileaccess, i18nutil, idl, io, rdbmaker,
registry, remotebridges, sane, store, svgio, twain, ucbhelper, unixODBC,
xmlreader, xmlscript]
22 out of 105 gbuild modules are parseable

That means 22 modules can already be converted, completely and correctly.
As we add more features to the converter (AllLangResTarget, UnoApi, Junit,
GoogleTest, etc.), that 22 will increase.

The per-module gbuild files are easy to parse. Parsing the syntax takes
only 3 methods and < 100 lines of Java. The non-deterministic ones with
"ifeq ($(GUIBASE),aqua)" require some manual work, but even there, a lot
can be automated. There is some more work involved in semantic conversion:
understanding and converting specific gbuild commands, converting paths to
scons format, etc. but even so, we're on just 1913 lines of code in total
for the converter.

The hard part is to convert gbuild functions in main/solenv/gbuild into
scons, for example, the worst case scenario is AllLangResTarget, for which
this monstrous dependency tree needs to be implemented, with 4 layers of
intermediate targets and complex actions with side effects and header
dependencies (not shown):

#  AllLangResTarget(name)
#  (meta-target; delivers an empty timestamp file)
#^ ^
#   /   \
#  / \
# /   \
#  ResTarget(nameen-US,name,en-US)
ResTarget(nameen-GB,name,en-GB)
#  $(WORKDIR)/ResTarget/$(resName).res
$(WORKDIR)/ResTarget/$(resName).res
#  $(WORKDIR)/ResTarget/nameen-US.res
 $(WORKDIR)/ResTarget/nameen-GB.res
#^   ^^
#| rsc   ||
#|   ||
#  SrsTarget   SrsTarget
SrsTarget
#  $(WORKDIR)/SrsTarget/$(srsName).srs
#  $(WORKDIR)/SrsTarget/uui/res.srs
#^
#| concatenate
#+--+
#|   \
#|\
#  SrcPartTarget   SrcPartTarget
#  $(WORKDIR)/SrsPartTarget/$(srsPartName)
#  $(WORKDIR)/SrsPartTarget/uui/source/ids.src
#^   ^
#| rsc   | rsc
#|   |
# (when not translating) |   | (when translating)
#|   |
#|SrcPartMergeTarget
#|$(WORKDIR)/SrsPartMergeTarget/$(1)
#|
 $(WORKDIR)/SrsPartMergeTarget/uui/source/ids.src
#| ^
#|/
#|   / transex3
#|  / (when translating)
#  $(srsPartName)  /
#  uuid/source/ids.src
#

Damjan

Re: about build environment development (was: declaring gbuild target dependencies)

[Jim Jagielski]

> On Apr 15, 2020, at 3:01 AM, Damjan Jovanovic  wrote:
> 
> 
> We are also thin on new contributors, and I recall you saying they're
> largely scared off by the current build system.
> 

Two points:

  1. I doubt that by the time we finish porting to a whole new build system, we 
will even have anyone *wanting* to contribute. With each delay and push-out on 
releases, and more time spent working on the build system instead of AOO 
itself, we become less and less relevant. Is that really a priority we should 
be focusing on? Are the number of people knowledgeable around scons really 
greater than what we have now? But I could be wrong, which leads me to #2...

  2. "The conversion from gbuild to scons would largely be automated, fast and 
correct." If that is the case, let's test that theory right now.
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: about build environment development

[Peter Kovacs]

Hi All,


Damjan, thanks for providing the feature list on SCONs. I did not have 
that on the able.


For me it is a promising Idea with a lot of questions attached to it.

And I am not 100% convinced it can solve the Issues where we got stuck 
on Gmake.



I would also like to know which arguments speak for using something we 
already have? That is not clear to me Patricia.



I am sorry. But I believe except Damjan no one has bought in to SCONs 
completely.


For me there are to many questions open and ant is still in the race. It 
does not have the great build in c++ support,


but it is easier to build in in IDEs and we can sign our stuff at least 
on windows with it. Probably on Mac too.


It has also great support to be extended, and it has as SCONS a 
dependency support.



I think we have to think on the following:

# Build bots

## support our own

## support for Azure (they have mac server free for OpenSource Projects!)

# Maven development support for 3rd party contributors

# Various different Platform and distribution support.

## Distribution we might need distribution specific patch support.

# support of building our own dependencies.

## automated Signing support, for our targets.

maybe

# easy to add other architectures. (I know that we might have an Issue 
in UNO here in general)



In the end all we need is Plan. Maybe we could combine SCONS and ANT 
through Jython -Ant as Frontend and SCONS as workhorse?


I do not know. But we should deliver answers to our needs. And doing 
PoCs is good.



All the Best

Peter


Am 15.04.20 um 09:01 schrieb Damjan Jovanovic:


On Wed, Apr 15, 2020 at 6:46 AM Peter Kovacs  wrote:


If one wants to tap in our build system he needs to understand Perl,
shell, make, ant, XML, configure, ...

This is just way to complicated, especially if you want to bring in an
IDE to ease code development.


Damjan is not very happy with the features gmake offers. I am not sure
where exactly the Issue is.

He is opting for SCONs, with the option to extend the build system with
python. And IMHO on Damjan

Side he is quite serious about it.


Everyone else has not expressed any opinion on this development, so I am
not sure everyone is aware. The last discussion on this topic,

consent has been strongly to make gmake work.


We already took that approach to its limit, and I don't believe we can go
much further. Most of gmake works by luck. The simplest things break, make
no sense, and cannot be debugged, eg. sometimes *_add_files breaks, but
*_add_file works, despite the fact the former just calls the latter. There
are already some hacks in modules to work around gmake's brokenness...



Another objection is that we got some heavy negative experience report
from the serf community about SCONS.



It wasn't the entire "serf community", just brane@ on 30 Oct 2019:
---snip---
As a far-too-long-time user of Scons (in Serf), let me just add a
caution: Scons is very, very broken and not at all well maintained.
Writing a truly cross-platform, cross-toolchain SConstruct file for
anything other than really trivial cases amounts to writing a *lot* of
platform-specific Python code to make the builds work.

If you're already moving to gmake (without autotools, and I expect using
Cygwin on Windows), then I suggest you finish the transition, then leave
well enough alone.
---snip---

My experience so far has been exactly the opposite: it is far easier to get
scons building cross-platform, than GNU make + countless shell tools which
also drag in the whole of Cygwin.

To summarize quickly:
I tried to avoid scons before and use gmake, and we already got as far as
we could.
scons is not a decision I made lightly, it's a decision I made because it's
that good.
Python isn't my favorite language, but what we gain from scons is
significant enough for me to want to learn more Python.
By using scons, Cygwin left the building without me even trying.
scons has a 20 year history, supports OS/2 and numerous other platforms,
supports Python 2 and 3, supports more MSVC versions than we do (including
Visual Studio 2019), would allow us to build almost anywhere.
It is packed full of many advanced features we need, like symlinking
libX.so -> libX.so.2, automated header dependency scanning, flex, yacc,
Java, Objective C, precompiled headers on MSVC, fully parallelizes builds
across module boundaries, can work out minimal rebuilds using checksums of
file contents instead of inode timestamps, is extensible by design, has
readable source code, can be debugged, and is under a liberal license
(MIT). I've looked, and nothing else really comes close; every other build
tool would require considerable further development (AOO has already tried
building big build systems around both dmake and GNU make; my better
experience with Ant/Maven makes me more hopeful about a richer higher-level
build tool that automates more of the work internally).
The conversion from gbuild to scons would largely be au

Re: about build environment development (was: declaring gbuild target dependencies)

[Damjan Jovanovic]

On Wed, Apr 15, 2020 at 6:46 AM Peter Kovacs  wrote:

> If one wants to tap in our build system he needs to understand Perl,
> shell, make, ant, XML, configure, ...
>
> This is just way to complicated, especially if you want to bring in an
> IDE to ease code development.
>
>
> Damjan is not very happy with the features gmake offers. I am not sure
> where exactly the Issue is.
>
> He is opting for SCONs, with the option to extend the build system with
> python. And IMHO on Damjan
>
> Side he is quite serious about it.
>
>
> Everyone else has not expressed any opinion on this development, so I am
> not sure everyone is aware. The last discussion on this topic,
>
> consent has been strongly to make gmake work.
>

We already took that approach to its limit, and I don't believe we can go
much further. Most of gmake works by luck. The simplest things break, make
no sense, and cannot be debugged, eg. sometimes *_add_files breaks, but
*_add_file works, despite the fact the former just calls the latter. There
are already some hacks in modules to work around gmake's brokenness...


>
> Another objection is that we got some heavy negative experience report
> from the serf community about SCONS.
>
>
It wasn't the entire "serf community", just brane@ on 30 Oct 2019:
---snip---
As a far-too-long-time user of Scons (in Serf), let me just add a
caution: Scons is very, very broken and not at all well maintained.
Writing a truly cross-platform, cross-toolchain SConstruct file for
anything other than really trivial cases amounts to writing a *lot* of
platform-specific Python code to make the builds work.

If you're already moving to gmake (without autotools, and I expect using
Cygwin on Windows), then I suggest you finish the transition, then leave
well enough alone.
---snip---

My experience so far has been exactly the opposite: it is far easier to get
scons building cross-platform, than GNU make + countless shell tools which
also drag in the whole of Cygwin.

To summarize quickly:
I tried to avoid scons before and use gmake, and we already got as far as
we could.
scons is not a decision I made lightly, it's a decision I made because it's
that good.
Python isn't my favorite language, but what we gain from scons is
significant enough for me to want to learn more Python.
By using scons, Cygwin left the building without me even trying.
scons has a 20 year history, supports OS/2 and numerous other platforms,
supports Python 2 and 3, supports more MSVC versions than we do (including
Visual Studio 2019), would allow us to build almost anywhere.
It is packed full of many advanced features we need, like symlinking
libX.so -> libX.so.2, automated header dependency scanning, flex, yacc,
Java, Objective C, precompiled headers on MSVC, fully parallelizes builds
across module boundaries, can work out minimal rebuilds using checksums of
file contents instead of inode timestamps, is extensible by design, has
readable source code, can be debugged, and is under a liberal license
(MIT). I've looked, and nothing else really comes close; every other build
tool would require considerable further development (AOO has already tried
building big build systems around both dmake and GNU make; my better
experience with Ant/Maven makes me more hopeful about a richer higher-level
build tool that automates more of the work internally).
The conversion from gbuild to scons would largely be automated, fast and
correct. (We could also keep the scons files in a format that would allow
easier automated conversion to something else later.)


> Which are switching from, SCONS to cmake.
>
>
> So in the end we do not have Consent where we want to go. And currently
> it is heavily influenced by Damjan. And this is imho very thin.
>
>
Then we were always very thin on gbuild too.

You've also done some scons development.

We are also thin on new contributors, and I recall you saying they're
largely scared off by the current build system.


> I am still like the Idea most to go in the direction of ant / maven,
> despite its flaws. But I am not negative on SCONS either. My main point
> is we need something that
>
> offers a better architecture and is easier to handled and maintained.
>
>
> Also what we could try is making use of something like portage. Portage
> is pretty easy to use repostory manager used by gentoo, whioch also had
> a community prior to homebrew on mac. It is not very difficult to
> setup.  But it is build to make different build system work together. So
> we could have a build repository, that builds our dependencies. We
> reconstruct our monolith in smaller build libraries, like UNOcore,
> OOFrame, UNOGUI, OOapp, OOpython, StarBasic, OOwizards, extentionXYZ
> (Just saying something), and pick the best build system (cmake, gmake,
> ant, maven, SCONS) for each library. Also we could think on

Re: about build environment development

[Patricia Shanahan]

Without knowing enough about the merits of the different build systems 
we got where we are through a history in which a new build system is 
selected every N years, but it takes more than N years to fully switch.


My recommendation is to pick one of the existing build systems, and get 
everything on to it.


On 4/14/2020 9:46 PM, Peter Kovacs wrote:
If one wants to tap in our build system he needs to understand Perl, 
shell, make, ant, XML, configure, ...


This is just way to complicated, especially if you want to bring in an 
IDE to ease code development.



Damjan is not very happy with the features gmake offers. I am not sure 
where exactly the Issue is.


He is opting for SCONs, with the option to extend the build system with 
python. And IMHO on Damjan


Side he is quite serious about it.


Everyone else has not expressed any opinion on this development, so I am 
not sure everyone is aware. The last discussion on this topic,


consent has been strongly to make gmake work.

Another objection is that we got some heavy negative experience report 
from the serf community about SCONS.


Which are switching from, SCONS to cmake.


So in the end we do not have Consent where we want to go. And currently 
it is heavily influenced by Damjan. And this is imho very thin.


I am still like the Idea most to go in the direction of ant / maven, 
despite its flaws. But I am not negative on SCONS either. My main point 
is we need something that


offers a better architecture and is easier to handled and maintained.


Also what we could try is making use of something like portage. Portage 
is pretty easy to use repostory manager used by gentoo, whioch also had 
a community prior to homebrew on mac. It is not very difficult to 
setup.  But it is build to make different build system work together. So 
we could have a build repository, that builds our dependencies. We 
reconstruct our monolith in smaller build libraries, like UNOcore, 
OOFrame, UNOGUI, OOapp, OOpython, StarBasic, OOwizards, extentionXYZ 
(Just saying something), and pick the best build system (cmake, gmake, 
ant, maven, SCONS) for each library. Also we could think on incubating 
Starbasic or UNO, as own Project if they become more interesting. Since 
Portage is made for source build, but can also handle binaries, maybe we 
could add some features that will make it easy to export towards 
specific distributions, making it easy for distributors to export to 
their system. BTW, portage is build on python, so it should work on all 
systems we target. Sorry if this Idea is to crazy for you. It is only an 
idea.



Maybe it is a good time now to bring this topic up in everyones mind.


All the Best

Peter


Am 15.04.20 um 01:14 schrieb Carl Marcum:



On 4/14/20 5:53 PM, Kay Schenk wrote:


On 4/14/20 1:46 PM, Carl Marcum wrote:



On 4/14/20 3:57 PM, Peter Kovacs wrote:
You could try to build only the module, by going into the folder 
and execute make directly.


Hi Peter,

Yes but that doesn't solve my problem with targets not running in 
order or how I can enforce it if possible.

I don't want to break the build if my change ever makes it to trunk.

Eventually if I can get Ant to build the Jar exactly as gbuild does 
I can use that one and my problem goes away.

But until then I was wanting to use the current one that gbuild builds.

Thanks,
Carl


Hi Carl --

From your first post in this thread...

When I build with "build --all" everything works as expected.
When I build with "build --all -P2 -- -P2" the file copy fails 
because the juh.jar file isn't completed.


I recall having issues with the second part -- -P2.

You might try omitting that, and just use "build --all -P2" or maybe 
"build --all -P4"


ref...

https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO#Building_2 



The build will take a longer but you shouldn't run into the 
"non-completion" issue you're having.


Hope this helps,

Kay


Hi Kay,

Thanks for pointing out what the second parameter meant :)

It would still be good to know if it's possible to declare 
dependencies between targets in gbuild somehow like you can with Ant 
builds.


I'm guessing any final solution that gets into trunk has to build with 
multiple threads per module.


My best option is probably to do the jar build along with the other 
tasks in Ant so I can control when it happens.


Were already using Ant to build java jars in ridljar, jurt, 
officebean, and probably other modules.


I didn't mention it but I'm working on creating the necessary javadoc, 
source, and library jars for distribution through Apache Nexus [1].
But during the build process to avoid the need for a separate Vote 
next time around.


[1] https://wiki.openoffice.org/wiki/Uno/Java/MavenBundles

Thanks again,
Carl



-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additiona

about build environment development (was: declaring gbuild target dependencies)

[Peter Kovacs]

If one wants to tap in our build system he needs to understand Perl, 
shell, make, ant, XML, configure, ...


This is just way to complicated, especially if you want to bring in an 
IDE to ease code development.



Damjan is not very happy with the features gmake offers. I am not sure 
where exactly the Issue is.


He is opting for SCONs, with the option to extend the build system with 
python. And IMHO on Damjan


Side he is quite serious about it.


Everyone else has not expressed any opinion on this development, so I am 
not sure everyone is aware. The last discussion on this topic,


consent has been strongly to make gmake work.

Another objection is that we got some heavy negative experience report 
from the serf community about SCONS.


Which are switching from, SCONS to cmake.


So in the end we do not have Consent where we want to go. And currently 
it is heavily influenced by Damjan. And this is imho very thin.


I am still like the Idea most to go in the direction of ant / maven, 
despite its flaws. But I am not negative on SCONS either. My main point 
is we need something that


offers a better architecture and is easier to handled and maintained.


Also what we could try is making use of something like portage. Portage 
is pretty easy to use repostory manager used by gentoo, whioch also had 
a community prior to homebrew on mac. It is not very difficult to 
setup.  But it is build to make different build system work together. So 
we could have a build repository, that builds our dependencies. We 
reconstruct our monolith in smaller build libraries, like UNOcore, 
OOFrame, UNOGUI, OOapp, OOpython, StarBasic, OOwizards, extentionXYZ 
(Just saying something), and pick the best build system (cmake, gmake, 
ant, maven, SCONS) for each library. Also we could think on incubating 
Starbasic or UNO, as own Project if they become more interesting. Since 
Portage is made for source build, but can also handle binaries, maybe we 
could add some features that will make it easy to export towards 
specific distributions, making it easy for distributors to export to 
their system. BTW, portage is build on python, so it should work on all 
systems we target. Sorry if this Idea is to crazy for you. It is only an 
idea.



Maybe it is a good time now to bring this topic up in everyones mind.


All the Best

Peter


Am 15.04.20 um 01:14 schrieb Carl Marcum:



On 4/14/20 5:53 PM, Kay Schenk wrote:


On 4/14/20 1:46 PM, Carl Marcum wrote:



On 4/14/20 3:57 PM, Peter Kovacs wrote:
You could try to build only the module, by going into the folder 
and execute make directly.


Hi Peter,

Yes but that doesn't solve my problem with targets not running in 
order or how I can enforce it if possible.

I don't want to break the build if my change ever makes it to trunk.

Eventually if I can get Ant to build the Jar exactly as gbuild does 
I can use that one and my problem goes away.

But until then I was wanting to use the current one that gbuild builds.

Thanks,
Carl


Hi Carl --

From your first post in this thread...

When I build with "build --all" everything works as expected.
When I build with "build --all -P2 -- -P2" the file copy fails 
because the juh.jar file isn't completed.


I recall having issues with the second part -- -P2.

You might try omitting that, and just use "build --all -P2" or maybe 
"build --all -P4"


ref...

https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO#Building_2 



The build will take a longer but you shouldn't run into the 
"non-completion" issue you're having.


Hope this helps,

Kay


Hi Kay,

Thanks for pointing out what the second parameter meant :)

It would still be good to know if it's possible to declare 
dependencies between targets in gbuild somehow like you can with Ant 
builds.


I'm guessing any final solution that gets into trunk has to build with 
multiple threads per module.


My best option is probably to do the jar build along with the other 
tasks in Ant so I can control when it happens.


Were already using Ant to build java jars in ridljar, jurt, 
officebean, and probably other modules.


I didn't mention it but I'm working on creating the necessary javadoc, 
source, and library jars for distribution through Apache Nexus [1].
But during the build process to avoid the need for a separate Vote 
next time around.


[1] https://wiki.openoffice.org/wiki/Uno/Java/MavenBundles

Thanks again,
Carl



-
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: AOO 4.2.x development branch created

[Marcus]

Am 25.01.19 um 19:08 schrieb Mechtilde:

100 % translated Help are German and Dutch:

https://translate.apache.org/projects/aoo40help/

And here the link to the Ui

https://translate.apache.org/projects/aoo40/
You can sort them yourself at the top of the columns


thanks, I thought it would be already more.

Then I think we should give people a chance to translate the last few 
percent for specific languages. Then we have more languages with 100% - 
UI and/or help.


That means include a (longer) translation time frame in the relase plan.

Marcus




Am 25.01.19 um 18:56 schrieb Marcus:

Am 25.01.19 um 18:39 schrieb Mechtilde:

Am 25.01.19 um 17:29 schrieb Marcus:

Am 10.01.19 um 16:50 schrieb Pedro Giffuni:




do you remember the BZ issues? I would like to add them to the list in
the new release notes (it's a first, very rough draft):

https://cwiki.apache.org/confluence/display/OOOUSERS/Release+Notes+Apache+4.2.0



I add the languages with has 100 % translated UI in Pootle.


thanks, are there any new languages with 100% complete Help content?

Then we should write this, too, as it is interesting for the users.



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

Re: AOO 4.2.x development branch created

[Mechtilde]

Hello Marcus

100 % translated Help are German and Dutch:

https://translate.apache.org/projects/aoo40help/

And here the link to the Ui

https://translate.apache.org/projects/aoo40/
You can sort them yourself at the top of the columns

Regards

Am 25.01.19 um 18:56 schrieb Marcus:
> Am 25.01.19 um 18:39 schrieb Mechtilde:
>> Am 25.01.19 um 17:29 schrieb Marcus:
>>> Am 10.01.19 um 16:50 schrieb Pedro Giffuni:
>>
>>>
>>> do you remember the BZ issues? I would like to add them to the list in
>>> the new release notes (it's a first, very rough draft):
>>>
>>> https://cwiki.apache.org/confluence/display/OOOUSERS/Release+Notes+Apache+4.2.0
>>>
>>
>> I add the languages with has 100 % translated UI in Pootle.
> 
> thanks, are there any new languages with 100% complete Help content?
> 
> Then we should write this, too, as it is interesting for the users.
> 
> Marcus
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
> 

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



signature.asc
Description: OpenPGP digital signature

Re: AOO 4.2.x development branch created

[Marcus]

Am 25.01.19 um 18:39 schrieb Mechtilde:

Am 25.01.19 um 17:29 schrieb Marcus:

Am 10.01.19 um 16:50 schrieb Pedro Giffuni:




do you remember the BZ issues? I would like to add them to the list in
the new release notes (it's a first, very rough draft):

https://cwiki.apache.org/confluence/display/OOOUSERS/Release+Notes+Apache+4.2.0


I add the languages with has 100 % translated UI in Pootle.


thanks, are there any new languages with 100% complete Help content?

Then we should write this, too, as it is interesting for the users.

Marcus


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

Re: AOO 4.2.x development branch created

[Mechtilde]

Hello,

Am 25.01.19 um 17:29 schrieb Marcus:
> Am 10.01.19 um 16:50 schrieb Pedro Giffuni:

> 
> do you remember the BZ issues? I would like to add them to the list in
> the new release notes (it's a first, very rough draft):
> 
> https://cwiki.apache.org/confluence/display/OOOUSERS/Release+Notes+Apache+4.2.0

I add the languages with has 100 % translated UI in Pootle.
> 
> 
> Thanks
> 
> Marcus
> 

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



signature.asc
Description: OpenPGP digital signature

Re: AOO 4.2.x development branch created

[Marcus]

Am 10.01.19 um 16:50 schrieb Pedro Giffuni:
Thank you to everyone getting involved in the new release. It is very 
much needed and I was really tired of the continuous revamping of the 
4.1 releases. It is now clear that we are also doing proper branching of 
the releases.


Some of the issues off the top of my head that you may want to mention 
on the Release Notes:


- All the fonts have been updated. We also added two fonts Caladea and 
Carlito which are geometrically compatible to Microsoft Cambria and 
Calibre.


- Python was updated to 2.7.15. Hunspell was updated to 1.3.3.

- Cleanups for many, many typos everywhere.

- Fixed many issues detected by Coverity scan.

There are many more changes that I surely forgot about.


do you remember the BZ issues? I would like to add them to the list in 
the new release notes (it's a first, very rough draft):


https://cwiki.apache.org/confluence/display/OOOUSERS/Release+Notes+Apache+4.2.0

Thanks

Marcus


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

Re: AOO 4.2.x development branch created

[Matthias Seidel]

Hi Dave,

Am 18.01.19 um 06:54 schrieb Dave Fisher:
> What action is there to take? It is a valid action by a downstream. Do we 
> wish they posted changes upstream? Yes! Can we require it? No!

It was just a funny side note for a fork that claims to be the "real"
successor of OpenOffice.org.

They forked in 2011(?) but list copyright back to 2000. Maybe here is
some action to be taken?

Regards,

   Matthias

>
> Regards,
> Dave
>
> Sent from my iPhone
>
>> On Jan 17, 2019, at 9:19 PM, Peter Kovacs  wrote:
>>
>> The Question is:
>>
>> Do we want to take action here or not?
>>
>>
>>> On 17.01.19 21:19, Matthias Seidel wrote:
>>> Hi Marcus,
>>>
 Am 17.01.19 um 20:42 schrieb Marcus:
> Am 17.01.19 um 13:41 schrieb Matthias Seidel:
> Two of my commits were immediately picked by LO. [1] [2]
>
> Always nice to see, that down streaming still works for the fork... :-D
 sure, better then to draw this on their own.

 Again with a note who has tested and reviewed it  - which is totally
 fine - but no hint where it comes from and who is the author. They
 still don't want to tell where they get the code from.
>>> Not exactly, Pilot_Pirx is me... ;-)
>>>
>>> But now it looks like I would have committed it directly to LO, while
>>> they just monitor aoo/trunk and take what they can use. [1]
>>>
>>> Regards,
>>>
>>>Matthias
>>>
>>> [1]
>>> https://github.com/LibreOffice/core/commit/1170f10906a9bca78782df6ab1b6a4e20cf0435a
>>>
 Is this redicioulous or just sad? I don't know. :-(

 Marcus



> [1]
> https://github.com/LibreOffice/core/commit/28dee1129c7a9c4da34b9253aefd6c6b2df1a073
>
> [2]
> https://github.com/LibreOffice/core/commit/9796738e1149a99f8b3ff687b0f72264ba3a56ff
>
>
>> Am 14.01.19 um 16:46 schrieb Jim Jagielski:
>> At this stage, I think just back porting (svn merge) to the AOO42X
>> branch is fine.
>> As we get close to a release, we'll need to either have an RM
>> approve it
>> or so something like creating a STATUS file, with a list of proposed
>> backports
>> and requiring at least 3 +1s to backport (ie: RTC)
>>
>>> On Jan 14, 2019, at 10:40 AM, Matthias Seidel
>>>  wrote:
>>>
>>> Hi Jim,
>>>
>>> Am 09.01.19 um 21:54 schrieb Jim Jagielski:
> On Jan 9, 2019, at 3:46 PM, Jim Jagielski  wrote:
>
> Ahh... something w/ the cppuhelper stuff. Obviously, some UDK
> issue I'm thinking...
>>> How is the process to get commits merged from trunk to AOO42X?
>>>
>>> I adjusted some pointers for Windows and Linux:
>>>
>>> https://svn.apache.org/viewvc?view=revision=1851110
>>> https://svn.apache.org/viewvc?view=revision=185
>>> https://svn.apache.org/viewvc?view=revision=1851214
>>>
>>> Additionally I updated some pointers for OS/2. I know that Bitwise is
>>> already working on a port of 4.2.0, so they would be useful.
>>>
>>> Since it took me several attempts it would be easier, if I would
>>> commit
>>> them directly. ..
>>>
>>> Regards
>>>
>>> Matthias
>>>
 Yeppers... for sure it's the udk versioning, which is more a Linux
 thing than a macOS (or Windows) thing.

 Will look into either hacking around it or something else. I
 thought I had fixed it. Obviously not :(
 -
 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: AOO 4.2.x development branch created

[Dave Fisher]

What action is there to take? It is a valid action by a downstream. Do we wish 
they posted changes upstream? Yes! Can we require it? No!

Regards,
Dave

Sent from my iPhone

> On Jan 17, 2019, at 9:19 PM, Peter Kovacs  wrote:
> 
> The Question is:
> 
> Do we want to take action here or not?
> 
> 
>> On 17.01.19 21:19, Matthias Seidel wrote:
>> Hi Marcus,
>> 
>>> Am 17.01.19 um 20:42 schrieb Marcus:
 Am 17.01.19 um 13:41 schrieb Matthias Seidel:
 Two of my commits were immediately picked by LO. [1] [2]
 
 Always nice to see, that down streaming still works for the fork... :-D
>>> sure, better then to draw this on their own.
>>> 
>>> Again with a note who has tested and reviewed it  - which is totally
>>> fine - but no hint where it comes from and who is the author. They
>>> still don't want to tell where they get the code from.
>> Not exactly, Pilot_Pirx is me... ;-)
>> 
>> But now it looks like I would have committed it directly to LO, while
>> they just monitor aoo/trunk and take what they can use. [1]
>> 
>> Regards,
>> 
>>Matthias
>> 
>> [1]
>> https://github.com/LibreOffice/core/commit/1170f10906a9bca78782df6ab1b6a4e20cf0435a
>> 
>>> Is this redicioulous or just sad? I don't know. :-(
>>> 
>>> Marcus
>>> 
>>> 
>>> 
 [1]
 https://github.com/LibreOffice/core/commit/28dee1129c7a9c4da34b9253aefd6c6b2df1a073
 
 [2]
 https://github.com/LibreOffice/core/commit/9796738e1149a99f8b3ff687b0f72264ba3a56ff
 
 
> Am 14.01.19 um 16:46 schrieb Jim Jagielski:
> At this stage, I think just back porting (svn merge) to the AOO42X
> branch is fine.
> As we get close to a release, we'll need to either have an RM
> approve it
> or so something like creating a STATUS file, with a list of proposed
> backports
> and requiring at least 3 +1s to backport (ie: RTC)
> 
>> On Jan 14, 2019, at 10:40 AM, Matthias Seidel
>>  wrote:
>> 
>> Hi Jim,
>> 
>> Am 09.01.19 um 21:54 schrieb Jim Jagielski:
 On Jan 9, 2019, at 3:46 PM, Jim Jagielski  wrote:
 
 Ahh... something w/ the cppuhelper stuff. Obviously, some UDK
 issue I'm thinking...
>> How is the process to get commits merged from trunk to AOO42X?
>> 
>> I adjusted some pointers for Windows and Linux:
>> 
>> https://svn.apache.org/viewvc?view=revision=1851110
>> https://svn.apache.org/viewvc?view=revision=185
>> https://svn.apache.org/viewvc?view=revision=1851214
>> 
>> Additionally I updated some pointers for OS/2. I know that Bitwise is
>> already working on a port of 4.2.0, so they would be useful.
>> 
>> Since it took me several attempts it would be easier, if I would
>> commit
>> them directly. ..
>> 
>> Regards
>> 
>> Matthias
>> 
>>> Yeppers... for sure it's the udk versioning, which is more a Linux
>>> thing than a macOS (or Windows) thing.
>>> 
>>> Will look into either hacking around it or something else. I
>>> thought I had fixed it. Obviously not :(
>>> 
>>> -
>>> 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: AOO 4.2.x development branch created

[Peter Kovacs]

The Question is:

Do we want to take action here or not?


On 17.01.19 21:19, Matthias Seidel wrote:
> Hi Marcus,
>
> Am 17.01.19 um 20:42 schrieb Marcus:
>> Am 17.01.19 um 13:41 schrieb Matthias Seidel:
>>> Two of my commits were immediately picked by LO. [1] [2]
>>>
>>> Always nice to see, that down streaming still works for the fork... :-D
>> sure, better then to draw this on their own.
>>
>> Again with a note who has tested and reviewed it  - which is totally
>> fine - but no hint where it comes from and who is the author. They
>> still don't want to tell where they get the code from.
> Not exactly, Pilot_Pirx is me... ;-)
>
> But now it looks like I would have committed it directly to LO, while
> they just monitor aoo/trunk and take what they can use. [1]
>
> Regards,
>
>    Matthias
>
> [1]
> https://github.com/LibreOffice/core/commit/1170f10906a9bca78782df6ab1b6a4e20cf0435a
>
>> Is this redicioulous or just sad? I don't know. :-(
>>
>> Marcus
>>
>>
>>
>>> [1]
>>> https://github.com/LibreOffice/core/commit/28dee1129c7a9c4da34b9253aefd6c6b2df1a073
>>>
>>> [2]
>>> https://github.com/LibreOffice/core/commit/9796738e1149a99f8b3ff687b0f72264ba3a56ff
>>>
>>>
>>> Am 14.01.19 um 16:46 schrieb Jim Jagielski:
 At this stage, I think just back porting (svn merge) to the AOO42X
 branch is fine.
 As we get close to a release, we'll need to either have an RM
 approve it
 or so something like creating a STATUS file, with a list of proposed
 backports
 and requiring at least 3 +1s to backport (ie: RTC)

> On Jan 14, 2019, at 10:40 AM, Matthias Seidel
>  wrote:
>
> Hi Jim,
>
> Am 09.01.19 um 21:54 schrieb Jim Jagielski:
>>> On Jan 9, 2019, at 3:46 PM, Jim Jagielski  wrote:
>>>
>>> Ahh... something w/ the cppuhelper stuff. Obviously, some UDK
>>> issue I'm thinking...
> How is the process to get commits merged from trunk to AOO42X?
>
> I adjusted some pointers for Windows and Linux:
>
> https://svn.apache.org/viewvc?view=revision=1851110
> https://svn.apache.org/viewvc?view=revision=185
> https://svn.apache.org/viewvc?view=revision=1851214
>
> Additionally I updated some pointers for OS/2. I know that Bitwise is
> already working on a port of 4.2.0, so they would be useful.
>
> Since it took me several attempts it would be easier, if I would
> commit
> them directly. ..
>
> Regards
>
>     Matthias
>
>> Yeppers... for sure it's the udk versioning, which is more a Linux
>> thing than a macOS (or Windows) thing.
>>
>> Will look into either hacking around it or something else. I
>> thought I had fixed it. Obviously not :(
>>
>> -
>> 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: AOO 4.2.x development branch created

[Matthias Seidel]

Hi Marcus,

Am 17.01.19 um 20:42 schrieb Marcus:
> Am 17.01.19 um 13:41 schrieb Matthias Seidel:
>> Two of my commits were immediately picked by LO. [1] [2]
>>
>> Always nice to see, that down streaming still works for the fork... :-D
>
> sure, better then to draw this on their own.
>
> Again with a note who has tested and reviewed it  - which is totally
> fine - but no hint where it comes from and who is the author. They
> still don't want to tell where they get the code from.

Not exactly, Pilot_Pirx is me... ;-)

But now it looks like I would have committed it directly to LO, while
they just monitor aoo/trunk and take what they can use. [1]

Regards,

   Matthias

[1]
https://github.com/LibreOffice/core/commit/1170f10906a9bca78782df6ab1b6a4e20cf0435a

>
> Is this redicioulous or just sad? I don't know. :-(
>
> Marcus
>
>
>
>> [1]
>> https://github.com/LibreOffice/core/commit/28dee1129c7a9c4da34b9253aefd6c6b2df1a073
>>
>> [2]
>> https://github.com/LibreOffice/core/commit/9796738e1149a99f8b3ff687b0f72264ba3a56ff
>>
>>
>> Am 14.01.19 um 16:46 schrieb Jim Jagielski:
>>> At this stage, I think just back porting (svn merge) to the AOO42X
>>> branch is fine.
>>> As we get close to a release, we'll need to either have an RM
>>> approve it
>>> or so something like creating a STATUS file, with a list of proposed
>>> backports
>>> and requiring at least 3 +1s to backport (ie: RTC)
>>>
 On Jan 14, 2019, at 10:40 AM, Matthias Seidel
  wrote:

 Hi Jim,

 Am 09.01.19 um 21:54 schrieb Jim Jagielski:
>> On Jan 9, 2019, at 3:46 PM, Jim Jagielski  wrote:
>>
>> Ahh... something w/ the cppuhelper stuff. Obviously, some UDK
>> issue I'm thinking...
 How is the process to get commits merged from trunk to AOO42X?

 I adjusted some pointers for Windows and Linux:

 https://svn.apache.org/viewvc?view=revision=1851110
 https://svn.apache.org/viewvc?view=revision=185
 https://svn.apache.org/viewvc?view=revision=1851214

 Additionally I updated some pointers for OS/2. I know that Bitwise is
 already working on a port of 4.2.0, so they would be useful.

 Since it took me several attempts it would be easier, if I would
 commit
 them directly. ..

 Regards

     Matthias

> Yeppers... for sure it's the udk versioning, which is more a Linux
> thing than a macOS (or Windows) thing.
>
> Will look into either hacking around it or something else. I
> thought I had fixed it. Obviously not :(
>
>
> -
> 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.x development branch created

[Marcus]

Am 17.01.19 um 13:41 schrieb Matthias Seidel:

Two of my commits were immediately picked by LO. [1] [2]

Always nice to see, that down streaming still works for the fork... :-D


sure, better then to draw this on their own.

Again with a note who has tested and reviewed it  - which is totally 
fine - but no hint where it comes from and who is the author. They still 
don't want to tell where they get the code from.


Is this redicioulous or just sad? I don't know. :-(

Marcus




[1]
https://github.com/LibreOffice/core/commit/28dee1129c7a9c4da34b9253aefd6c6b2df1a073
[2]
https://github.com/LibreOffice/core/commit/9796738e1149a99f8b3ff687b0f72264ba3a56ff

Am 14.01.19 um 16:46 schrieb Jim Jagielski:

At this stage, I think just back porting (svn merge) to the AOO42X branch is 
fine.
As we get close to a release, we'll need to either have an RM approve it
or so something like creating a STATUS file, with a list of proposed backports
and requiring at least 3 +1s to backport (ie: RTC)


On Jan 14, 2019, at 10:40 AM, Matthias Seidel  
wrote:

Hi Jim,

Am 09.01.19 um 21:54 schrieb Jim Jagielski:

On Jan 9, 2019, at 3:46 PM, Jim Jagielski  wrote:

Ahh... something w/ the cppuhelper stuff. Obviously, some UDK issue I'm 
thinking...

How is the process to get commits merged from trunk to AOO42X?

I adjusted some pointers for Windows and Linux:

https://svn.apache.org/viewvc?view=revision=1851110
https://svn.apache.org/viewvc?view=revision=185
https://svn.apache.org/viewvc?view=revision=1851214

Additionally I updated some pointers for OS/2. I know that Bitwise is
already working on a port of 4.2.0, so they would be useful.

Since it took me several attempts it would be easier, if I would commit
them directly. ..

Regards

Matthias


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

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



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

Re: AOO 4.2.x development branch created

[Matthias Seidel]

Two of my commits were immediately picked by LO. [1] [2]

Always nice to see, that down streaming still works for the fork... :-D

Regards,

   Matthias

[1]
https://github.com/LibreOffice/core/commit/28dee1129c7a9c4da34b9253aefd6c6b2df1a073
[2]
https://github.com/LibreOffice/core/commit/9796738e1149a99f8b3ff687b0f72264ba3a56ff

Am 14.01.19 um 16:46 schrieb Jim Jagielski:
> At this stage, I think just back porting (svn merge) to the AOO42X branch is 
> fine.
> As we get close to a release, we'll need to either have an RM approve it
> or so something like creating a STATUS file, with a list of proposed backports
> and requiring at least 3 +1s to backport (ie: RTC)
>
>> On Jan 14, 2019, at 10:40 AM, Matthias Seidel  
>> wrote:
>>
>> Hi Jim,
>>
>> Am 09.01.19 um 21:54 schrieb Jim Jagielski:
 On Jan 9, 2019, at 3:46 PM, Jim Jagielski  wrote:

 Ahh... something w/ the cppuhelper stuff. Obviously, some UDK issue I'm 
 thinking...
>> How is the process to get commits merged from trunk to AOO42X?
>>
>> I adjusted some pointers for Windows and Linux:
>>
>> https://svn.apache.org/viewvc?view=revision=1851110
>> https://svn.apache.org/viewvc?view=revision=185
>> https://svn.apache.org/viewvc?view=revision=1851214
>>
>> Additionally I updated some pointers for OS/2. I know that Bitwise is
>> already working on a port of 4.2.0, so they would be useful.
>>
>> Since it took me several attempts it would be easier, if I would commit
>> them directly. ..
>>
>> Regards
>>
>>Matthias
>>
>>> Yeppers... for sure it's the udk versioning, which is more a Linux thing 
>>> than a macOS (or Windows) thing.
>>>
>>> Will look into either hacking around it or something else. I thought I had 
>>> fixed it. Obviously not :(
>>>
>>>
>>> -
>>> 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: Development beginner

[Peter Kovacs]

Hi Dustin,

OpenOffice is an old project. The code has been touched by many people.
OpenOffice is also a multi language project.

Parts of it are written in c, c++ or a mix of both. We got java and
python code. The build  environment is written in perl and bash. We use
in parts dmake, gmake and Ant. We have the Idea to port to SCON.

We have a own COM-Interface written in c,c++ and assembler. It connects
all language pieces.


There is no IDE that can handle this colorful approach. The best IDE
support is offered by eclipse and that is incomplete. Some use Visual
Studio.

Welcome to OpenOffice. :)

Best way to start with OpenOffice is to learn do your own builds and be
persistent. There is no shame in asking questions. Even the experienced
devs here have to ask around.

You find a general guide here:
https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO

specific guide:
https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Step_by_step

How to setup eclipse:
https://wiki.openoffice.org/wiki/OpenOffice_and_Eclipse


I try to organize tasks on Jira:
https://issues.apache.org/jira/secure/RapidBoard.jspa?projectKey=OPENOFFICE=301

you can of course help to maintain Bugzilla. We get frequent reports,
and have to look at old ones if they still are accurate.
https://bz.apache.org/ooo/

Also you can try and write hints on bugs can be solved. Maybe a hint
where to look can already help that a solution can be found.

Or help update the documentation on Programming. We have some stuff
here: https://wiki.openoffice.org/wiki/Category:Development


Hope this gives you enough hints and connects to choose how you
contribute to the project. All actions even learning to build is very
usefull for us.

All the best

Peter


On 14.01.19 02:46, Dustin Alldredge wrote:
> Hi guys, I recently graduated with my bachelor's degree and would like to
> get into development and thought that some experience with open office
> would be a great start. I've never been a part of any development teams
> outside of my educational experience so any tips or pointers would be very
> welcome. I have experience in several languages but am not sure what tools
> everyone uses here. Thank you and I look forward to working with you all!!
>


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

Re: AOO 4.2.x development branch created

[Mechtilde]

+1 from me

up to the time of a beta release

Mechtilde

Am 14.01.19 um 16:46 schrieb Jim Jagielski:
> At this stage, I think just back porting (svn merge) to the AOO42X branch is 
> fine.
> As we get close to a release, we'll need to either have an RM approve it
> or so something like creating a STATUS file, with a list of proposed backports
> and requiring at least 3 +1s to backport (ie: RTC)
> 
>> On Jan 14, 2019, at 10:40 AM, Matthias Seidel  
>> wrote:
>>
>> Hi Jim,
>>
>> Am 09.01.19 um 21:54 schrieb Jim Jagielski:
>>>
 On Jan 9, 2019, at 3:46 PM, Jim Jagielski  wrote:

 Ahh... something w/ the cppuhelper stuff. Obviously, some UDK issue I'm 
 thinking...
>>
>> How is the process to get commits merged from trunk to AOO42X?
>>
>> I adjusted some pointers for Windows and Linux:
>>
>> https://svn.apache.org/viewvc?view=revision=1851110
>> https://svn.apache.org/viewvc?view=revision=185
>> https://svn.apache.org/viewvc?view=revision=1851214
>>
>> Additionally I updated some pointers for OS/2. I know that Bitwise is
>> already working on a port of 4.2.0, so they would be useful.
>>
>> Since it took me several attempts it would be easier, if I would commit
>> them directly. ..
>>
>> Regards
>>
>>Matthias
>>

>>> Yeppers... for sure it's the udk versioning, which is more a Linux thing 
>>> than a macOS (or Windows) thing.
>>>
>>> Will look into either hacking around it or something else. I thought I had 
>>> fixed it. Obviously not :(
>>>
>>>
>>> -
>>> 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
> 

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



signature.asc
Description: OpenPGP digital signature

Re: AOO 4.2.x development branch created

[Jim Jagielski]

At this stage, I think just back porting (svn merge) to the AOO42X branch is 
fine.
As we get close to a release, we'll need to either have an RM approve it
or so something like creating a STATUS file, with a list of proposed backports
and requiring at least 3 +1s to backport (ie: RTC)

> On Jan 14, 2019, at 10:40 AM, Matthias Seidel  
> wrote:
> 
> Hi Jim,
> 
> Am 09.01.19 um 21:54 schrieb Jim Jagielski:
>> 
>>> On Jan 9, 2019, at 3:46 PM, Jim Jagielski  wrote:
>>> 
>>> Ahh... something w/ the cppuhelper stuff. Obviously, some UDK issue I'm 
>>> thinking...
> 
> How is the process to get commits merged from trunk to AOO42X?
> 
> I adjusted some pointers for Windows and Linux:
> 
> https://svn.apache.org/viewvc?view=revision=1851110
> https://svn.apache.org/viewvc?view=revision=185
> https://svn.apache.org/viewvc?view=revision=1851214
> 
> Additionally I updated some pointers for OS/2. I know that Bitwise is
> already working on a port of 4.2.0, so they would be useful.
> 
> Since it took me several attempts it would be easier, if I would commit
> them directly. ..
> 
> Regards
> 
>Matthias
> 
>>> 
>> Yeppers... for sure it's the udk versioning, which is more a Linux thing 
>> than a macOS (or Windows) thing.
>> 
>> Will look into either hacking around it or something else. I thought I had 
>> fixed it. Obviously not :(
>> 
>> 
>> -
>> 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: AOO 4.2.x development branch created

[Matthias Seidel]

Hi Jim,

Am 09.01.19 um 21:54 schrieb Jim Jagielski:
>
>> On Jan 9, 2019, at 3:46 PM, Jim Jagielski  wrote:
>>
>> Ahh... something w/ the cppuhelper stuff. Obviously, some UDK issue I'm 
>> thinking...

How is the process to get commits merged from trunk to AOO42X?

I adjusted some pointers for Windows and Linux:

https://svn.apache.org/viewvc?view=revision=1851110
https://svn.apache.org/viewvc?view=revision=185
https://svn.apache.org/viewvc?view=revision=1851214

Additionally I updated some pointers for OS/2. I know that Bitwise is
already working on a port of 4.2.0, so they would be useful.

Since it took me several attempts it would be easier, if I would commit
them directly. ..

Regards

   Matthias

>>
> Yeppers... for sure it's the udk versioning, which is more a Linux thing than 
> a macOS (or Windows) thing.
>
> Will look into either hacking around it or something else. I thought I had 
> fixed it. Obviously not :(
>
>
> -
> 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

Development beginner

[Dustin Alldredge]

Hi guys, I recently graduated with my bachelor's degree and would like to
get into development and thought that some experience with open office
would be a great start. I've never been a part of any development teams
outside of my educational experience so any tips or pointers would be very
welcome. I have experience in several languages but am not sure what tools
everyone uses here. Thank you and I look forward to working with you all!!

Re: Future development discussion

[Pedro Giffuni]

Win64 is also making good progress behind the scenes. The uncommitted Win64
UNO bridge I've been coding (a lot of it in AMD64 assembly) should now be
able to call arbitrary C++ methods from UNO and UNO methods from C++ (not
tested yet), but the poorly documented internals of MSVC C++ exception
handling are still TODO.

I also played a bit with mingw-w64 (an independent and alternative
mingw-like project capable of producing both Win32 and Win64 binaries) as
an alternative C++ compiler on Windows, but its MSYS2 environment can't
easily replace Cygwin due to using /c instead of /cygdrive/c, so a
tremendous amount of patching configure.ac, set_soenv.in, and many Perl
scripts that assume /cygdrive would be required. Using Cygwin instead of
MSYS2 might be more successful, but since GCC has different exception
handling to MSVC, Windows builds would need to be debugged with gdb instead
of Visual Studio, and AOO extensions would need to be built with mingw and
would be incompatible with the MSVC extensions. Also either we would need
the ship the GCC C and C++ runtimes, or link them statically and have
bloated binaries. It's worth noting LO gave up on mingw.

Where mingw could really help though, is building Windows binaries quickly
for testing purposes. Since Windows builds very slowly, and *nix builds
quickly, we could build a Windows version on *nix at *nix speeds by
compiling it in this setup:
mingw
Cygwin
Wine
*nix
;-)

We could also try a more ambitious setup of Windows Platform SDK in place
of mingw there, but how well it works on Wine is an open question.

FWIW, clang-cl from LLVM is really easy to install:

http://www.llvm.org/builds/

The thing is, libc++ hasn't been ported yet to Windows, so it depends on 
the Visual Studio libraries for everything.


All in all it is likely a better option than mingw, or cygwin.

Pedro.

Re: Future development discussion

[Peter Kovacs]

Okay, have all special quick points to my OpenOffice overview[1]. (I
skipped the ODF, and Pivot part, since there are plenty Bugzilla Issues
which I will find at some point in the future ;P )

I think we have a lot of technical Debt, and Issues that needs to be
fixed. Not only in the building environment.

As we see on the HTML filter, and the feedback it is also not easy to
enhance here.

And to the least, we are a multilanguage Project, which I found none IDE
supporting to my satisfaction. The best is Eclipse and that one handles
it not very well.


I hope with the Overview we can create a Roadmap in the future and
support people that are interested in topics with pointers what to look
out for.


All the Best

Peter


[1] https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=301




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

Re: Future development discussion

[Jim Jagielski]

+1 on doing what we can to move to gbuild as appropriate, but we also need
to find out what our long term plan is, esp as related to non-*Nix platforms.

I hope to get macOS more up-to-date and part of that is fixing the longstanding
confusion regarding UDK library versioning. Currently, AOO forces macOS to
follow the *Nix standard (libfoo.so.3, etc) which is NOT how macOS does it
(libfoo.3.dylib, NOT libfoo.dylib.3). I am working on this now, which should
be a step in the right directly and the plan is that this be part of 4.2.x
(might as well bite the bullet now since macOS doesn't build yet and
fails during the packaging phase now with the movement of some
libs to "real" UDK versioning via gbuild (and not dmake).
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Future development discussion

[Damjan Jovanovic]

Win64 is also making good progress behind the scenes. The uncommitted Win64
UNO bridge I've been coding (a lot of it in AMD64 assembly) should now be
able to call arbitrary C++ methods from UNO and UNO methods from C++ (not
tested yet), but the poorly documented internals of MSVC C++ exception
handling are still TODO.

I also played a bit with mingw-w64 (an independent and alternative
mingw-like project capable of producing both Win32 and Win64 binaries) as
an alternative C++ compiler on Windows, but its MSYS2 environment can't
easily replace Cygwin due to using /c instead of /cygdrive/c, so a
tremendous amount of patching configure.ac, set_soenv.in, and many Perl
scripts that assume /cygdrive would be required. Using Cygwin instead of
MSYS2 might be more successful, but since GCC has different exception
handling to MSVC, Windows builds would need to be debugged with gdb instead
of Visual Studio, and AOO extensions would need to be built with mingw and
would be incompatible with the MSVC extensions. Also either we would need
the ship the GCC C and C++ runtimes, or link them statically and have
bloated binaries. It's worth noting LO gave up on mingw.

Where mingw could really help though, is building Windows binaries quickly
for testing purposes. Since Windows builds very slowly, and *nix builds
quickly, we could build a Windows version on *nix at *nix speeds by
compiling it in this setup:
mingw
Cygwin
Wine
*nix
;-)

We could also try a more ambitious setup of Windows Platform SDK in place
of mingw there, but how well it works on Wine is an open question.

Damjan

On Thu, Jan 10, 2019 at 6:24 PM Pedro Giffuni  wrote:

> Hi again;
>
> I just wanted to stop by and share some ideas of things that need to be
> done in AOO after 4.2.
>
> Easier things:
>
> OpenSSL has to be updated, yet again, and while the future versions will
> be under an Apache License, making things nicer for us, the API has been
> changing so we may need some adaptations to work with future versions.
>
> Python 3: our compiler toolchain for MS-Windows is ancient enough that
> it is difficult to update internally to a recent Python 3 version. We
> have been supporting python 3 through external packages: configuring the
> AOO to build with Python 3 worked but, as found be FreeBSD's builds, it
> recently broke. I don't have more details this needs more investigation
> (and fixing).
>
> And now the tougher thing:
>
> I absolutely appreciate the huge effort Damjan has been doing with the
> build system: getting rid of Dmake is a viable objective that needs to
> be pushed forward.
>
> I have been playing a bit with clang-cl, which appears to be the only
> opensource compiler that can work with native windows binaries: it
> integrates into MS-Visual Studio but it requires CMake. I also happen to
> have met a developer of the Bazel build system which seems interesting
> and would suit our purposes in many ways but I have no interest in
> having long discussions about build systems. The central thing that we
> *have* to do is update the windows toolchain: MSVisual Studio 2015 seems
> to be the minimum that is suficiently popular and basically required
> nowadays.
>
> After that, there is a huge technical debt. Of course, pivot charts,
> newer ODF and better docx support would be very nice to have but without
> the proper tooling, especially on Windows, we have one hand tied.
>
> All just my 0.02$.
>
> Pedro.
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Future development discussion

[Pedro Giffuni]

Hi again;

I just wanted to stop by and share some ideas of things that need to be 
done in AOO after 4.2.


Easier things:

OpenSSL has to be updated, yet again, and while the future versions will 
be under an Apache License, making things nicer for us, the API has been 
changing so we may need some adaptations to work with future versions.


Python 3: our compiler toolchain for MS-Windows is ancient enough that 
it is difficult to update internally to a recent Python 3 version. We 
have been supporting python 3 through external packages: configuring the 
AOO to build with Python 3 worked but, as found be FreeBSD's builds, it 
recently broke. I don't have more details this needs more investigation 
(and fixing).


And now the tougher thing:

I absolutely appreciate the huge effort Damjan has been doing with the 
build system: getting rid of Dmake is a viable objective that needs to 
be pushed forward.


I have been playing a bit with clang-cl, which appears to be the only 
opensource compiler that can work with native windows binaries: it 
integrates into MS-Visual Studio but it requires CMake. I also happen to 
have met a developer of the Bazel build system which seems interesting 
and would suit our purposes in many ways but I have no interest in 
having long discussions about build systems. The central thing that we 
*have* to do is update the windows toolchain: MSVisual Studio 2015 seems 
to be the minimum that is suficiently popular and basically required 
nowadays.


After that, there is a huge technical debt. Of course, pivot charts, 
newer ODF and better docx support would be very nice to have but without 
the proper tooling, especially on Windows, we have one hand tied.


All just my 0.02$.

Pedro.



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

Re: AOO 4.2.x development branch created

[Pedro Giffuni]

Hey guys!

Thank you to everyone getting involved in the new release. It is very 
much needed and I was really tired of the continuous revamping of the 
4.1 releases. It is now clear that we are also doing proper branching of 
the releases.


Some of the issues off the top of my head that you may want to mention 
on the Release Notes:


- All the fonts have been updated. We also added two fonts Caladea and 
Carlito which are geometrically compatible to Microsoft Cambria and 
Calibre.


- Python was updated to 2.7.15. Hunspell was updated to 1.3.3.

- Cleanups for many, many typos everywhere.

- Fixed many issues detected by Coverity scan.

There are many more changes that I surely forgot about.

Pedro.

Re: AOO 4.2.x development branch created

[Mechtilde]

Hello

Am 09.01.19 um 21:21 schrieb Marcus:
> Am 09.01.19 um 20:25 schrieb Mechtilde:
>> thanks for the branch.
>>
>> How do we handle the translation I think we should do the translation on
>> AOOO42X so we only tranlate for the next release.
> 
> IMHO yes. But updates need to be done in the 4.2.x branches directly and
> should not come from Pootle anymore.
> 
> As soon as it's clear that the 4.2.X release branch is done and found
> it's end, new translations for the new 4.3.x branch should then come
> again from Pootle.
> 
> At least this is my understanding.

We can do the translation for 42x in Pootle as long as I do not merge a
template from trunk.

For creating the SDF-file I must use the template file which the
translation based on.

https://wiki.openoffice.org/wiki/Translation_from_4.2

I see no problem to do more translation in Pootle.
> 
> Marcus
> 

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



signature.asc
Description: OpenPGP digital signature

Re: AOO 4.2.x development branch created

[Jim Jagielski]

> On Jan 9, 2019, at 3:46 PM, Jim Jagielski  wrote:
> 
> Ahh... something w/ the cppuhelper stuff. Obviously, some UDK issue I'm 
> thinking...
> 

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

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


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

Re: AOO 4.2.x development branch created

[Jim Jagielski]

Ahh... something w/ the cppuhelper stuff. Obviously, some UDK issue I'm 
thinking...

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


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

Re: AOO 4.2.x development branch created

[Jim Jagielski]

Request for help...

Any ideas would be helpful:

% build --all:instsetoo_native
build -- version: 1775979


=
Building module instsetoo_native
=

Entering 
/Users/jim/src/asf/AOO42X/main/instsetoo_native/inc_openoffice/windows/msi_languages


Entering /Users/jim/src/asf/AOO42X/main/instsetoo_native/inc_openoffice/unix


Entering /Users/jim/src/asf/AOO42X/main/instsetoo_native/util

... checking environment variables ...


make_installer.pl, version 1.0
Product list file: ../util/openoffice.lst
Taking setup script from solver
Unpackpath: /Users/jim/src/asf/AOO42X/main/instsetoo_native/util/../unxmaccx.pro
Compiler: unxmaccx
Product: Apache_OpenOffice
BuildID: 9800
Build: AOO420
No minor set
Product version
Using default installpath
Package format: dmg
msi templatepath: 
/Users/jim/src/asf/AOO42X/main/instsetoo_native/util/../unxmaccx.pro/misc/openoffice/msi_templates
msi template path will be ignored for non Windows builds!
msi languagepath: 
/Users/jim/src/asf/AOO42X/main/instsetoo_native/util/../unxmaccx.pro/misc/win_ulffiles
msi language path will be ignored for non Windows builds!
Calling epm
Stripping files
Unzip ARCHIVE files
Languages: en-US

... checking required files ...
.. searching zip ...
Found: /usr/bin/zip
... analyzing ../util/openoffice.lst ... 
... reading include paths ...
... analyzing script: 
/Users/jim/src/asf/AOO42X/main/solver/420/unxmaccx.pro/bin/setup_osl.ins ... 
... analyzing script: 
/Users/jim/src/asf/AOO42X/main/solver/420/unxmaccx.pro/bin/setup_osl.ins ... 
WARNING: mis-named or un-known %-variable in setup script at line 32927:
Description (kab) = "\u1e6c\u1e6def til\u0263uyin tiwurmanin mi ara 
yewjed umucce\u1e0d amaynut n %PRODUCTNAM.";
... analyzing directories ... 
... analyzing files ... 
... analyzing scpactions ... 
... analyzing shortcuts ... 
... analyzing unix links ... 
... analyzing profile ... 
... analyzing profileitems ... 
... analyzing modules ... 

... languages en-US ... 
... analyzing files ...
preparing 1 extension blob for language en-US:
dict-en.oxt
preparing 0 bundled extensions for language en-US:
... analyzing files with flag ARCHIVE ...
... analyzing files with flag SUBST_FILENAME ...
... analyzing files with flag SCPZIP_REPLACE ...
... analyzing files with flag PATCH_SO_NAME ...
... analyzing files with flag HIDDEN ...
... analyzing all directories for this product ...
... analyzing links ...
... analyzing unix links ...
... creating profiles ...
... analyzing modules ...
... creating installation directory ...
... creating installation set in 
/Users/jim/src/asf/AOO42X/main/instsetoo_native/unxmaccx.pro/Apache_OpenOffice/dmg/install/en-US
 ...
... removing old installation directories ...
... creating directories ...
... copying files ...
... creating links ...
remove_empty_dirs_in_folder 
/Users/jim/src/asf/AOO42X/main/instsetoo_native/unxmaccx.pro/Apache_OpenOffice/dmg/install/en-US_inprogress/Apache_OpenOffice_4.2.0_MacOS_x86-64_install_en-US/OpenOffice.app/Contents/share/extensions/install
remove_empty_dirs_in_folder 
/Users/jim/src/asf/AOO42X/main/instsetoo_native/unxmaccx.pro/Apache_OpenOffice/dmg/install/en-US_inprogress/Apache_OpenOffice_4.2.0_MacOS_x86-64_install_en-US/OpenOffice.app/Contents/share/extensions
... current dir: 
/Users/jim/src/asf/AOO42X/main/instsetoo_native/unxmaccx.pro/Apache_OpenOffice/dmg/install/en-US_inprogress/Apache_OpenOffice_4.2.0_MacOS_x86-64_install_en-US/OpenOffice.app/Contents/MacOS
 ...
... 
/Users/jim/src/asf/AOO42X/main/instsetoo_native/unxmaccx.pro/Apache_OpenOffice/dmg/install/en-US_inprogress/Apache_OpenOffice_4.2.0_MacOS_x86-64_install_en-US/OpenOffice.app/Contents/program/unopkg
 sync --verbose -env:UNO_JAVA_JFW_ENV_JREHOME=true 2>&1 | ...
... cleaning the output tree ...
... removing directory 
/var/folders/_p/nx0kp5h157197n6ssf35ft7hgn/T/ooopackaging/i_519031547065879 
...
... removing directory 
/Users/jim/src/asf/AOO42X/main/instsetoo_native/unxmaccx.pro/Apache_OpenOffice/dmg/stripped/en-US
 ...
Error: ERROR: 
/Users/jim/src/asf/AOO42X/main/instsetoo_native/unxmaccx.pro/Apache_OpenOffice/dmg/install/en-US_inprogress/Apache_OpenOffice_4.2.0_MacOS_x86-64_install_en-US/OpenOffice.app/Contents/program/unopkg
 sync --verbose -env:UNO_JAVA_JFW_ENV_JREHOME=true 2>&1 | failed!

**
ERROR: ERROR: 
/Users/jim/src/asf/AOO42X/main/instsetoo_native/unxmaccx.pro/Apache_OpenOffice/dmg/install/en-US_inprogress/Apache_OpenOffice_4.2.0_MacOS_x86-64_install_en-US/OpenOffice.app/Contents/program/unopkg
 sync --verbose -env:UNO_JAVA_JFW_ENV_JREHOME=true 2>&1 | failed!
in function: register_extensions
**
in function: register_extensionsstopping log at Wed Jan  9 15:32:36 2019
dmake:  Error code 255, while making 

Re: AOO 4.2.x development branch created

[Marcus]

Am 09.01.19 um 21:20 schrieb Matthias Seidel:

Am 09.01.19 um 21:12 schrieb Marcus:

Am 09.01.19 um 20:44 schrieb Matthias Seidel:

There is more than minor.mk.

I will try to take care of it...


hm, don't we have now a little script for this? To identify all the
places that need tobe changed? IMHO it should be somewhere in devtools.


Yes, works for micro releases, we used it for the last release:
http://svn.apache.org/repos/asf/openoffice/devtools/updateVersion/

But for a jump in version number there is more to do (according to this
issue):
https://bz.apache.org/ooo/show_bug.cgi?id=119977


OK, then it should be possible to extend it, so that it can be used for 
minor and major releases also.


Marcus




Am 09.01.19 um 20:41 schrieb Jim Jagielski:

All done


On Jan 9, 2019, at 2:21 PM, Matthias Seidel
 wrote:

9800



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

Re: AOO 4.2.x development branch created

[Marcus]

Am 09.01.19 um 20:25 schrieb Mechtilde:

thanks for the branch.

How do we handle the translation I think we should do the translation on
AOOO42X so we only tranlate for the next release.


IMHO yes. But updates need to be done in the 4.2.x branches directly and 
should not come from Pootle anymore.


As soon as it's clear that the 4.2.X release branch is done and found 
it's end, new translations for the new 4.3.x branch should then come 
again from Pootle.


At least this is my understanding.

Marcus




Am 09.01.19 um 20:10 schrieb Jim Jagielski:




On Jan 9, 2019, at 1:37 PM, Matthias Seidel  wrote:

Hi Jim,

Am 09.01.19 um 18:40 schrieb Jim Jagielski:

Trunk has been branched off to the (eventual) release branch
for the AOO 4.2.x series. The branch is:

https://svn.apache.org/repos/asf/openoffice/branches/AOO42X


Great, but why is it called 42X? Wouldn't 420 be better?


The reason is that when it's time to release 4.2.0, we work on 42X until we 
have it ready. once done, we then tag AOO420 from 42X. That is, the 42X branch 
will always be the eventual branch for a 4.2.x release. All backports from 
trunk are done to that branch.

Make sense?



The reason I ask is because I wanted to adjust the links for the update
feed...



Development can, and should, continue on trunk, but ONLY
approved backports should be applied to AOO42X.


Now trunk (aka 420) needs a new internal version number.
What about 450?



Works for me :)



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

Re: AOO 4.2.x development branch created

[Matthias Seidel]

Hi Marcus,

Am 09.01.19 um 21:12 schrieb Marcus:
> Am 09.01.19 um 20:44 schrieb Matthias Seidel:
>> There is more than minor.mk.
>>
>> I will try to take care of it...
>
> hm, don't we have now a little script for this? To identify all the
> places that need tobe changed? IMHO it should be somewhere in devtools.

Yes, works for micro releases, we used it for the last release:
http://svn.apache.org/repos/asf/openoffice/devtools/updateVersion/

But for a jump in version number there is more to do (according to this
issue):
https://bz.apache.org/ooo/show_bug.cgi?id=119977

Regards,

   Matthias

>
> Marcus
>
>
>
>> Am 09.01.19 um 20:41 schrieb Jim Jagielski:
>>> All done
>>>
 On Jan 9, 2019, at 2:21 PM, Matthias Seidel
  wrote:

 9800
>
> -
> 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.x development branch created

[Jim Jagielski]

If so, I don't know of it.

Agreed that such a beastie should exist.

> On Jan 9, 2019, at 3:12 PM, Marcus  wrote:
> 
> Am 09.01.19 um 20:44 schrieb Matthias Seidel:
>> There is more than minor.mk.
>> I will try to take care of it...
> 
> hm, don't we have now a little script for this? To identify all the places 
> that need tobe changed? IMHO it should be somewhere in devtools.
> 
> Marcus
> 
> 
> 
>> Am 09.01.19 um 20:41 schrieb Jim Jagielski:
>>> All done
>>> 
 On Jan 9, 2019, at 2:21 PM, Matthias Seidel  
 wrote:
 
 9800
> 
> -
> 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: AOO 4.2.x development branch created

[Marcus]

Am 09.01.19 um 20:44 schrieb Matthias Seidel:

There is more than minor.mk.

I will try to take care of it...


hm, don't we have now a little script for this? To identify all the 
places that need tobe changed? IMHO it should be somewhere in devtools.


Marcus




Am 09.01.19 um 20:41 schrieb Jim Jagielski:

All done


On Jan 9, 2019, at 2:21 PM, Matthias Seidel  wrote:

9800


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

Re: AOO 4.2.x development branch created

[Matthias Seidel]

There is more than minor.mk.

I will try to take care of it...

Am 09.01.19 um 20:41 schrieb Jim Jagielski:
> All done
>
>> On Jan 9, 2019, at 2:21 PM, Matthias Seidel  
>> wrote:
>>
>> 9800
>



smime.p7s
Description: S/MIME Cryptographic Signature

Re: AOO 4.2.x development branch created

[Jim Jagielski]

All done

> On Jan 9, 2019, at 2:21 PM, Matthias Seidel  
> wrote:
> 
> 9800

Re: AOO 4.2.x development branch created

[Mechtilde]

Hello,

thanks for the branch.

How do we handle the translation I think we should do the translation on
AOOO42X so we only tranlate for the next release.

Make sense?

Regards
Mechtilde

Am 09.01.19 um 20:10 schrieb Jim Jagielski:
> 
> 
>> On Jan 9, 2019, at 1:37 PM, Matthias Seidel  
>> wrote:
>>
>> Hi Jim,
>>
>> Am 09.01.19 um 18:40 schrieb Jim Jagielski:
>>> Trunk has been branched off to the (eventual) release branch
>>> for the AOO 4.2.x series. The branch is:
>>>
>>>https://svn.apache.org/repos/asf/openoffice/branches/AOO42X
>>
>> Great, but why is it called 42X? Wouldn't 420 be better?
> 
> The reason is that when it's time to release 4.2.0, we work on 42X until we 
> have it ready. once done, we then tag AOO420 from 42X. That is, the 42X 
> branch will always be the eventual branch for a 4.2.x release. All backports 
> from trunk are done to that branch.
> 
> Make sense?
> 
>>
>> The reason I ask is because I wanted to adjust the links for the update
>> feed...
>>
>>>
>>> Development can, and should, continue on trunk, but ONLY
>>> approved backports should be applied to AOO42X.
>>
>> Now trunk (aka 420) needs a new internal version number.
>> What about 450?
>>
> 
> Works for me :)
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
> 

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



signature.asc
Description: OpenPGP digital signature

setting up build environmant (was:AOO 4.2.x development branch created)

[Peter Kovacs]

Hello Vittal Sher,

Better is to write what you want in the subject.

generic guide you find here:

https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO

Different Distributions and Windows:

https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Step_by_step


All the Best

Peter

On 09.01.19 19:37, sher.vittal wrote:
> Hi All,
>
> Greetings!
> I’m a hobbyist, after looking at the build issue mails since long time, I 
> have finally ready to contribute to AOO. I have been in the Information 
> Technology since 15 to 16 years. I have seen windows since 3.0 and work on 
> Debian/FreeBSD and also have exposure to couple of other Unix/Linux OS’s. I 
> personally feel that I can contribute to the AOO community. I use AOO on my 
> personal home laptop and desktop(s).
>
> I would need a guide/doc to start setting up the build environment on any 
> Linux / Windows.
>
> Regards
> Vittal Sher
>
> From: Jim Jagielski
> Sent: Wednesday, January 9, 2019 11:10 PM
> To: OOo Apache
> Subject: AOO 4.2.x development branch created
>
> Trunk has been branched off to the (eventual) release branch
> for the AOO 4.2.x series. The branch is:
>
> https://svn.apache.org/repos/asf/openoffice/branches/AOO42X
>
> Development can, and should, continue on trunk, but ONLY
> approved backports should be applied to AOO42X.
>
> Cheers!
>
> -
> 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: AOO 4.2.x development branch created

[Matthias Seidel]

Am 09.01.19 um 20:10 schrieb Jim Jagielski:
>
>> On Jan 9, 2019, at 1:37 PM, Matthias Seidel  
>> wrote:
>>
>> Hi Jim,
>>
>> Am 09.01.19 um 18:40 schrieb Jim Jagielski:
>>> Trunk has been branched off to the (eventual) release branch
>>> for the AOO 4.2.x series. The branch is:
>>>
>>>https://svn.apache.org/repos/asf/openoffice/branches/AOO42X
>> Great, but why is it called 42X? Wouldn't 420 be better?
> The reason is that when it's time to release 4.2.0, we work on 42X until we 
> have it ready. once done, we then tag AOO420 from 42X. That is, the 42X 
> branch will always be the eventual branch for a 4.2.x release. All backports 
> from trunk are done to that branch.
>
> Make sense?

Not really (for me).

But I am sure there are others that have an opinion...

>
>> The reason I ask is because I wanted to adjust the links for the update
>> feed...
>>
>>> Development can, and should, continue on trunk, but ONLY
>>> approved backports should be applied to AOO42X.
>> Now trunk (aka 420) needs a new internal version number.
>> What about 450?
>>
> Works for me :)

At the moment we have two different branches with the same version
number (AOO420m1(Build:9800)).

We should fix that asap.

Regards,

   Matthias

>
>
> -
> 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.x development branch created

[Peter Kovacs]

+1 to this plan.

On 09.01.19 20:10, Jim Jagielski wrote:
>
>> On Jan 9, 2019, at 1:37 PM, Matthias Seidel  
>> wrote:
>>
>> Hi Jim,
>>
>> Am 09.01.19 um 18:40 schrieb Jim Jagielski:
>>> Trunk has been branched off to the (eventual) release branch
>>> for the AOO 4.2.x series. The branch is:
>>>
>>>https://svn.apache.org/repos/asf/openoffice/branches/AOO42X
>> Great, but why is it called 42X? Wouldn't 420 be better?
> The reason is that when it's time to release 4.2.0, we work on 42X until we 
> have it ready. once done, we then tag AOO420 from 42X. That is, the 42X 
> branch will always be the eventual branch for a 4.2.x release. All backports 
> from trunk are done to that branch.
>
> Make sense?
>
>> The reason I ask is because I wanted to adjust the links for the update
>> feed...
>>
>>> Development can, and should, continue on trunk, but ONLY
>>> approved backports should be applied to AOO42X.
>> Now trunk (aka 420) needs a new internal version number.
>> What about 450?
>>
> Works for me :)
>
>
> -
> 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: AOO 4.2.x development branch created

[Jim Jagielski]

> On Jan 9, 2019, at 1:37 PM, Matthias Seidel  
> wrote:
> 
> Hi Jim,
> 
> Am 09.01.19 um 18:40 schrieb Jim Jagielski:
>> Trunk has been branched off to the (eventual) release branch
>> for the AOO 4.2.x series. The branch is:
>> 
>>https://svn.apache.org/repos/asf/openoffice/branches/AOO42X
> 
> Great, but why is it called 42X? Wouldn't 420 be better?

The reason is that when it's time to release 4.2.0, we work on 42X until we 
have it ready. once done, we then tag AOO420 from 42X. That is, the 42X branch 
will always be the eventual branch for a 4.2.x release. All backports from 
trunk are done to that branch.

Make sense?

> 
> The reason I ask is because I wanted to adjust the links for the update
> feed...
> 
>> 
>> Development can, and should, continue on trunk, but ONLY
>> approved backports should be applied to AOO42X.
> 
> Now trunk (aka 420) needs a new internal version number.
> What about 450?
> 

Works for me :)


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

Re: AOO 4.2.x development branch created

[Matthias Seidel]

Hi Jim,

Am 09.01.19 um 18:40 schrieb Jim Jagielski:
> Trunk has been branched off to the (eventual) release branch
> for the AOO 4.2.x series. The branch is:
>
> https://svn.apache.org/repos/asf/openoffice/branches/AOO42X

Great, but why is it called 42X? Wouldn't 420 be better?

The reason I ask is because I wanted to adjust the links for the update
feed...

>
> Development can, and should, continue on trunk, but ONLY
> approved backports should be applied to AOO42X.

Now trunk (aka 420) needs a new internal version number.
What about 450?

Regards,

   Matthias

>
> Cheers!
>
> -
> 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.x development branch created

[sher . vittal]

Hi All,

Greetings!
I’m a hobbyist, after looking at the build issue mails since long time, I have 
finally ready to contribute to AOO. I have been in the Information Technology 
since 15 to 16 years. I have seen windows since 3.0 and work on Debian/FreeBSD 
and also have exposure to couple of other Unix/Linux OS’s. I personally feel 
that I can contribute to the AOO community. I use AOO on my personal home 
laptop and desktop(s).

I would need a guide/doc to start setting up the build environment on any Linux 
/ Windows.

Regards
Vittal Sher

From: Jim Jagielski
Sent: Wednesday, January 9, 2019 11:10 PM
To: OOo Apache
Subject: AOO 4.2.x development branch created

Trunk has been branched off to the (eventual) release branch
for the AOO 4.2.x series. The branch is:

https://svn.apache.org/repos/asf/openoffice/branches/AOO42X

Development can, and should, continue on trunk, but ONLY
approved backports should be applied to AOO42X.

Cheers!

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

AOO 4.2.x development branch created

[Jim Jagielski]

Trunk has been branched off to the (eventual) release branch
for the AOO 4.2.x series. The branch is:

https://svn.apache.org/repos/asf/openoffice/branches/AOO42X

Development can, and should, continue on trunk, but ONLY
approved backports should be applied to AOO42X.

Cheers!

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

Survey on Interaction Design in Distributed Software Development

[Daniel Domingos]

Dear,

We would like to invite you to participate in a survey on *interaction design
in distributed software development*.

The purpose of this survey is to identify the perception of people involved
in design or software development with geographically distributed teams on
interaction design and to verify how interaction design has been conducted
in Distributed Software Development (DSD) projects.

If you are currently participating or have already participated in design
or software development with geographically distributed teams, please give
your opinion in this survey.

*The survey takes an average of 10 (ten) minutes to be answered and is
available at: https://interactiondesign.limequery.com/366376?lang=en
<https://interactiondesign.limequery.com/366376?lang=en>*

Your participation is very important to the success of this study!

*If possible, please help us to spread this survey **in the company where
you work.*

Thank you in advance for taking the time to complete the survey.


Daniel Alves and Ecivaldo Matos.

--
Daniel Domingos Alves
PhD student in computer science at the Federal University of Bahia (UFBA)
Member of the Onda Digital Research and Extension Group
Professor at the Federal Institute of Mato Grosso (IFMT)
Lattes: http://lattes.cnpq.br/1948646331395064
Salvador, Bahia, Brazil.

[Survey] Identification of People Involved in Design or Software Development with Geographically Distributed Teams

[Daniel Domingos]

Dear,

We would like to invite you to participate in a study on interaction design
in distributed software development.

At first, we are identifying people who are currently participating or who
have already participated in design or software development with
geographically distributed teams.

If you are currently participating or have already participated in design
or software development with geographically distributed teams, please give
your opinion in this survey.

The survey has only 6 (six) questions and is available at:
https://interactiondesign.limequery.com/435494?lang=en

Your participation is very important to the success of this study!

If possible, please help us to spread this survey.

Thank you in advance for taking the time to complete the survey.


Daniel Alves and Ecivaldo Matos.

--
Daniel Domingos Alves
PhD student in computer science at the Federal University of Bahia (UFBA)
Member of the Onda Digital Research and Extension Group
Professor at the Federal Institute of Mato Grosso (IFMT)
Lattes: http://lattes.cnpq.br/1948646331395064
email: daniel.domin...@ufba.br

gbuild development update 2018-11

[Damjan Jovanovic]

Hi

Out of our 183 total modules, 94 are now in gbuild (51.37%).

That seems like a small number, given the amount of time it has taken to
get there. Right?

Well, of the remaining modules, 37 of them (another 20.22% of total) are
"externals" (zlib, jpeg, etc.) which we merely unzip and patch with dmake,
but then chain-build with their own build systems. It is relatively easy to
port the unzipping/patching logic to gbuild, but then there are many custom
actions in each module. Potentially, for modules that don't need patching,
we could also download binaries instead of patching and building from
source?

The rest are our own internal dmake modules, 52 of them (another 28.42% of
total), which build with dmake all the way, and which have to be converted
fully. From my perspective, the main challenges with those currently are:
* XCU and XHP files are somehow gathered and processed in many modules. The
dmake logic for this is complex.
* Perl scripts are called from many modules. It's not clear how to call
Perl from gbuild's declarative syntax.
* Windows is used in many modules, and the Windows build is the slowest and
most painful to work with.
* .NET tools are used in many modules, which I am unfamiliar with.
* ATL is required in some modules but seems like a huge mission to install.
* XSLT processing is done in many modules, which again requires calling out
to other tools somehow.
* Quite specialized custom build logic is found in a few modules, and it's
not clear whether to convert it to gbuild or how to deal with it. Do we
make gbuild scripts to build UNO extensions just to cater to main/mysqlc?
* Some dmake code is unused, but discovering that takes a while.
* Mac-only modules (apple_remote) need a Mac to test on.

On the bright side, even with so much left, we've come a long way. All the
"main" applications (writer, calc, impress, base) are in gbuild. Every type
of binary (eg. "unoverlibs" with "3" in their names and symbolic links to
those without the 3) is correctly built and delivered. Much of the tooling
and code generation, for example yacc and flex, has already been ported to
gbuild. Ant modules can open in Java IDEs, with all their dependencies, and
be compiled and tested from within the IDE, with even their IDL code
generation that involves having Ant call UNO tools in the shell, all
working, without "make" involved at all - an unprecedented development
[LibreOffice can only build Java modules with their gbuild, in the shell;
Java IDEs certainly can't parse gbuild's eval-filled non-deterministic
makefiles, so their Java development must be quite a pain ;)].

Today I even got gbuild to extract dependencies from Ant, and use them to
build Ant submodules in the correct order. We no longer need build.pl to
order building of Ant submodules, and in a similar way, eventually we won't
need it to order building of gbuild modules either.

Changing build systems is not the most exciting development possible, but a
bad build system is a barrier to entry for new developers and a pain for
existing ones, and the innovation and cleanups possible while changing to a
new one, all have benefits.

If anyone wants to help, let me know and I'll teach you how it's done.

Damjan

Re: accessibility development status question

[Pavel Vlček]

Yea thanks.

I have a small issue with Writer and Nvda screen reader. I will test, if 
it is only with .docx, doc and / or odt format and I'll create a issue. 
Problem is with reading documents with more than one page.


Pavel



Dne 01.07.2018 v 10:20 Peter Kovacs napsal(a):

Hi Pavel,

What do you mean by accessibility?

We have some bugs of accessibility request for

- internal features.

- Mousless Interface

- Speech recognition


In general we are currently focus maintain the code, meaning fixing 
errors. That does not mean someone is not looking into it, or has done 
something that brings you closer to your whish.


Please describe more closely what you mean, or point at a dedicated 
issue.



Thank you.


All the best

Peter


On 29.06.2018 10:51, Pavel Vlček wrote:

Dear devs,

is accessibility of Open Office in active development?

Thanks,

Pavel



-
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