Re: Change contact on Reference List
You haven't told us what list you mean but I found your name here: https://www.openoffice.org/de/marketing/referenzkunden.html Please write to this mailing list the details you want to see changed. Then we can change the data on the webpage. Thanks Marcus Am 08/30/2015 04:36 AM, schrieb David Sterr: I want to change my entry on the reference list (old company) - can you please tell me, who I have to contact for this matter? - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
New here
Hi everyone, My name is Prem Pandya, 26, I live in Niles, IL and Im an undergrad at DePaul University studying computer science. I'm eager to contribute to this open source project!
Re: 4.1.2_release_blocker requested: [Issue 126447] When using LanguageTools, toggling the checkbox check grammar in the spell checker removes content
On 08/30/2015 12:37 PM, Andrea Pescetti wrote: Kay Schenk wrote: I did not encounter problems building with patch version 2.6, so I never applied this patch. I'm rebuilding now to see if the patch works OK for me. More feedback later today. You surely meant the other thread/issue: https://bz.apache.org/ooo/show_bug.cgi?id=126258 and indeed the release notes I linked state that the behavior changed with GNU Patch 2.7. If we have confirmation that GNU Patch 2.6 still works (which I'm confident it does) with the patch, very good. We may want to note this in the issues. Regards, Andrea. oops! yes. :( -- MzK “The journey of a thousand miles begins with a single step.” --Lao Tzu - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Updating English dictionaries today?
On 30/08/2015 Marco A.G.Pinto wrote: Andrea, I was wondering if, since there are several release blockers around, if I could still be in time to update the English dictionaries to be used in AOO 4.1.2? Yes, no problem. As I wrote in the issue: https://bz.apache.org/ooo/show_bug.cgi?id=126454#c2 It will likely be updated again before releasing, but at the moment we have the latest available version. We had done 4 updates in trunk but none had been ported to AOO410, so I had to realign the two in order to make the next dictionary updates smoother. You can take your time and do the release with the needed care. We are surely in time a new dictionary update in the next weekend. When the new extension is ready, just clone https://bz.apache.org/ooo/show_bug.cgi?id=126454 (clone issue) and nominate it as blocker, and the new update will be applied. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: 4.1.2_release_blocker requested: [Issue 126447] When using LanguageTools, toggling the checkbox check grammar in the spell checker removes content
Am 08/30/2015 05:42 PM, schrieb Andrea Pescetti: On 06/08/2015 bugzilla wrote: Marcus has asked for 4.1.2_release_blocker: Issue 126447: When using LanguageTools, toggling the checkbox check grammar in the spell checker removes content https://bz.apache.org/ooo/show_bug.cgi?id=126447 This is committed to trunk, not yet to AOO410 (OpenOffice 4.1.2), but I plan to commit it if we have enough testing coverage. See issue for technical discussion. OK, thats fine. Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: 4.1.2_release_blocker requested: [Issue 126447] When using LanguageTools, toggling the checkbox check grammar in the spell checker removes content
On 08/30/2015 08:42 AM, Andrea Pescetti wrote: On 06/08/2015 bugzilla wrote: Marcus has asked for 4.1.2_release_blocker: Issue 126447: When using LanguageTools, toggling the checkbox check grammar in the spell checker removes content https://bz.apache.org/ooo/show_bug.cgi?id=126447 This is committed to trunk, not yet to AOO410 (OpenOffice 4.1.2), but I plan to commit it if we have enough testing coverage. See issue for technical discussion. Regards, Andrea. I did not encounter problems building with patch version 2.6, so I never applied this patch. I'm rebuilding now to see if the patch works OK for me. More feedback later today. -- MzK “The journey of a thousand miles begins with a single step.” --Lao Tzu - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: 4.1.2_release_blocker requested: [Issue 126447] When using LanguageTools, toggling the checkbox check grammar in the spell checker removes content
Kay Schenk wrote: I did not encounter problems building with patch version 2.6, so I never applied this patch. I'm rebuilding now to see if the patch works OK for me. More feedback later today. You surely meant the other thread/issue: https://bz.apache.org/ooo/show_bug.cgi?id=126258 and indeed the release notes I linked state that the behavior changed with GNU Patch 2.7. If we have confirmation that GNU Patch 2.6 still works (which I'm confident it does) with the patch, very good. We may want to note this in the issues. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [Issue 126454] Update English dictionary to version 2015.09.01
Andrea, Here is the e-mail to the dev list as I can't find the clone issue. I already uploaded 2015.09.01 today after we exchanged a few e-mails and I clicked in the download button and it seems to be working okay. :-P What more can be done? Thanks! Kind regards, Marco A.G.Pinto --- On 30/08/2015 18:58, bugzi...@apache.org wrote: https://bz.apache.org/ooo/show_bug.cgi?id=126454 --- Comment #7 from Andrea Pescetti pesce...@apache.org --- (In reply to marcoagpinto from comment #3) I have just uploaded version 2015-09-01. My update and your update simply overlapped, no problem. No need to rush the new update: just take your time to check and upload it (or recheck it if already uploaded), and then when ready clone this issue (do not reopen it; just clone it into a new one with clone issue) and we will proceed to another update. The important thing was to bring trunk and AOO410 in sync, and now they are aligned and it will be much easier to update again. [later...] Marco, we overlapped again. No, the right thing to do is not to change the issue title. Please leave this one as it is, and clone it into a new one. Ask me (on the dev list) to do so if you don't find the clone issue button. --
Re: Third-Party ALv2 Dependencies (RE: Limiting Trademark Policy Discussion ...)
I appreciate all your diligence about licenses. It is valuable. Whatever you want to call this thread ... One intention was to discuss what if anything is required with respect to trademarks when ANY third party product is (re)based on Apache OpenOffice. For example it cannot be called OpenOffice. If there are exceptions to this then these should be openly and explicitly acknowledged. I am not saying that there are any. You are missing the idea of creating a Powered By designation which is about trademark and not the license. If no one is interested then fine. If everyone is happy with the status quo so be it, but I don't think it is the case. Regards, Dave Sent from my iPhone On Aug 30, 2015, at 9:45 AM, Dennis E. Hamilton orc...@apache.org wrote: From the Chair, I need to speak up about the rebasing business. 1. Use of the ALv2 has nothing to do with trademarks, so this conversation should be on a separate thread. 2. However, it probably should not be held here and certainly not privately by the PMC. If someone wants to pursue it, I suggest these observations be checked with an authoritative source on a more-appropriate list, perhaps legal-discuss. Absent that, I request that this conversation not go any farther. - Dennis - - - - - - - - - - - OBSERVATIONS 3. Whatever the term rebase signified, I think we can all agree that it is about a fork (or a refork: if you prefer). 4. At the ASF, forking is a feature. The only requirement is that the ALv2 (and any other applicable licenses) be honored. I know, people can be unhappy and will object. But the ASF position, to the extent one is needed, is captured by forking is a feature. 5. The ASF *does*not* police the use of ALv2 content by third parties. The ASF prides itself on how it manages third-party and contributed content. The ASF is meticulous about IP provenance. That is part of the way in which the ASF operates in the public interest by being an extraordinary open-source citizen. That is what the ASF does. It is not about what others might or might not do. 6. It is up to third parties to satisfy themselves that they are operating with any incorporated ALv2 code and its derivatives appropriately. It is not the business of the ASF to warrant anything about such activity. Those who wish to reuse and repurpose code from the third party must also satisfy themselves. That has nothing directly to do with the ASF. 7. Here is further evidence that the ASF is not the ALv2 sheriff over third-party reliance and handling of ALv2 code in their works. It is perfectly clear that closed-source works that have code dependencies on ALv2 works of others are not required to provide an account to anybody, as far as ALv2 license terms go, beyond the appropriate provision of LICENSE/NOTICE files. - - - - - - PERSONAL REMARK I have personally confirmed that a kindred OpenOffice.org-descendant does indeed satisfy the LICENSE/NOTICE provisions of the ALv2. Those files were, in fact, easier for me to find in the installed binaries than in installs of Apache OpenOffice distributions. I have also remarked, in a discussion elsewhere, that I feel the way ALv2 is characterized in individual derivative files I've examined is, to my taste, a bit sketchy. However, the observed practice is not unusual and even happens in the publishing industry where there tends to be serious attention to rights and permissions. I don't think there is a legality question, just my own fussiness, and that of some others, in how provenance and attribution is accounted for in our own work. It should be well-known by now that my fussiness threshold is rather different than that of many other developers [;). This does not matter. I am not an ALv2 cop either. I can only satisfy myself on what I rely on and how I am comfortable that I know enough about its provenance to feel safe in doing so. -Original Message- From: Louis Suárez-Potts [mailto:lui...@gmail.com] Sent: Sunday, August 30, 2015 07:58 To: dev@openoffice.apache.org Subject: Re: Limiting Trademark Policy Discussion (was RE: [REPORT] PMC 2015-07 Private-List ...) Hi, On 29 Aug 15, at 21:13, Dave Fisher dave2w...@comcast.net wrote: [ ... ] We should (re)acknowledge what (re)based on Apache OpenOffice requires whatever that really is. Yep. [ ... ] - 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: cppunit - Google Test migration and old failing tests
On 08/29/2015 12:37 AM, Damjan Jovanovic wrote: On Fri, Aug 28, 2015 at 6:07 PM, Kay Schenk kay.sch...@gmail.com wrote: On 08/27/2015 09:05 PM, Damjan Jovanovic wrote: Hi I am in the process of migrating our unit tests from cppunit to Google Test. However AOO doesn't build with cppunit and hasn't been routinely built with cppunit for a while, which means our unit tests are in a state of neglect, and unsurprisingly, there are many failures both compiling and running our unit tests. Ideally we should investigate why and fix the tests. But the APIs being tested are complex and unfamiliar to me (eg. SVG parsing), and would take very long to investigate properly. I could commit changes that will just get the tests to compile, then fail during testing and stop the build, thus forcing others to fix them quickly :-), but I don't imagine that will go down well. So I am taking this approach instead: // FIXME: #define RUN_OLD_FAILING_TESTS 0 #if RUN_OLD_FAILING_TESTS broken_test(); #endif Also I am making unit tests run on every build. This way at least some unit tests will be run, and any future regressions to tests can be caught immediately, while the broken tests can be fixed gradually. Everyone happy? Well pretty much. :) I've been watching your commits. Thank you for taking on this challenging task. Thank you. OK, just to be clear. It looks like you're converting the cppunit calls to Google Test api calls. But, what you're saying is the actual use of the Google test routines needs additional modification to work correctly, right? Yes that's what I am doing. No, the C++ conversions are very easy (feel free to help ;-)): #include cppunit... = #include gtest/gtest.h class X : public CppUnit::TestFixture = class X : public ::testing:Test CPPUNIT_ASSERT_MESSAGE(msg, condition) = ASSERT_TRUE(condition) msg CPPUNIT_ASSERT_EQUAL(c1, c2)= ASSERT_EQ(c1, c2) CPPUNIT_FALSE(msg) = FAIL() msg private: = protected: test methods move outside of class declaration and become TEST_F(className, methodName) instead CPPUNIT_TEST...() registrations disappear but the problem is that tests themselves are wrong no matter what the testing library. For example: basegfx::tools::importFromSvgD( aPoly, aSvg ); won't compile, as importfromSvgD() requires 4 parameters now instead of just 2 (as I explained in an earlier email, this was caused by commit 1536730 on 2013-10-29 by alg). Damjan A quick question on these changes. Do these require a reconfigure to work correctly? I ran into a problem building with r1698208 so this is why I ask. -- MzK “The journey of a thousand miles begins with a single step.” --Lao Tzu - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: Third-Party ALv2 Dependencies (RE: Limiting Trademark Policy Discussion ...)
Oh, I'm sorry, Dave. I thought I was making it clear, on this change of subject, that I am not talking about trademarks but only 3rd parties deriving from ALv2 code itself, including by rebasing, forking, or any other means. With regard to the use of marks and Powered By I agree that is separate and find your comments about that on the other thread interesting. I agree that is about permitting use of ASF trademarks. I responded to that separately. - Dennis -Original Message- From: Dave Fisher [mailto:dave2w...@comcast.net] Sent: Sunday, August 30, 2015 12:41 To: dev@openoffice.apache.org Subject: Re: Third-Party ALv2 Dependencies (RE: Limiting Trademark Policy Discussion ...) I appreciate all your diligence about licenses. It is valuable. Whatever you want to call this thread ... One intention was to discuss what if anything is required with respect to trademarks when ANY third party product is (re)based on Apache OpenOffice. For example it cannot be called OpenOffice. If there are exceptions to this then these should be openly and explicitly acknowledged. I am not saying that there are any. You are missing the idea of creating a Powered By designation which is about trademark and not the license. If no one is interested then fine. If everyone is happy with the status quo so be it, but I don't think it is the case. Regards, Dave [ ... ] - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: Limiting Trademark Policy Discussion (was RE: [REPORT] PMC 2015-07 Private-List ...)
I'm wondering about the following. I think the based on X conversation is already happening at a general level and I believe participation at that level is better, since this will probably be simple and generic and VP Brand Management will likely take a position that applies to us also. I thought powered by X was also being discussed at a cross-project level. I may have been mistaken. The conversations went across different lists and I lost track. I suspect VP Brand Management may set a policy there too. I think in practice there will always have to be treatment on an individual-case basis. Any cookie-cutter test would be simply a starting point for a negotiated agreement that could be rescinded if an user of the marks violates the agreed conditions. I have no prediction how that would go. Those were somewhat open discussions that arose out of what happens if someone distributes builds of unreleased code, and what about when someone other than the project distributes binaries of released code, with none to significant alternations. How can the Apache Project marks be used under those conditions? It would be good to see what conclusions have been reached, if reached yet, and rely on that broader analysis if possible. I didn't think there was any notion of required labelling so much as indicating how one of those distributions could indicate relationship in a way that did not violate trademarks. I am not certain there was anything about required based/powered but rather conditions under which those would be allowed to be used, although others, including Dave may have raised the prospect. We should look again there. What were your take-aways from those discussion, Dave? - Dennis -Original Message- From: Dave Fisher [mailto:dave2w...@comcast.net] Sent: Saturday, August 29, 2015 18:13 To: dev@openoffice.apache.org Subject: Re: Limiting Trademark Policy Discussion (was RE: [REPORT] PMC 2015-07 Private-List ...) As me from my soapbox: [ ... ] I think that the project should have an open source code test for Powered By that applies to all. The rights to use are clear for all. The obligations spelled out. Benefits given equally. [ ... ] Once we have a proposal that the community likes we can go through any type of confirmation or clearance the Brand committee requires. I expect that this discussion should proceed carefully and not rush into set form but instead collect ideas focusing on different parts. There must be an opportunity to heal rifts with respect for all. Are you open to that discussion? Are you open to any and all to that discussion? This process is not against any group, but for all. Regards, Dave [ ... ] - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
4.1.2_release_blocker granted: [Issue 125991] Fatal Error index out of bounds on Gtk
Andrea Pescetti pesce...@apache.org has granted hanya hanya.r...@gmail.com's request for 4.1.2_release_blocker: Issue 125991: Fatal Error index out of bounds on Gtk https://bz.apache.org/ooo/show_bug.cgi?id=125991 --- Comment #8 from Andrea Pescetti pesce...@apache.org --- Reviewed, accepted as blocker, fixes a fatal error and also has duplicates. @hanya: feel free to port this from trunk to the AOO410 branch for OpenOffice 4.1.2. I can do it too, of course; as you prefer. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Limiting Trademark Policy Discussion (was RE: [REPORT] PMC 2015-07 Private-List ...)
Hi, On 29 Aug 15, at 21:13, Dave Fisher dave2w...@comcast.net wrote: As me from my soapbox: Any proposal for reworking trademark policies would naturally grandfather prior arrangements. My hope is that any rework of policies would be more and not less generous than current reality. I think that the project should have an open source code test for Powered By that applies to all. The rights to use are clear for all. The obligations spelled out. Benefits given equally. Easier said than done. I had written a longer reply on this issue but that can wait. We should (re)acknowledge what (re)based on Apache OpenOffice requires whatever that really is. Yep. Once we have a proposal that the community likes we can go through any type of confirmation or clearance the Brand committee requires. Indeed. I expect that this discussion should proceed carefully and not rush into set form but instead collect ideas focusing on different parts. There must be an opportunity to heal rifts with respect for all. Are you open to that discussion? Are you open to any and all to that discussion? This process is not against any group, but for all. yes. I need to underscore one thing I think Dave is doing here. He’s humanising the process, opening it up. Undoubtedly this will lead to some confusion but it won’t be serious and it won’t fatally commit or tarnish Apache. It will actually be good, should it occur. And it will also lead, I believe, to interested and interesting discussion, which is hugely important and whose very existence implies trust. Regards, Dave best, louis Sent from my iPhone On Aug 29, 2015, at 5:26 PM, Dennis E. Hamilton orc...@apache.org wrote: From the Chair, I don't know, off-hand, what the proportion of discussion of Trademark Policy is in the PMC private discussion activity so far this year. However, a discussion of trademark policy, as such, especially with real and fictional examples, is inappropriate on this list if it is about trademark enforcement. Trademark enforcement, when material to an issue before the PMC, is a private duty of the PMC. There are ways to reduce the discussion to essentials there, however. Let me illustrate what I mean by this. Let's say the Apache OpenOffice PMC has offered arrangements, ratified VP Brand Management, by which a third party can employ AOO marks as part of a Powered by Apache OpenOffice labeling. The PMC establishes the conditions under which that arrangement is available to individual parties and may propose custom arrangements based on the circumstances. That might be useful to describe and clarify here. On the other hand, proposal of conditions under which third parties might be *required* to enter into such an arrangement is entirely different, even hypothetically. As far as I know that is inconsistent with the ASF view of how its mission is accomplished and its being a good citizen in the world of open-source activities. The ASF is by nature not litigious and resolves concerns about inappropriate use of its marks by other means. I can't imagine it attempting to compel use of any of its marks. IMPORTANT. Trademark protection, infringement, and remedies are serious legal matters and they are not for inexpert discussion on public mailing lists. Suspicions of infringement and any acting on those suspicions in public pronouncements are unwelcome. Even disguised accounts of specific situations relevant to this project are inappropriate. And if not relevant to this project, they don't belong here either. To abbreviate the need for custom PMC discussions on cases of alleged trademark infringement, I have posted a policy applicable to how the AOO PMC shall deal with any allegations of infringement and prospective curing of such infringements at http://svn.apache.org/repos/asf/openoffice/pmc/Policies/Trademark-Infringement-Allegations-2015-08.txt. Questions, comments, and suggestions about that text are welcome. - Dennis BACKGROUND INFORMATION At the Apache Software Foundation, the Board delegates the determination and resolution of trademark matters to the Vice President, Brand Management. All external engagement with respect to trademarks is handled discretely within the PMC and then always reviewed by, and possibly acted upon, by VP Brand Management and only VP Brand Management. Individual projects are expected to be vigilant about how marks are used and also allowed in the domain of the project. The Apache OpenOffice PMC conducts such activities. The web site page at http://openoffice.apache.org/trademarks.html is sufficient information for those who have concerns for use of or infringing use of Apache OpenOffice marks. There are non-specific topical discussions on the use of marks and the naming of software distributions based on code from ASF projects, such as recent
Updating English dictionaries today?
Hello, Andrea, I was wondering if, since there are several release blockers around, if I could still be in time to update the English dictionaries to be used in AOO 4.1.2? I have everything ready for an update and I could do it today (although the official release date is always the 1st of every month). I have only added 320 new words to en_GB this month but Kevin Atkinson updated US+CA which is good. I also have now a LibreOffice account where I release the dictionaries there too. Thanks! Kind regards from your friend, Marco A.G.Pinto --
4.1.2_release_blocker granted: [Issue 126454] Update English dictionary to version 2015.08.01
Andrea Pescetti pesce...@apache.org has granted Andrea Pescetti pesce...@apache.org's request for 4.1.2_release_blocker: Issue 126454: Update English dictionary to version 2015.08.01 https://bz.apache.org/ooo/show_bug.cgi?id=126454 --- Comment #2 from Andrea Pescetti pesce...@apache.org --- This is a routine update, already committed to trunk, now porting to AOO410 for OpenOffice 4.1.2. It will likely be updated again before releasing, but at the moment we have the latest available version. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: 4.1.2_release_blocker requested: [Issue 126447] When using LanguageTools, toggling the checkbox check grammar in the spell checker removes content
On 06/08/2015 bugzilla wrote: Marcus has asked for 4.1.2_release_blocker: Issue 126447: When using LanguageTools, toggling the checkbox check grammar in the spell checker removes content https://bz.apache.org/ooo/show_bug.cgi?id=126447 This is committed to trunk, not yet to AOO410 (OpenOffice 4.1.2), but I plan to commit it if we have enough testing coverage. See issue for technical discussion. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Third-Party ALv2 Dependencies (RE: Limiting Trademark Policy Discussion ...)
From the Chair, I need to speak up about the rebasing business. 1. Use of the ALv2 has nothing to do with trademarks, so this conversation should be on a separate thread. 2. However, it probably should not be held here and certainly not privately by the PMC. If someone wants to pursue it, I suggest these observations be checked with an authoritative source on a more-appropriate list, perhaps legal-discuss. Absent that, I request that this conversation not go any farther. - Dennis - - - - - - - - - - - OBSERVATIONS 3. Whatever the term rebase signified, I think we can all agree that it is about a fork (or a refork: if you prefer). 4. At the ASF, forking is a feature. The only requirement is that the ALv2 (and any other applicable licenses) be honored. I know, people can be unhappy and will object. But the ASF position, to the extent one is needed, is captured by forking is a feature. 5. The ASF *does*not* police the use of ALv2 content by third parties. The ASF prides itself on how it manages third-party and contributed content. The ASF is meticulous about IP provenance. That is part of the way in which the ASF operates in the public interest by being an extraordinary open-source citizen. That is what the ASF does. It is not about what others might or might not do. 6. It is up to third parties to satisfy themselves that they are operating with any incorporated ALv2 code and its derivatives appropriately. It is not the business of the ASF to warrant anything about such activity. Those who wish to reuse and repurpose code from the third party must also satisfy themselves. That has nothing directly to do with the ASF. 7. Here is further evidence that the ASF is not the ALv2 sheriff over third-party reliance and handling of ALv2 code in their works. It is perfectly clear that closed-source works that have code dependencies on ALv2 works of others are not required to provide an account to anybody, as far as ALv2 license terms go, beyond the appropriate provision of LICENSE/NOTICE files. - - - - - - PERSONAL REMARK I have personally confirmed that a kindred OpenOffice.org-descendant does indeed satisfy the LICENSE/NOTICE provisions of the ALv2. Those files were, in fact, easier for me to find in the installed binaries than in installs of Apache OpenOffice distributions. I have also remarked, in a discussion elsewhere, that I feel the way ALv2 is characterized in individual derivative files I've examined is, to my taste, a bit sketchy. However, the observed practice is not unusual and even happens in the publishing industry where there tends to be serious attention to rights and permissions. I don't think there is a legality question, just my own fussiness, and that of some others, in how provenance and attribution is accounted for in our own work. It should be well-known by now that my fussiness threshold is rather different than that of many other developers [;). This does not matter. I am not an ALv2 cop either. I can only satisfy myself on what I rely on and how I am comfortable that I know enough about its provenance to feel safe in doing so. -Original Message- From: Louis Suárez-Potts [mailto:lui...@gmail.com] Sent: Sunday, August 30, 2015 07:58 To: dev@openoffice.apache.org Subject: Re: Limiting Trademark Policy Discussion (was RE: [REPORT] PMC 2015-07 Private-List ...) Hi, On 29 Aug 15, at 21:13, Dave Fisher dave2w...@comcast.net wrote: [ ... ] We should (re)acknowledge what (re)based on Apache OpenOffice requires whatever that really is. Yep. [ ... ] - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: build breaker/Issue 126449/ svx module
On 29 Aug, Don Lewis wrote: On 14 Aug, Andrea Pescetti wrote: On 09/08/2015 Don Lewis wrote: Looks like you are compiling with gcc 4.9. I ran into this same problem on FreeBSD and worked around it by changing the -Os optimization flag ... This is a gcc bug, see: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65009 This looks like very valuable information (I never saw this, but I build with gcc 4.8.x most of the times). Could you expand on it a bit? It apparently is an optimizer bug in gcc 4.9 that has been fixed in gcc 5 and was not present in 4.8. It is sometimes triggered by inline virtual class methods. I believe it only happens with -Os optimization. The workaround is to either disable optimization by using -O0, or disabling the problematic optimization step by using -fno-devirtualize -fno-devirtualize-speculatively, which I figured out based on comment #2 in the gcc bug report. I didn't attempt to figure out if only one of the flags would be sufficient. Do I understand correctly from the above issue than anybody building OpenOffice (I'm obviously particularly interested in the coming 4.1.2) with GCC 4.9.0 to 4.9.3 (and possibly later 4.9.x releases, since the issue is not fixed yet in 4.9.x) will have to manually edit their makefiles? Yes. If this is true, would you recommend that we either detect it at configuration time, or modify the makefiles, or anything else? It would be nice to detect it at configuration time, but configure doesn't really look at the compiler version. One half of the build framework does decipher the compiler version and that could be leveraged to change the optimization flags for gcc 4.9, but the other half of the build framework does not. Unfortunately there are two instances where this is broken, and the fix needs to be done in both places. I maintain the FreeBSD port and the approach that I took for package building is to detect the use of gcc 4.9 in the port Makefile, and then patch the freebsd.mk and unxfbsdi.mk on the fly when gcc 4.9 is detected. I didn't need to patch unxfbdx.mk because it uses -O2 optimization on x86_64. Is this related to https://bz.apache.org/ooo/show_bug.cgi?id=125475 (where a patch by Ariel is available, but operates at a C++ code level and not at a Makefile level)? Yes. Early on I saw the LibreOffice folks do something similar, but I was not able to get that to work reliably and switched to -O0 optmization for a long time. My workaround above is fairly recent. As I recall, when I tried something similar to the patch in the bug report, it fixed the problem on x86_64, but not intel. The problem potentially affects two files, fmgridif.cxx and ColumnControl.cxx. The out of the box build on FreeBSD builds one of those with -Os and the other with -O2 on x86_64. Since the gcc bug is only triggered when using -Os, only one of the resulting .o files has the problem, and it is fixed by the patch. On intel, both files are built with -Os, so both .o files have the problem. The patch fixed one of them and the undefined symbols were exported, but they were exported as weak symbols and were not visible outside of the shared library that the .o file was linked into. The .o file that remained broken was linked into another shared library and wasn't able to see the symbols from the fixed .o file. Patching the source to attempt to export these symbols is the wrong thing to do in any case. These are for class methods that are defined in the class declaration, so the expectation is that the compiler will inline them wherever they are used. There are some hooks in the build specific files with optimization disabled, so adding the above two files to that list is one possible fix, though I don't know if that hook is present in both parts of the build framework, but it looks like it is. Another possibility is to globally change -Os to -Os -fno-devirtualize -fno-devirtualize-speculatively when building with gcc. On the solenv/inc side, this would involve patching these files: os2.mk unxfbsdi.mk unxfbsdppc.mk unxlngi.mk unxlngm68k.mk unxlngmips.mk unxlngppc.mk unxlngr.mk unxlngs.mk Since CCUMVER is available, this could be made conditional on the gcc version. On the gbuild/platform side, the files to change are: freebsd.mk linux.mk os2.mk winmingw.mk Since CCNUMBER is not available here, the optmiization change would affect all gcc versions. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: cppunit - Google Test migration and old failing tests
No they shouldn't. It's possible something broke. Do you have a log of the build? On Sun, Aug 30, 2015 at 11:16 PM, Kay Schenk kay.sch...@gmail.com wrote: On 08/29/2015 12:37 AM, Damjan Jovanovic wrote: On Fri, Aug 28, 2015 at 6:07 PM, Kay Schenk kay.sch...@gmail.com wrote: On 08/27/2015 09:05 PM, Damjan Jovanovic wrote: Hi I am in the process of migrating our unit tests from cppunit to Google Test. However AOO doesn't build with cppunit and hasn't been routinely built with cppunit for a while, which means our unit tests are in a state of neglect, and unsurprisingly, there are many failures both compiling and running our unit tests. Ideally we should investigate why and fix the tests. But the APIs being tested are complex and unfamiliar to me (eg. SVG parsing), and would take very long to investigate properly. I could commit changes that will just get the tests to compile, then fail during testing and stop the build, thus forcing others to fix them quickly :-), but I don't imagine that will go down well. So I am taking this approach instead: // FIXME: #define RUN_OLD_FAILING_TESTS 0 #if RUN_OLD_FAILING_TESTS broken_test(); #endif Also I am making unit tests run on every build. This way at least some unit tests will be run, and any future regressions to tests can be caught immediately, while the broken tests can be fixed gradually. Everyone happy? Well pretty much. :) I've been watching your commits. Thank you for taking on this challenging task. Thank you. OK, just to be clear. It looks like you're converting the cppunit calls to Google Test api calls. But, what you're saying is the actual use of the Google test routines needs additional modification to work correctly, right? Yes that's what I am doing. No, the C++ conversions are very easy (feel free to help ;-)): #include cppunit... = #include gtest/gtest.h class X : public CppUnit::TestFixture = class X : public ::testing:Test CPPUNIT_ASSERT_MESSAGE(msg, condition) = ASSERT_TRUE(condition) msg CPPUNIT_ASSERT_EQUAL(c1, c2)= ASSERT_EQ(c1, c2) CPPUNIT_FALSE(msg) = FAIL() msg private: = protected: test methods move outside of class declaration and become TEST_F(className, methodName) instead CPPUNIT_TEST...() registrations disappear but the problem is that tests themselves are wrong no matter what the testing library. For example: basegfx::tools::importFromSvgD( aPoly, aSvg ); won't compile, as importfromSvgD() requires 4 parameters now instead of just 2 (as I explained in an earlier email, this was caused by commit 1536730 on 2013-10-29 by alg). Damjan A quick question on these changes. Do these require a reconfigure to work correctly? I ran into a problem building with r1698208 so this is why I ask. -- MzK “The journey of a thousand miles begins with a single step.” --Lao Tzu - 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: cppunit - Google Test migration and old failing tests
On Sun, Aug 30, 2015 at 11:16 PM, Kay Schenk kay.sch...@gmail.com wrote: On 08/29/2015 12:37 AM, Damjan Jovanovic wrote: On Fri, Aug 28, 2015 at 6:07 PM, Kay Schenk kay.sch...@gmail.com wrote: On 08/27/2015 09:05 PM, Damjan Jovanovic wrote: Hi I am in the process of migrating our unit tests from cppunit to Google Test. However AOO doesn't build with cppunit and hasn't been routinely built with cppunit for a while, which means our unit tests are in a state of neglect, and unsurprisingly, there are many failures both compiling and running our unit tests. Ideally we should investigate why and fix the tests. But the APIs being tested are complex and unfamiliar to me (eg. SVG parsing), and would take very long to investigate properly. I could commit changes that will just get the tests to compile, then fail during testing and stop the build, thus forcing others to fix them quickly :-), but I don't imagine that will go down well. So I am taking this approach instead: // FIXME: #define RUN_OLD_FAILING_TESTS 0 #if RUN_OLD_FAILING_TESTS broken_test(); #endif Also I am making unit tests run on every build. This way at least some unit tests will be run, and any future regressions to tests can be caught immediately, while the broken tests can be fixed gradually. Everyone happy? Well pretty much. :) I've been watching your commits. Thank you for taking on this challenging task. Thank you. OK, just to be clear. It looks like you're converting the cppunit calls to Google Test api calls. But, what you're saying is the actual use of the Google test routines needs additional modification to work correctly, right? Yes that's what I am doing. No, the C++ conversions are very easy (feel free to help ;-)): #include cppunit... = #include gtest/gtest.h class X : public CppUnit::TestFixture = class X : public ::testing:Test CPPUNIT_ASSERT_MESSAGE(msg, condition) = ASSERT_TRUE(condition) msg CPPUNIT_ASSERT_EQUAL(c1, c2)= ASSERT_EQ(c1, c2) CPPUNIT_FALSE(msg) = FAIL() msg private: = protected: test methods move outside of class declaration and become TEST_F(className, methodName) instead CPPUNIT_TEST...() registrations disappear but the problem is that tests themselves are wrong no matter what the testing library. For example: basegfx::tools::importFromSvgD( aPoly, aSvg ); won't compile, as importfromSvgD() requires 4 parameters now instead of just 2 (as I explained in an earlier email, this was caused by commit 1536730 on 2013-10-29 by alg). Damjan A quick question on these changes. Do these require a reconfigure to work correctly? I ran into a problem building with r1698208 so this is why I ask. I see, main/codemaker's tests don't build unless AOO is already built; it's probably one of those tests that needs OOO_SUBSEQUENT_TESTS. r1698208 builds for me with this patch (ie. delete the last line of text in main/codemaker/prj/build.lst): Index: main/codemaker/prj/build.lst === --- main/codemaker/prj/build.lst(revision 1700184) +++ main/codemaker/prj/build.lst(working copy) @@ -7,4 +7,3 @@ cmcodemaker\source\cppumakernmake-all cm_cppumaker cm_codemaker cm_cpp cm_inc NULL cmcodemaker\source\commonjavanmake-all cm_java cm_inc NULL cmcodemaker\source\javamakernmake-all cm_javamaker cm_codemaker cm_java cm_inc NULL -cmcodemaker\test\cppumakernmake-all cm_cppumaker_test cm_cppumaker cm_codemaker cm_cpp cm_inc NULL However in the latest SVN I then get another build error in main/oovbaapi: Compiling: Globals.idl /tmp/idli_wyec6x: line 32: file 'com/sun/star/table/XCellRange.idl' not found AOO/main/solver/420/unxfbsdx/bin/idlc: preprocessing file /AOO/main/oovbaapi/ooo/vba/excel/Globals.idl failed dmake: Error code 1, while making '../../../unxfbsdx/ucr/excel.db' which isn't in a module I changed. I am bisection testing between r1698208 and r1700184 to see what broke that. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Third-Party ALv2 Dependencies (RE: Limiting Trademark Policy Discussion ...)
Hi Dennis; I find your posting somewhat confusing as the topic would indicate something different from the body of the message. I agree in observation 5 that the ASF (actually I can only speak partially for AOO) does *not* police the use of ALv2 content by third parties. This, of course, doesn't mean that third parties are at liberty of ignoring the license. Considering your personal remark are you referring to clause 4 (a) and (d)? IANAL and that's someone else's job at the ASF, but I didn't find those in the root tree of a certain third party, which is where I would expect them to be. I do think there is at least a willing effort to deceive the public opinion by hiding the presence of ALv2 code and it's extent. Back to the topic of ALv2 dependencies. I think you are aware that I notified the PMC repeatedly about licensing concerns. I hope the situation is solved before the next release as it may be an issue. I personally don't plan to interfere with the release process at all, but I think the PMC understands that unlike third parties, IP issues are taken very seriously for ASF releases. Regards, Pedro. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
