Fwd: [ANNOUNCE] Apache OpenOffice 4.1.9 released
Hello OpenOffice community, today we want to share with you the announcement from below. Thank You to all who have helped to make this new release happen. Especially the Mac community will be happy again as they can use DOCX, XLSX; and PPTX document again. PS: The Apache Blog server is having an outage at the moment. So, please be patient as the usual announcement is not yet there. Marcus (on behalf of the Apache OpenOffice PMC) Weitergeleitete Nachricht Betreff: [ANNOUNCE] Apache OpenOffice 4.1.9 released Datum: Mon, 8 Feb 2021 00:33:33 +0100 Von: Marcus Antwort an: annou...@openoffice.apache.org An: annou...@openoffice.apache.org 07 February 2021 - Apache OpenOffice, the leading Open Source office document productivity suite, announced today Apache OpenOffice 4.1.9, now available in 41 languages on Windows, macOS and Linux. Apache OpenOffice 4.1.9 is a maintenance release aimed at correcting some regressions and delivering the latest English dictionary. All users of Apache OpenOffice 4.1.8 or earlier are advised to upgrade. For the complete overview see the list in Bugzilla: https://s.apache.org/AOO-419changes Full version of this announcement: https://s.apache.org/AOO-419announcement Apache OpenOffice 4.1.8 Release Notes: https://s.apache.org/AOO-419releasenotes Download Apache OpenOffice 4.1.9 from the original source only: https://www.openoffice.org/download/ Follow Apache OpenOffice: Twitter https://twitter.com/apacheoo Facebook https://www.facebook.com/ApacheOO YouTube https://www.youtube.com/openoffice Mail https://openoffice.apache.org/mailing-lists.html - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [openoffice] branch trunk updated: Update url_transfer.htm
Hi Mathias > On 02/07/2021 10:48 PM Matthias Seidel wrote: > This is the easiest way... ;-) Ok. I expected a point and click option would be available at the Github website... > Did you checkout from GitHub or from Gitbox? Thanks to this question I noticed that the Terminal prompt was asking for the Gitbox credentials and I was typing the Github credentials :) > If Gitbox, you need to use your ASF credentials. Yes... I only figured that out now :) Thank you again for teaching me to fish ;) Regards, Pedro - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [openoffice] branch trunk updated: Update url_transfer.htm
Hi Mathias > I think this was your first commit with Git? Congratulations! I had done a previous one but it was for the website. > This seems to be safe to be "cherry-picked" from trunk for AOO42X: > > git checkout AOO42X > git pull > git cherry-pick -x 5215491 > git push origin AOO42X Unfortunately that doesn't work... It won't accept my password which I know is correct. I think it's because I enabled 2 Factor Authentication to be able to commit in Github... Is there a way to cherry pick in Github??? I can simply switch branches and do the same modification on the 42x branch but I'm sure there has to be an easier way (for people who modify multiple lines of code)? Regards, Pedro - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: How to cope with duplicate attributes in XML tags
On 2/7/2021 10:22 AM, Arrigo Marchiori wrote: > Hello all, > > re-replying to Jim's message. > > On Wed, Feb 03, 2021 at 02:25:16PM -0500, Jim Jagielski wrote: > >> Funny that you bring this up... I'm been tracking down some bugs and they >> all seem to be XML related... fastsax->libwriterfilter with occasional cores >> due to __cxa_call_unexpected. >> >> I feel that making AOO more fragile by trying to work around cases where >> invalid and/or non-compliant XML is encountered is just wrong. We should >> either ignore the error (catch it) or raise an exception. Invalid data >> shouldn't >> be tolerated. Additionally, trying to be "lenient" is an easy vector for >> vulnerabilities. > > For the record: the detection of duplicated attributes is made > internally by the expat library. Our code just receives the error > message and cannot do anything to recover it. > > I don't believe it's worth patching expat to allow duplicated > attributes. I don't know the library well and I fear about the > consequences of tinkering with it. > > But then my question becomes: do we want to offer any data recovery > tools for corrupted documents? Like ``dumb'' XML parsers that just > shave away XML errors? > > 1- it could be an external tool, written in a language that is easier > to code into? (like Python, Perl, Java... whatever) > > 2- or an internal pre-parsing phase? It should not be based on the > expat library though; do we have any other possibilities among the > current modules? > > 3- or we leave it to hand-crafting by knowledgeable people on the > forum, as it is happening now? > > I am looking forward to opinions ... and possibily reviews of PR 122 > please ;-) > > Best regards, > Purely from a users point of view I agree with Jim. It should not be allowed to happen. Asking the user to run an external program, our to send it to the forum to be hand edit is a recipe for disaster to our user base and from a marketing standpoint. I could see an external program as a short term, stop gap work around. However it should only be that. Regards Keith signature.asc Description: OpenPGP digital signature
Re: How to cope with duplicate attributes in XML tags
Hello Peter, and thank you for taking time to reply. On Sun, Feb 07, 2021 at 04:58:19PM +0100, Peter Kovacs wrote: > Hello, > > On 07.02.21 16:22, Arrigo Marchiori wrote: > > Hello all, > > > > re-replying to Jim's message. > > > > On Wed, Feb 03, 2021 at 02:25:16PM -0500, Jim Jagielski wrote: > > > > > Funny that you bring this up... I'm been tracking down some bugs and they > > > all seem to be XML related... fastsax->libwriterfilter with occasional > > > cores > > > due to __cxa_call_unexpected. > > > > > > I feel that making AOO more fragile by trying to work around cases where > > > invalid and/or non-compliant XML is encountered is just wrong. We should > > > either ignore the error (catch it) or raise an exception. Invalid data > > > shouldn't > > > be tolerated. Additionally, trying to be "lenient" is an easy vector for > > > vulnerabilities. > > For the record: the detection of duplicated attributes is made > > internally by the expat library. Our code just receives the error > > message and cannot do anything to recover it. > > I think it is not an issue of expat itself. It is an issue of how expat is > setup. > > From the pure xml lore you can allow multiple elements of the same name. > > consider unordered HTML List, as a reference. I may have explained myself wrong... I am not talking about duplicated _elements_ but rather duplicated _attributes_. To remain in your example, the problem is not having multiple elements, but rather something like: [...] > We could provide a helper to help the user to figure out what has happened > maybe. By "helper" do you mean a separate program or a function inside AOO? [..] > > I am looking forward to opinions ... and possibily reviews of PR 122 > > please ;-) > I plan to have a look! Many thanks! If we approve it, I will surely need your indication (as per a previous thread on this ML) about the next "high priority issue" to address. Best regards, -- Arrigo http://rigo.altervista.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [openoffice] branch trunk updated: Update url_transfer.htm
Hi Pedro, I think this was your first commit with Git? Congratulations! This seems to be safe to be "cherry-picked" from trunk for AOO42X: git checkout AOO42X git pull git cherry-pick -x 5215491 git push origin AOO42X Regards, Matthias Am 05.02.21 um 00:02 schrieb pl...@apache.org: > This is an automated email from the ASF dual-hosted git repository. > > plino pushed a commit to branch trunk > in repository https://gitbox.apache.org/repos/asf/openoffice.git > > > The following commit(s) were added to refs/heads/trunk by this push: > new 5215491 Update url_transfer.htm > 5215491 is described below > > commit 52154912a3595e2eb122f2f07e9469c9134fc1ff > Author: Pedro Lino <34394465+pedl...@users.noreply.github.com> > AuthorDate: Thu Feb 4 23:01:36 2021 + > > Update url_transfer.htm > --- > main/extras/source/templates/wizard/desktop/lang/pt/url_transfer.htm | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git > a/main/extras/source/templates/wizard/desktop/lang/pt/url_transfer.htm > b/main/extras/source/templates/wizard/desktop/lang/pt/url_transfer.htm > index b30d1e3..0970434 100644 > --- a/main/extras/source/templates/wizard/desktop/lang/pt/url_transfer.htm > +++ b/main/extras/source/templates/wizard/desktop/lang/pt/url_transfer.htm > @@ -70,7 +70,7 @@ > >FACE="Arial, sans-serif">Seleccione o > URL que aparece na > linha de entrada do URL, por exemplo: > - HREF="https://www.openoffice.org;>https://www.openoffice.org). > + HREF="https://www.openoffice.org;>https://www.openoffice.org. > > > > > smime.p7s Description: S/MIME Cryptographic Signature
Re: [PROPOSAL] add an unsubscribe/help footer to recruitment ML
+1 On Sun, Feb 7, 2021 at 9:29 PM Peter Kovacs wrote: > For me, too. 'Thanks a lot Carl. > > On 07.02.21 16:41, Marcus wrote: > > Am 07.02.21 um 16:36 schrieb Carl Marcum: > >> The unsubscribe and help footer has been added to recruitment@ list. > > > > ... and it's working for me. > > > > Thanks > > > > Marcus > > > >> On 1/25/21 6:45 PM, Carl Marcum wrote: > >>> On 1/19/21 12:23 PM, Marcus wrote: > Am 19.01.21 um 01:08 schrieb Carl Marcum: > > On 1/17/21 3:41 PM, Andrea Pescetti wrote: > >> On 10/01/2021 Peter Kovacs wrote: > >>> On 10.01.21 23:42, Andrea Pescetti wrote: > But we should also be more proactive and remove people when > they ask for it on the list: Whimsy https://whimsy.apache.org/ > ... > >>> The moderators are Patricia, Andrea and Marcus. > >> > >> I confirm that indeed I use Whimsy to help people unsubscribe the > >> recruitment list when their intention is clear and when they are > >> confused about how to do it. I hope the new footer will help > >> limit these cases. > >> > > So should I go ahead with this if we are renaming the list? > > I don't to create work for infra if it's not needed. > > I haven't seen any objection since days, so I would assume that a) > renaming the mailing list and b) adding a footer is OK. > > Please go ahead. :-) > > Marcus > > >>> I put in a ticket for the footer [1]. > >>> > >>> The rename I'll let someone else submit. > >>> > >>> [1] https://issues.apache.org/jira/browse/INFRA-21343 > > > > > > - > > 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: [PROPOSAL] add an unsubscribe/help footer to recruitment ML
For me, too. 'Thanks a lot Carl. On 07.02.21 16:41, Marcus wrote: Am 07.02.21 um 16:36 schrieb Carl Marcum: The unsubscribe and help footer has been added to recruitment@ list. ... and it's working for me. Thanks Marcus On 1/25/21 6:45 PM, Carl Marcum wrote: On 1/19/21 12:23 PM, Marcus wrote: Am 19.01.21 um 01:08 schrieb Carl Marcum: On 1/17/21 3:41 PM, Andrea Pescetti wrote: On 10/01/2021 Peter Kovacs wrote: On 10.01.21 23:42, Andrea Pescetti wrote: But we should also be more proactive and remove people when they ask for it on the list: Whimsy https://whimsy.apache.org/ ... The moderators are Patricia, Andrea and Marcus. I confirm that indeed I use Whimsy to help people unsubscribe the recruitment list when their intention is clear and when they are confused about how to do it. I hope the new footer will help limit these cases. So should I go ahead with this if we are renaming the list? I don't to create work for infra if it's not needed. I haven't seen any objection since days, so I would assume that a) renaming the mailing list and b) adding a footer is OK. Please go ahead. :-) Marcus I put in a ticket for the footer [1]. The rename I'll let someone else submit. [1] https://issues.apache.org/jira/browse/INFRA-21343 - 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: How to cope with duplicate attributes in XML tags
Hello, On 07.02.21 16:22, Arrigo Marchiori wrote: Hello all, re-replying to Jim's message. On Wed, Feb 03, 2021 at 02:25:16PM -0500, Jim Jagielski wrote: Funny that you bring this up... I'm been tracking down some bugs and they all seem to be XML related... fastsax->libwriterfilter with occasional cores due to __cxa_call_unexpected. I feel that making AOO more fragile by trying to work around cases where invalid and/or non-compliant XML is encountered is just wrong. We should either ignore the error (catch it) or raise an exception. Invalid data shouldn't be tolerated. Additionally, trying to be "lenient" is an easy vector for vulnerabilities. For the record: the detection of duplicated attributes is made internally by the expat library. Our code just receives the error message and cannot do anything to recover it. I think it is not an issue of expat itself. It is an issue of how expat is setup. From the pure xml lore you can allow multiple elements of the same name. consider unordered HTML List, as a reference. I would opt for checking if we could allow that this Element can be read as a duplicate. The user can then delete the entry he does not like, and fix therefore the document. We could provide a helper to help the user to figure out what has happened maybe. I don't believe it's worth patching expat to allow duplicated attributes. I don't know the library well and I fear about the consequences of tinkering with it. But then my question becomes: do we want to offer any data recovery tools for corrupted documents? Like ``dumb'' XML parsers that just shave away XML errors? 1- it could be an external tool, written in a language that is easier to code into? (like Python, Perl, Java... whatever) 2- or an internal pre-parsing phase? It should not be based on the expat library though; do we have any other possibilities among the current modules? 3- or we leave it to hand-crafting by knowledgeable people on the forum, as it is happening now? I am looking forward to opinions ... and possibily reviews of PR 122 please ;-) I plan to have a look! Best regards, -- 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: [PROPOSAL] add an unsubscribe/help footer to recruitment ML
Am 07.02.21 um 16:36 schrieb Carl Marcum: The unsubscribe and help footer has been added to recruitment@ list. ... and it's working for me. Thanks Marcus On 1/25/21 6:45 PM, Carl Marcum wrote: On 1/19/21 12:23 PM, Marcus wrote: Am 19.01.21 um 01:08 schrieb Carl Marcum: On 1/17/21 3:41 PM, Andrea Pescetti wrote: On 10/01/2021 Peter Kovacs wrote: On 10.01.21 23:42, Andrea Pescetti wrote: But we should also be more proactive and remove people when they ask for it on the list: Whimsy https://whimsy.apache.org/ ... The moderators are Patricia, Andrea and Marcus. I confirm that indeed I use Whimsy to help people unsubscribe the recruitment list when their intention is clear and when they are confused about how to do it. I hope the new footer will help limit these cases. So should I go ahead with this if we are renaming the list? I don't to create work for infra if it's not needed. I haven't seen any objection since days, so I would assume that a) renaming the mailing list and b) adding a footer is OK. Please go ahead. :-) Marcus I put in a ticket for the footer [1]. The rename I'll let someone else submit. [1] https://issues.apache.org/jira/browse/INFRA-21343 - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [PROPOSAL] add an unsubscribe/help footer to recruitment ML
Hi All, The unsubscribe and help footer has been added to recruitment@ list. Best regards, Carl On 1/25/21 6:45 PM, Carl Marcum wrote: On 1/19/21 12:23 PM, Marcus wrote: Am 19.01.21 um 01:08 schrieb Carl Marcum: On 1/17/21 3:41 PM, Andrea Pescetti wrote: On 10/01/2021 Peter Kovacs wrote: On 10.01.21 23:42, Andrea Pescetti wrote: But we should also be more proactive and remove people when they ask for it on the list: Whimsy https://whimsy.apache.org/ ... The moderators are Patricia, Andrea and Marcus. I confirm that indeed I use Whimsy to help people unsubscribe the recruitment list when their intention is clear and when they are confused about how to do it. I hope the new footer will help limit these cases. So should I go ahead with this if we are renaming the list? I don't to create work for infra if it's not needed. I haven't seen any objection since days, so I would assume that a) renaming the mailing list and b) adding a footer is OK. Please go ahead. :-) Marcus I put in a ticket for the footer [1]. The rename I'll let someone else submit. [1] https://issues.apache.org/jira/browse/INFRA-21343 Best regards, Carl - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: How to cope with duplicate attributes in XML tags
Hello all, re-replying to Jim's message. On Wed, Feb 03, 2021 at 02:25:16PM -0500, Jim Jagielski wrote: > Funny that you bring this up... I'm been tracking down some bugs and they > all seem to be XML related... fastsax->libwriterfilter with occasional cores > due to __cxa_call_unexpected. > > I feel that making AOO more fragile by trying to work around cases where > invalid and/or non-compliant XML is encountered is just wrong. We should > either ignore the error (catch it) or raise an exception. Invalid data > shouldn't > be tolerated. Additionally, trying to be "lenient" is an easy vector for > vulnerabilities. For the record: the detection of duplicated attributes is made internally by the expat library. Our code just receives the error message and cannot do anything to recover it. I don't believe it's worth patching expat to allow duplicated attributes. I don't know the library well and I fear about the consequences of tinkering with it. But then my question becomes: do we want to offer any data recovery tools for corrupted documents? Like ``dumb'' XML parsers that just shave away XML errors? 1- it could be an external tool, written in a language that is easier to code into? (like Python, Perl, Java... whatever) 2- or an internal pre-parsing phase? It should not be based on the expat library though; do we have any other possibilities among the current modules? 3- or we leave it to hand-crafting by knowledgeable people on the forum, as it is happening now? I am looking forward to opinions ... and possibily reviews of PR 122 please ;-) Best regards, -- Arrigo http://rigo.altervista.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
