Re: volunteer activity tracking
On 24.11.2019 13:19, Jörg Schmidt wrote: > > >> -Original Message- >> From: Peter Kovacs [mailto:pe...@apache.org] >> Sent: Sunday, November 24, 2019 11:28 AM >> To: dev@openoffice.apache.org >> Subject: Re: volunteer activity tracking >> >> >> On 24.11.19 09:30, Jörg Schmidt wrote: Normally we discuss to get a consensus. Crucial votes are out-of-favour. This is the only way to keep the community together. >>> No, that is only a way of unification. >> But if there is no unification, voices have not been taken >> sufficiently >> into account. >> >> If this happens to often, people will go away, and the community is >> diminished. > That's not gonna happen. That's happened. > > Lots and lots of former volunteers left the OpenOffice project and either > went to LO or turned away from free software. > Doesn't it show the weakness of our project that we couldn't even stand up to > a newcomer like LO? (Nothing general against LO, only it is not our project. > Our task is to ensure the success of AOO.) > > The example of the ProOO-Box shows how wrong the procedure is in some cases. > With OOo, the ProOO box was part of the project, with AOO it was suddenly no > longer part of the project, but was declared a "third party" without any > substantial reason. > At the persistent request of the volunteers, it was explained that the ProOO > box could apply as a separate incubator project. > Does nobody understand how absurd this proposal was? Does no one understand > how it offended volunteers? I don't know anything about this story, but in general terms: as far as I'm aware, a software grant (or other kind of IP contribution) can go directly to an existing PMC without having to pass through the Incubator. If anyone said otherwise, they were simply wrong. -- Brane - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: volunteer activity tracking
On 21.11.2019 14:42, Jörg Schmidt wrote: > > >> -Original Message----- >> From: Branko Čibej [mailto:br...@apache.org] >> Sent: Thursday, November 21, 2019 2:16 PM >> To: dev@openoffice.apache.org >> Subject: Re: volunteer activity tracking > >> I have not heard of a single instance in the history of the ASF where >> merit was bought -- either through donations or through salaried >> employees. I'm sure there have been attempts, we all know >> what nonsense >> "smart" managers are capable of coming up with. > And I didn't(!!!) say anyone intended to buy "merit". I was talking about > legally acquired merit. I'm not sure what you mean by "legally acquired merit." > Or are members of the PMC not allowed to have different opinions when voting? They surely are, but a healthy community will reach a consensus through discussion, not by majority fiat through a vote. This is actually a crucial point and what the ASF is all about: and, if you find yourself making decisions by voting, rather than the vote being just a way to formally confirm prior consensus, then something has gone very wrong. Different opinions /should/ be ironed out through discussion. If they're not, eventually the community will break up. If the community finds itself unable to form consensus about some topic, it's better to postpone any decision, or explore alternatives. > And if they may, may they not have different opinions in the future than at > the time when they became a PMC member? Of course they may. That's a normal consequence of learning, after all. -- Brane - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: volunteer activity tracking
On 21.11.2019 13:35, Jörg Schmidt wrote: > Hello, > >> -Original Message- >> From: Hagar Delest [mailto:delest.ha...@gmail.com] >> Sent: Wednesday, November 20, 2019 7:29 PM >> To: dev@openoffice.apache.org >> Subject: Re: volunteer activity tracking >> >> Le 20/11/2019 à 09:33, Jörg Schmidt a écrit : >>> for example: At first glance, activity is activity, but I >> think there >>> is a certain difference between the activity of people who >> only work >>> in the project because they are paid for it by companies and people >>> who work in the project out of their own interest. >> I don't understand the point. If he someone is paid to work on the >> project, at least he produces something. Why would it be >> considered less >> than the energy put by someone contributing of his own? What >> if the guy >> is paid AND he likes what he does? > My opinion is that "merit" is something specific other than "important" (Your > wording was: "Why would it be considered less..."). "merit" is something very > personal. > > For me, this is personal because each of us, with skill, effort and perhaps > also some luck, can earn and donate any amount of money. On the other hand > the day has only 24 hours for each of us and nobody can increase this time. > > And please, don't get me wrong: > the support by companies or other donors, I don't think is unimportant or of > less value in the core, but "merit" is something which for me also contains a > pinch of what one could call "honor". (Perhaps not the best choice of words, > but hopefully understandable) I have not heard of a single instance in the history of the ASF where merit was bought -- either through donations or through salaried employees. I'm sure there have been attempts, we all know what nonsense "smart" managers are capable of coming up with. If you have evidence that specific people have a secret agenda to undermine or otherwise steer this project in ways that are not in the best interests of the users, then by all means bring it up, either here, or on the private@ list, or to the Board. Open discussion is definitely encouraged at the ASF. But please be careful if you do: saying "I have a feeling" is not evidence. -- Brane - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Para-site
On 07.11.2019 16:29, Bidouille wrote: > Domain name: openoficextrem.com > Registry Domain ID: 1966381298_DOMAIN_COM-VRSN > Registrar WHOIS Server: whois.namecheap.com > Registrar URL: http://www.namecheap.com > Updated Date: 2019-09-09T10:26:10.34Z > Creation Date: 2015-10-06T10:53:42.00Z > Registrar Registration Expiration Date: 2020-10-06T10:53:42.00Z > Registrar: NAMECHEAP INC > Registrar IANA ID: 1068 > Registrar Abuse Contact Email: ab...@namecheap.com > Registrar Abuse Contact Phone: +1.6613102107 > Reseller: NAMECHEAP INC > Domain Status: clientTransferProhibited > https://icann.org/epp#clientTransferProhibited > Registry Registrant ID: > Registrant Name: WhoisGuard Protected > Registrant Organization: WhoisGuard, Inc. > Registrant Street: P.O. Box 0823-03411 > Registrant City: Panama > Registrant State/Province: Panama > Registrant Postal Code: 0 > Registrant Country: PA > Registrant Phone: +507.8365503 > Registrant Phone Ext: > Registrant Fax: +51.17057182 This should go to trademarks@a.o for further processing, IMO. -- Brane - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: what is this supposed to do?
On 06.11.2019 18:06, Don Lewis wrote: > On 6 Nov, Branko Čibej wrote: >> On 05.11.2019 20:20, Peter Kovacs wrote: >>> I am not sure why, but if you use gcc++98 std it compiles. Maybe it >>> optimizes the code since it might be dead code. >> That would be a very, very strange way to go about things. To figure out >> something is dead code, you have to at *least* parse it first, and the >> syntax error is pretty glaring. (Oops ... it's not, strictly speaking, a syntax error at all.) >> It's not impossible that the function is >> never called and hence previous (IMO, buggy) versions of GCC never got >> to generate the template function. > It's not just gcc, clang also is happy, at least in gnu++98 mode. I do > remember seeing this problem before, which was probably after clang > switched its default to a newer C++ standard and before I switched the > FreeBSD port to always build in gnu++98 mode. > > My suspicion is that the source is getting tokenized, but since the > method is defined in a header and will get inlined where it gets used, > it is being treated a lot like the body of a macro and the deeper > analysis of the code is getting deferred until the method gets called > somewhere. That makes sense, yes. Oooh, I could've got away with so many nasty delayed-action mines in the code if I'd only known some compilers behaved in this "interesting" way. :D -- Brane - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: what is this supposed to do?
On 05.11.2019 20:20, Peter Kovacs wrote: > I am not sure why, but if you use gcc++98 std it compiles. Maybe it > optimizes the code since it might be dead code. That would be a very, very strange way to go about things. To figure out something is dead code, you have to at *least* parse it first, and the syntax error is pretty glaring. It's not impossible that the function is never called and hence previous (IMO, buggy) versions of GCC never got to generate the template function. -- Brane - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: what is this supposed to do?
On 05.11.2019 19:54, Don Lewis wrote:
> I don't understand what this strange little bit of code (line 611 of
> basebmp/inc/basebmp/packedpixeliterator.hxx) is supposed to do:
>
> value_type get(difference_type const & d) const
> {
> const int remainder( x(d.x) % num_intraword_positions );
> ^^
> return (unsigned_cast(*current(d.x,d.y) &
> get_mask bits_per_pixel, MsbFirst>(remainder))
> >> get_shift MsbFirst>(remainder));
> }
>
> I've never seen any compiler complaints about it before, but gcc 9
> throws an error:
>
> ../inc/basebmp/packedpixeliterator.hxx: In member function
> 'basebmp::PackedPixel
> Iterator::value_type
> basebmp::PackedPixelIt
> erator::get(const difference_type&)
> const':
> ../inc/basebmp/packedpixeliterator.hxx:611:35: error: expression cannot be
> used
> as a function
> 611 | const int remainder( x(d.x) % num_intraword_positions );
> | ^
Gcc 9 is right, 'x' is a MoveX which is an integer as far as I can see.
I have no idea what this means either, or how it can be valid code.
Unless there's some really heavy macro magic going on behind the scenes,
but that doesn't make much sense given the rest of the code in that class.
-- Brane
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: C++ standard when building OpenOffice
On 04.11.2019 05:15, Damjan Jovanovic wrote: > Yeah, it has compiler bugs, undocumented linker issues, crashes when built > with Clang due to lack of -fno-enforce-eh-specs support, crash-on-startup > on some Windows installations, porting to new platforms is hard, there are > incompatibilities with Microsoft Visual C++ > static/multithreaded/debug/release library options, it's difficult using > new C++ versions, it has ridiculous build times (7+ hours on Windows), > patches often break the build on some platforms, has all kinds of > platform-specific limitations (eg. no throwing exceptions or passing STL > structures across DLL boundaries), and it's Swiss cheese in terms of > security holes, but C++ is just perfect right? OK, if this is going to be a language war, let me just point out that "competent" isn't a function of the source programming language ... :) -- Brane - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: C++ standard when building OpenOffice
On 04.11.2019 02:14, Damjan Jovanovic wrote: > Thank you for the info. I haven't had good experiences with Boost in my > Win64 attempts either... > > Don, how feasible do you think Go or Rust are, to start using in place of > C++? Really? You'd rewrite code in a completely different language because you can't figure out a way to select std::auto_ptr or std::unique_ptr depending on your build environment? FWIW, both Go and Rust are far more moving targets than C++, but sure, that's not going to be a problem, eh. -- Brane > On Mon, Nov 4, 2019 at 1:08 AM Don Lewis wrote: > >> On 3 Nov, Don Lewis wrote: >>> For much of our history, until fairly recently, the versions of gcc that >>> we used defaulted to -std=gnu++98 when compiiling C++ code. >>> >>> When FreeBSD on i386 and amd64 switched from gcc to clang, it also >>> defaulted to -std=gnu++98. Clang has been C++11 compliant from version >>> 3.3 onwards. Around the time of the switch, I added the >>> -DHAVE_STL_INCLUDE_PATH compiler flag so that clang would use it's own >>> STL include files instead of the boost TR1 includes. Clang was >>> perfectly happy using its own STL include files even though they were >>> not part of C++98, only C++11. >>> >>> Later on, when clang 6 changed the default to gnu++14, the build >>> generated tons warning and some number of errors. To work around this, >>> I added the -std=gnu++98 compiler flag to force the old mode. >>> >>> FreeBSD on powerpc still uses gcc and it recently came to my attention >>> that the build was broken there. The FreeBSD port of AOO to powerpc >>> does not use -DHAVE_STL_INCLUDE_PATH, so it was falling back to the >>> boost TR1 headers. The FreeBSD port uses the system boost, and recent >>> versions of boost have dropped TR1 support. To work around that, I >>> tried enabling -DHAVE_STL_INCLUDE_PATH to use the gcc C++ headers. This >>> failed badly because the gcc STL headers check to see if the compilation >>> mode is C++11 or better and immediately error out of this is not the >>> case. Switching the compilation mode to c++11 results in the warning >>> and error spew mentioned above. I tried modifying the stlport headers >>> to include the gcc TR1 headers in gnu++98 mode. That worked better, but >>> I still got some mysterious C++ errors that I was not able to figure >>> out. My next attempt will be to try the boost non-TR1 headers. >> That was a dead end. Recent boost appears to assume that the STL headers >> are provided by the system. I'll probably have to switch back to >> bundled boost and use its TR1 headers. >> >> >> - >> 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: macOS Notarization test builds
On 01.11.2019 12:11, Dave Fisher wrote: > Jim, > > It worked for Catalina and that is the goal. I don’t think a difference > should be expected for macOS prior to 10.15. > > Please check with Apple Developer documentation before letting FUD get you! Come on, it's not FUD. Just a normal install on 10.14: opening the DMG, copying AOO to /Applications and running it from there, macOS Mojave will *not* allow it until you jump through the hoops of System Preferences. Having such an important piece of software properly signed for Windows and macOS is simply a basic requirement (has been for years, really) and, IMNSHO, it should be Infra that provides the required services to do so, for builds created on our infrastructure, not Joe "Random" Developer. -- Brane >> On Nov 1, 2019, at 6:40 PM, Jim Jagielski wrote: >> >> >> >>> On Oct 31, 2019, at 5:20 PM, Branko Čibej wrote: >>> >>> On 31.10.2019 19:49, Jim Jagielski wrote: >>>> Located at >>>> >>>> https://home.apache.org/~jim/AOO-builds/AOO418-macOS-test/ >>>> >>>> Are some test macOS dmgs that should be correctly signed and notarized >>>> such that they do not trigger Gatekeeper; that is, they should result in >>>> AOO opening on macOS without any warning about unknown developer. >>>> >>>> Please check that this does, in fact, happen ;) If not, then instead of >>>> signing, notarizing and stapling the DMG we will need to do the actual app >>>> itself, which means some changes to the actual AOO build and packaging >>>> process... which I hope we don't need :) >>> >>> Nope, sorry (macOS 10.14.6). Still complains. Signing the DMG is not enough. >>> >> As I feared... I'll start looking at where to plug-in the additional steps. >> >> Most likely, we'll need to separate out, functionally in the build setup, >> creating the binary and the packaging... something like: >> >> $ build.pl" --all (stops before we bundle things up) >> $ dmake package (rpm and deb for Linux, dmg for macOS) >> >> >> - >> 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: macOS Notarization test builds
On 31.10.2019 19:49, Jim Jagielski wrote: > Located at > > https://home.apache.org/~jim/AOO-builds/AOO418-macOS-test/ > > Are some test macOS dmgs that should be correctly signed and notarized such > that they do not trigger Gatekeeper; that is, they should result in AOO > opening on macOS without any warning about unknown developer. > > Please check that this does, in fact, happen ;) If not, then instead of > signing, notarizing and stapling the DMG we will need to do the actual app > itself, which means some changes to the actual AOO build and packaging > process... which I hope we don't need :) Nope, sorry (macOS 10.14.6). Still complains. Signing the DMG is not enough. -- Brane - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [DISCUSSION] Build environment future
On 30.10.2019 06:25, Peter Kovacs wrote: > Hello Damjan and all > > > I would like to re-discuss our current plan. Hoping to gain a common view. > > Current state is mostly we use gmake, there are still some difficult to > migrate dmake projects. And we use Ant for java. > > The plan is not to stop at the dmake -> gmake conversion but to move on > to scons, removing as much dependencies as we can. Right? 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. -- Brane - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Mac system Catalina
On 28.10.2019 07:40, Peter Kovacs wrote: > Hi Helen, > > AFAIK the current version 4.1.7 should work, as all other versions did work > before. > Can you describe your issue in more detail? Even I saw reports on this very list to the tune that, without proper notarization, apps won't work on Catalina. AOO is not notarized by Apple. Hence, user problems. -- Brane > Am 28. Oktober 2019 00:36:22 MEZ schrieb Helen Robson > : >> Could you tell me when OpenOffice will be updated to run on Mac System >> Catalina? >> Thank you >> H Robson >> >> Sent from my iPad >> >> - >> 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: upgrading OpenSSL
On 07.10.2019 01:23, Peter Kovacs wrote: > Serf is dropping scon, Nope, we're just adding a CMake build. Scons is still supported. > and with 4.0 supportung cmake, too. Not that it changes a lot. It actually does, the CMake build also properly supports latest CMake-enabled APR and APR-Util builds. > There was a thread with the request of feedback quite a while back. Yes, there was. I asked someone to test the latest 1.4.x branch (or trunk), but didn't get any feedback. Sadly I don't have time to set up an AOO build environment. On the bright side, the Serf 1.4.x branch supports OpenSSL 1.1.x (tested on Windows, Linux and macOS). -- Brane - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: FOSDEM 2020
If it's not too late and if you don't mind, I'd like to fix grammar and semantics here: On 19.09.2019 13:33, Matthias Seidel wrote: > Hi Michael, > > Small corrections inside: > > Am 17.09.19 um 09:57 schrieb Dr. Michael Stehmann: >> Hello, >> >> we are planning to join next FOSDEM like we did in the past. To get a >> booth (stand) we have to write a request. The deadline for this request >> will come soon. >> >> Among other things we have to answer two questions. With help from Peter >> I sketched a text for this purpose. >> >> Feel free to criticize this draft: >> >> """ >> Description of project(s) for publication: >> >> Apache OpenOffice is the Free and Open Productivity Suite to handle >> office tasks. The roots of Apache OpenOffice go back more than twenty >> years, creating a mature and powerful product. > Apache OpenOffice is a Free and Open Productivity Suite to handle > office tasks. The roots of Apache OpenOffice go back more than twenty > years, creating a mature and powerful product. Not "... creating a mature ..." but "... making it a mature ...". You don't "create" a mature product by starting it 20 years ago, but being 20 years old could (potentially, YMMV) "make" it mature. >> The software looks and feels familiar and is instantly usable by anyone >> who has used a competitive product. It has many millions of users and >> still millions of downloads each year. > The software looks and feels familiar and is instantly usable by anyone > who has used a competitive product. It has many millions of users and > still millions of downloads every year. If you're going full marketroid, at least don't say "... used a competitive product" but "... used a *competing* product." (Or even better, "similar" instead of "competing" to avoid the horrible marketroiderism.) Saying other products are "competitive" implies that AOO is not. Perish the thought. -- Brane P.S.: Yes, I am extremely allergic to marketspeak, but if you really want to use it, might as well get it right. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: SHA1/MD5 in sal/rtl/source/digest.c patch license able for OO
On 25.07.2019 00:43, Peter Kovacs wrote: > Hello all, > > > I would like to ask if I or any other from OpenOffice Development team > can port the patch from LibreOffice to OpenOffice to fix this Issue > under the APL2 License, so the Issue can be fixed in OpenOffice without > more work then necessary. Would it be appropriate to use the hash code from APR (https://apr.apacha.org)? The license fits, and that code has been stable and well tested for ages. But I'm not sure if it fits your FIPS compliance requirements. -- Brane - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [discussion] svn migration plan
On Sun, 21 Jul 2019, 07:25 Mechtilde, wrote: > Hello Branko, > > Am 21.07.19 um 02:01 schrieb Branko Čibej: > > On Sun, 21 Jul 2019, 01:42 Peter Kovacs, wrote: > > > >> Hi brane, > >> > >> The threads are linked in my first post. > >> > > > > Thanks ... Sorry I missed those. > > > > > >> It is for me a workflow thing. > >> I need a decentral versioning system instead of a central one. > >> > > > > > > Which particular "decentralised" feature do you miss most? For example, > > there's work going on to implement client-side shelving (similar to 'git > > stash'), it's experimental but available in various forms in the last 3 > > Subversion (minor) releases > > Most of the missing features were the reason why Git was developed. > As Peter said SVN is centralized, Git is decentralized. > With Git you can do your own home branch without publishing for testing. > And then you can do a Merge Request (on Github it is named Pull Request) > > With Git you need one Repo e.g. with the two branches trunk and 42x. > With SVN you have two branches to checkout. So you need double space to > hold the repo locally for testing > This last isn't strictly true (see 'svn switch'), but it doesn't really matter; I'm not trying to change anyone's mind, just to understand your motivation. Thanks everyone for your explanations. In time, we'll make Subversion so much better that it'll wipe Git off the map. :) -- Brane > >
Re: [discussion] svn migration plan
On Sun, 21 Jul 2019, 01:42 Peter Kovacs, wrote: > Hi brane, > > The threads are linked in my first post. > Thanks ... Sorry I missed those. > It is for me a workflow thing. > I need a decentral versioning system instead of a central one. > Which particular "decentralised" feature do you miss most? For example, there's work going on to implement client-side shelving (similar to 'git stash'), it's experimental but available in various forms in the last 3 Subversion (minor) releases And I want github as public patch interface. > Both do not work with svn. > > I add a reason that I heard at work. Young people do not know svn. They > expect to work with git. > IMHO it is a dumb argument but in my country the fresh people from > university are dictating a little their working environment. > > Ahh and git has major pains reading OpenOffice svn repo. So I can't even > use git as a client. > I assume you mean git-svn? I'm not surprised. Thanks for taking the time to respond. Looks like nothing short of making svn just another git would make you change your mind. :) -- Brane > > All the best. > Peter > > Am 21. Juli 2019 01:17:32 MESZ schrieb "Branko Čibej" : > >Hi AOO devs, > > > >I just stumbled onto this thread. Coming from subversion.a.o, I'm > >saddened > >to see you've decided to switch to Git. Could someone please summarise > >the > >reasons for this decision, or give me a link to the discussion in the > >mail > >archives? I'd very much like to know if it was caused by some specific > >problem or missing feature in Subversion that we may be able to > >address. > > > >-- Brane >
Re: [discussion] svn migration plan
Hi AOO devs, I just stumbled onto this thread. Coming from subversion.a.o, I'm saddened to see you've decided to switch to Git. Could someone please summarise the reasons for this decision, or give me a link to the discussion in the mail archives? I'd very much like to know if it was caused by some specific problem or missing feature in Subversion that we may be able to address. -- Brane
Re: Does OpenOffice still use Serf?
On 15.11.2018 21:17, Branko Čibej wrote: > On 15.11.2018 20:28, Matthias Seidel wrote: >> Hi Pedro, >> >> Am 13.11.18 um 23:20 schrieb Pedro Lino: >>>> On November 13, 2018 at 10:08 PM Andrea Pescetti >>>> wrote: >>>> 2. All WebDAV operations. You can find somewhere in Bugzilla a patch >>>> that didn't make it to 4.1.2 due to excessive complexity (build >>>> requirements). The Serf upgrade was meant to supplement WebDAV fixes in >>>> 4.1.2. >>>> >>>> So you might want to focus testing on these two scenarios (the second >>>> one will probably be tricky). >>> I can help with testing this feature. I use AOO for editing files on a >>> webdav folder. >>> I use Windows 7 Pro, Ubuntu 16.04 and 18.04 (all x64) >>> Let me know when the builds are ready ;) >> I just gave up on building AOO with Serf 1.3.9... ;-) >> >> Given the problems with Scons mentioned by Andrea I think it is better >> to focus on Serf 1.4.0 if we want to upgrade. > Note that if you want to go this way (and I do recommend it), I suggest > using Serf's trunk for now. The difference between trunk and the current > 1.4.0 branch are a couple of bug fixes and the fact that trunk reports > version 2.0. > > I also recommend using the CMake build — Serf can very handily be > included as a subproject into another CMake tree, let me know if you > need help with that, I can provide examples. Has anyone managed to make any progress on this? Any results available? -- Brane - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Check for Updates broken?
On 19.11.2018 18:17, Andrea Pescetti wrote: > Pedro Lino wrote:>> On November 19, 2018 at 12:52 AM Branko Čibej wrote: >>> It looks like you found the real problem: >>> $ curl -sviI --tlsv1.0 https://ooo-updates.apache.org/ > > This makes sense, but I still don't understand it as the full > explanation. > > I mean, if this is due to bundled libraries then why do the same > binaries produce different results on different systems? > > This is config.log from my test 4.1.6 build (done on CentOS 7): > --- > configure:16978: checking which libnss to use > configure:17076: result: internal > configure:17088: checking which libssl to use > configure:17194: result: internal > --- > so this should mean we are using bundled libraries. > > Then I copy the produced binaries to Ubuntu 16.04 and to Fedora 26 > (these happen to be the machines that I setup for this test). > > On CentOS 7 (where it was built): > $ ./soffice https://ooo-updates.apache.org/index.html # Fails > $ ./soffice https://fosdem.org # Succeeds > $ curl -sviI --tlsv1.0 https://ooo-updates.apache.org/ # Fails > > On Ubuntu 16.04: > $ ./soffice https://ooo-updates.apache.org/index.html # Fails > $ ./soffice https://fosdem.org # Succeeds > $ curl -sviI --tlsv1.0 https://ooo-updates.apache.org/ # Fails > > On Fedora 26: > $ ./soffice https://ooo-updates.apache.org/index.html # Succeeds! > $ ./soffice https://fosdem.org # Succeeds > $ curl -sviI --tlsv1.0 https://ooo-updates.apache.org/ # Fails > > Does the current explanation actually explain why the first command > succeeds on Fedora? (of course, this also reflects in GUI, where the > check for updates only succeeds on Fedora). No ... but checking which OpenSSL library is actually used at runtime just might. Just now I downloaded 4.1.6 and installed it on a VM running XUbuntu 14.04. I didn't find libcrypto.so or libssl.so in the install tree, nor are they mentioned by ldd. Opening fosdem.org or ooo-updates.apache.org just hangs. -- Brane - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Check for Updates broken?
On 19.11.2018 10:11, Pedro Lino wrote: > Hi Brane, all > >> On November 19, 2018 at 12:52 AM Branko Čibej wrote: >>> Does the Apache web server still support TLS version 1.0? The old >>> version of OpenSSL that we bundle with the Windows and Linux versions >>> doesn't support anything newer than that. >> >> It looks like you found the real problem: >> >> $ curl -sviI --tlsv1.0 https://ooo-updates.apache.org/ >> * Trying 40.79.78.1... >> ... >> * TLSv1.0 (OUT), TLS handshake, Client hello (1): >> * TLSv1.0 (IN), TLS alert, Server hello (2): >> * error:1400442E:SSL routines:CONNECT_CR_SRVR_HELLO:tlsv1 alert protocol >> version >> >> >> Connection fails with options --tlsv1.0 and --tlsv1.1 but succeeds with >> --tlsv1.2. Which is in fact a good thing; TLSv1 and TLSv1.1 both have >> known security bugs. > This means that on the Server side connection with the current version of > Openoffice will not be accepted? > Can this change be reversed or an exception opened for AOO? This is a server-side configuration, I suppose an exception could be added ... but this is for Infra to decide. > Otherwise, how are users going to be notified that any future version is > available? It's actually a bit worse than users not being notified. If you bundle your own SSL library you must have a process in place to track security fixes in said library. I suspect OpenSSL is not the only issue; for example, AOO still uses Serf 1.2.1, which does not support the latest OpenSSL, so you're effectively stuck with 1.02 and can't migrate to 1.1.0 unless you also upgrade Serf. -- Brane - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Check for Updates broken?
On 18.11.2018 23:30, Don Lewis wrote: > On 17 Nov, Pedro Lino wrote: >>> On November 17, 2018 at 5:32 PM Andrea Pescetti wrote: >>> A nice additional benefit is that this gives us a simple way to >>> reproduce the bug, equivalent to the update notification. >>> >>> $ soffice https://ooo-updates.apache.org/index.html >>> (this fails on Ubuntu, succeeds on Fedora) >>> >>> Note that >>> >>> $ soffice https://www.google.com/ >>> will work in all cases (so this is not an HTTPS bug per se) and >>> >>> $ soffice http://ooo-updates.apache.org/index.html >>> will work in all cases (so this not a network issue but rather an SSL >>> issue). >>> >>> Now, debugging SSL issues is not easy, but can the people who don't get >>> updates at least confirm the three results above, i.e., that only the >>> first one fails? >> Confirmed that only the first one fails. >> I always get the message (even when it didn't fail to open the page) >> >> Gtk-Message: Failed to load module "overlay-scrollbar" >> >> ** (soffice:10458): WARNING **: Unknown type: GailWindow >> >>> Further tests show that problematic systems have issues with ASF sites >>> in HTTPS, like: >>> $ soffice https://www.apache.org/ # Fails >>> $ soffice http://www.apache.org/ # Succeeds >>> $ soffice https://www.openoffice.org/ # Fails >>> $ soffice http://www.openoffice.org/ # Succeeds >>> $ soffice https://... # Succeeds for any site I put there, except ASF >>> sites, but I'd love to see a non-ASF example of a failing HTTPS site. >> Confirmed. HTTPS links fail, HTTP succeed > The HTTPS links all work for me with the FreeBSD port of 4.1.6. One > difference is that the FreeBSD port uses the system OpenSSL, currently > 1.02p or newer. > > Does the Apache web server still support TLS version 1.0? The old > version of OpenSSL that we bundle with the Windows and Linux versions > doesn't support anything newer than that. It looks like you found the real problem: $ curl -sviI --tlsv1.0 https://ooo-updates.apache.org/ * Trying 40.79.78.1... ... * TLSv1.0 (OUT), TLS handshake, Client hello (1): * TLSv1.0 (IN), TLS alert, Server hello (2): * error:1400442E:SSL routines:CONNECT_CR_SRVR_HELLO:tlsv1 alert protocol version Connection fails with options --tlsv1.0 and --tlsv1.1 but succeeds with --tlsv1.2. Which is in fact a good thing; TLSv1 and TLSv1.1 both have known security bugs. It is usually a bad idea to bundle OpenSSL instead of using the system-provided version; but if you do have to do that (e.g., on Windows, which doesn't have it, or macOS, which has an ancient version), at least use the latest 1.0.2 version, or even better, 1.1.0. -- Brane - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Check for Updates broken?
On 18.11.2018 18:41, Branko Čibej wrote: > On 18.11.2018 17:19, Andrea Pescetti wrote: >> Pedro Lino wrote: >>> However the AOO site does not specify any charset. Could that be the >>> problem? >> I don't think the charset is a major issue, but indeed (if I do the >> same test with openssl) there is something interesting that can >> probably be submitted to Infra for investigation. >> >> On any system I've tried with (CentOS, Ubuntu, Fedora) >> >> $ openssl s_client -state -nbio -connect ooo-updates.apache.org:443 >> >> will show (in a lengthy output that I don't have the time to debug >> now) that it is using this certificate: >> >> 0 s:/OU=Domain Control Validated/OU=EssentialSSL >> Wildcard/CN=*.openoffice.org >> >> Note that I requested apache.org and I get a certificate valid for >> *.openoffice.org. > The subject alternative names (which are the real identities that should > match, not the common name) are '*.openoffice.org' and 'openoffice.org'. > > And you're right ... the certificate is wrong ... but making the same > request with cURL will give the right certificate. Most likely that's > because s_client doesn't send the Server Name Indication that would let > HTTPd select the correct virtual host, so it'll select the "first" one. > > >> The same holds if I use just apache.org or openoffice.org > And this tends to prove the above assumption. And so does this: $ openssl s_client -state -nbio -servername ooo-updates.apache.org -connect ooo-updates.apache.org:443 Note the additional -servename option. -- Brane - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Check for Updates broken?
On 18.11.2018 17:19, Andrea Pescetti wrote: > Pedro Lino wrote: >> However the AOO site does not specify any charset. Could that be the >> problem? > > I don't think the charset is a major issue, but indeed (if I do the > same test with openssl) there is something interesting that can > probably be submitted to Infra for investigation. > > On any system I've tried with (CentOS, Ubuntu, Fedora) > > $ openssl s_client -state -nbio -connect ooo-updates.apache.org:443 > > will show (in a lengthy output that I don't have the time to debug > now) that it is using this certificate: > > 0 s:/OU=Domain Control Validated/OU=EssentialSSL > Wildcard/CN=*.openoffice.org > > Note that I requested apache.org and I get a certificate valid for > *.openoffice.org. The subject alternative names (which are the real identities that should match, not the common name) are '*.openoffice.org' and 'openoffice.org'. And you're right ... the certificate is wrong ... but making the same request with cURL will give the right certificate. Most likely that's because s_client doesn't send the Server Name Indication that would let HTTPd select the correct virtual host, so it'll select the "first" one. > The same holds if I use just apache.org or openoffice.org And this tends to prove the above assumption. > This mismatch itself doesn't explain much since the connection still > works, but it probably gives a hint for asking Infra why this happens. > > The output I get is very different depending on the system I use (I > get dozens of errors on some systems, a cleaner output in Ubuntu) but > in all cases openssl manages to connect in the end. I think it's best to gather all the info in this thread and create an Infra ticket. -- Brane
Re: Check for Updates broken?
On 17.11.2018 18:32, Andrea Pescetti wrote: > Dave Fisher wrote: >> I’ve been on with Infra on HipChat and both servers are the same with >> the same content internally, > > Yes, I don't see this as a major issue either. It is probably too > early for Infra to jump in, since we haven't identified major > network-related issues so far (yes, one of the two server does not > respond to ping and traceroute, but I can get updates from it > nevertheless). I mean, of course it doesn't harm but we need to shed > more light, see below. > >> I’m being asked for IP addresses to share so that can see if there is >> an IP ban happening. > > A ban is for sure not the case. > > Indeed, I have interesting news: I can reproduce the bug on an Ubuntu > system. My best bet at the moment is that something in the SSL > negotiation is wrong. > > A nice additional benefit is that this gives us a simple way to > reproduce the bug, equivalent to the update notification. > > $ soffice https://ooo-updates.apache.org/index.html > > (this fails on Ubuntu, succeeds on Fedora) > > Note that > > $ soffice https://www.google.com/ > > will work in all cases (so this is not an HTTPS bug per se) and > > $ soffice http://ooo-updates.apache.org/index.html > > will work in all cases (so this not a network issue but rather an SSL > issue). > > Now, debugging SSL issues is not easy, but can the people who don't > get updates at least confirm the three results above, i.e., that only > the first one fails? > > Further tests show that problematic systems have issues with ASF sites > in HTTPS, like: > $ soffice https://www.apache.org/ # Fails > $ soffice http://www.apache.org/ # Succeeds > $ soffice https://www.openoffice.org/ # Fails > $ soffice http://www.openoffice.org/ # Succeeds > $ soffice https://... # Succeeds for any site I put there, except ASF > sites, but I'd love to see a non-ASF example of a failing HTTPS site. > > If this is confirmed we are really close to a point where we could > actually get useful information from Infra. Note that all the sites that fail in your list have wildcard certificates — CN=*.apache.org for the Apache sites and CN=*.openoffice.org for the OO sites. This may be related to wildcard cert support in OpenSSL/LibreSSL/GnuTLS/whateveryou'reusing on the affected systems. Correlating this with the SSL library name and version would be useful. (I'm on macOS, so using Apple's crypto library which does support wildcard certs). For debugging, I suggest using cURL instead of OO, for example: curl -sviI https://www.openoffice.org/ -- Brane - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Check for Updates broken?
On Fri, 16 Nov 2018, 17:02 Andrea Pescetti Pedro Lino wrote: > >> On November 16, 2018 at 11:54 AM Andrea Pescetti wrote: > >> $ curl https://ooo-updates.apache.org/aoo416/check.Update > > > > > > > > http://installation.openoffice.org/description";> > > > > The network diagnostics are absolutely perfect (the fact that ncat had > to be terminated meant that it had managed to connect and it was waiting > for input, so that one is good too). > > In particular, the last output above shows that you can successfully > download the update feed to your computer. You can replace "416" in the > URL with the OpenOffice version you are actually running if you wish to > be 100% sure. In this case you will get a longer XML file for 4.1.4 and > earlier, since for 4.1.6 (and 4.1.5 as of today) we have the short empty > feed shown above, but for earlier versions we have the full update > information. > > Is the behavior above consistent? Like, if you alternate 5 times the > "curl, open OpenOffice, try updates, close OpenOffice" sequence, does > curl always succeed and OpenOffice always fail in downloading the feed? > > If yes, can you provide your OpenOffice version and Ubuntu version, so > that I can test with the same versions and see if I start seeing errors? > > Regards, >Andrea. I tried this today, just for fun. My curl etc. used the same IPv4 address as the other published results. Maybe the OO updater picks the other server and only that one has problems? -- Brane
Re: Does OpenOffice still use Serf?
On 15.11.2018 20:28, Matthias Seidel wrote: > Hi Pedro, > > Am 13.11.18 um 23:20 schrieb Pedro Lino: >>> On November 13, 2018 at 10:08 PM Andrea Pescetti >>> wrote: >>> 2. All WebDAV operations. You can find somewhere in Bugzilla a patch >>> that didn't make it to 4.1.2 due to excessive complexity (build >>> requirements). The Serf upgrade was meant to supplement WebDAV fixes in >>> 4.1.2. >>> >>> So you might want to focus testing on these two scenarios (the second >>> one will probably be tricky). >> I can help with testing this feature. I use AOO for editing files on a >> webdav folder. >> I use Windows 7 Pro, Ubuntu 16.04 and 18.04 (all x64) >> Let me know when the builds are ready ;) > I just gave up on building AOO with Serf 1.3.9... ;-) > > Given the problems with Scons mentioned by Andrea I think it is better > to focus on Serf 1.4.0 if we want to upgrade. Note that if you want to go this way (and I do recommend it), I suggest using Serf's trunk for now. The difference between trunk and the current 1.4.0 branch are a couple of bug fixes and the fact that trunk reports version 2.0. I also recommend using the CMake build — Serf can very handily be included as a subproject into another CMake tree, let me know if you need help with that, I can provide examples. -- Brane - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Does OpenOffice still use Serf?
On 14.11.2018 08:16, Peter kovacs wrote: > How about trying to open an URL as a test case? > > Is serf moving away from SCONs? I surely hope so. > I ask since we want to move to SCONs. An experience exchange would be great. Well ... SCons looks amazingly good in tiny examples, but when it comes to doing anything less than trivial, it's a nightmare. For example, I'm not thrilled that we have platform-specific Python code in Serf's SConstruct, and that's not even a very complex build at all. So, whilst I really hate CMake for its inconsistencies and homegrown horrible macro language, I like SCons quite a bit less. All of the above is my "humble" opinion of course. -- Brane > Am 13. November 2018 22:43:03 MEZ schrieb Matthias Seidel > : >> Hi Andrea, >> >> Am 13.11.18 um 22:23 schrieb Andrea Pescetti: >>> Matthias Seidel wrote: I think it would be a good idea to upgrade Serf in our builds. What about the others (real developers)? ;-) >>> Years ago, we had to avoid upgrading Serf in 4.1.x as Serf had >> started >>> to require SCons for the build and we didn't want to introduce yet >>> another build system since we already had too many. >>> >>> I see it still requires SCons, but probably we've included support >> for >>> SCons in trunk in the meantime, so... well, we decided we can live >>> with yet another build system! Still, I doubt we can use it for 4.1.x >>> as SCons integration would be needed and I don't think we support it >>> in 4.1.x. >> I forgot to mention that I indeed build with trunk. And the build is >> still going on, so anything can happen... ;-) >> >> I will keep you updated! >> >> Regards, >> >> Matthias >> >>> Regards, >>> Andrea. >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >>> For additional commands, e-mail: dev-h...@openoffice.apache.org >>> > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Does OpenOffice still use Serf?
On 13.11.2018 22:23, Andrea Pescetti wrote: > Matthias Seidel wrote: >> I think it would be a good idea to upgrade Serf in our builds. >> What about the others (real developers)? ;-) > > Years ago, we had to avoid upgrading Serf in 4.1.x as Serf had started > to require SCons for the build and we didn't want to introduce yet > another build system since we already had too many. I can surely relate to that ... > I see it still requires SCons, The 1.3.x branch does, but for 1.4.x and trunk, you can use CMake for most purposes. The CMake build currently doesn't support GSSAPI and BROTLI compression, but other than that it is (in my not so humble opinion) superior to the SCons build. > but probably we've included support for SCons in trunk in the > meantime, so... well, we decided we can live with yet another build > system! Still, I doubt we can use it for 4.1.x as SCons integration > would be needed and I don't think we support it in 4.1.x. That's OK, any kind of testing, even with OO trunk, would be welcome. The only other Serf consumer I can test is Subversion, adding even one more would make out real-life testing increase by 100%. :) -- Brane - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Does OpenOffice still use Serf?
On 13.11.2018 21:49, Matthias Seidel wrote: > Hi Branko, Hi all, > > Am 13.11.18 um 12:39 schrieb Branko Čibej: >> Hi all, >> >> I'm writing here because I believe OpenOffice uses Serf as its HTTP >> client; at least I did find version 1.2.1 mentioned in the patch files >> in ext_libraries/serf. > It is even mentioned on your project page. ;-) Yes, and in our Board reports, one of which I posted today ... and that made me wonder and eventually write a mail to this list. :) -- Brane - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Does OpenOffice still use Serf?
Hi all, I'm writing here because I believe OpenOffice uses Serf as its HTTP client; at least I did find version 1.2.1 mentioned in the patch files in ext_libraries/serf. I would like to ask for help from the OpenOffice developers to test the next release of Serf. We — the Apache Serf project — are in the (very slow) process of finally releasing Serf version 1.4.0, and it would be helpful if we could get some feedback from testing it. This version should be source-compatible with 1.2.1, but the build system has been completely changed since then; the supported build uses scons but there's also a fairly complete CMake build. Major improvements include support for HTTP/2, FCGI, CRL, OCSP stapling and OCSP requests, OpenSSL 1.1.x and and of course a large number of bug fixes. For details, see: https://s.apache.org/9259 If you're able and willing to help, please respond here, or post to . Thanks! -- Brane - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
