Re: test failure due to xmlsec

Il 07/01/25 16:41, Michael Stahl - michael.stahl at allotropia.de ha scritto: > > On 19/12/2024 07:59, Mattia Verga wrote: >> Il 18/12/24 20:49, Mattia Verga ha scritto: >>> Il 18/12/24 19:05, Thorsten Behrens - thb at libreoffice.org ha scritto: Hi Mattia, Mattia Verga wrote: >

Re: test failure due to xmlsec

On 19/12/2024 07:59, Mattia Verga wrote: Il 18/12/24 20:49, Mattia Verga ha scritto: Il 18/12/24 19:05, Thorsten Behrens - thb at libreoffice.org ha scritto: Hi Mattia, Mattia Verga wrote: I've been trying to build LO 25.2.0.0.beta1 on Fedora Rawhide and saw a new test failure in /builddi

Re: test failure due to xmlsec

On Wed, 2024-12-18 at 17:26 +, Mattia Verga wrote: > I've been trying to build LO 25.2.0.0.beta1 on Fedora Rawhide and saw > a > new test failure in > > /builddir/build/BUILD/libreoffice-25.2.0.0-build/libreoffice- > 25.2.0.0.beta1/xmlsecurity/qa/xmlsec/xmlsec.cxx:100:(anonymous > namespace)

Re: test failure due to xmlsec

Hi Mattia, On Sun, Dec 22, 2024 at 10:36:33AM +, Mattia Verga wrote: > > I tried to build 25.2.0.0.beta1 first with system's xmlsec1 1.2.41, > > then with bundled 1.3.0 and 1.3.6. That test always fails, so there's > > something else in Fedora that doesn't like it. > > > > I'm not sure how

Re: test failure due to xmlsec

Il 22/12/24 11:26, Mattia Verga ha scritto: > Il 19/12/24 09:19, Miklos Vajna - vmiklos at collabora.com ha scritto: >> Hi Mattia, >> >> On Thu, Dec 19, 2024 at 06:59:33AM +, Mattia Verga >> wrote: >>> I got the same failure with the patch applied... I'll set up a virtual >>> machine to build

Re: test failure due to xmlsec

Il 19/12/24 09:19, Miklos Vajna - vmiklos at collabora.com ha scritto: > Hi Mattia, > > On Thu, Dec 19, 2024 at 06:59:33AM +, Mattia Verga > wrote: >> I got the same failure with the patch applied... I'll set up a virtual >> machine to build LO in different combinations LO/xmlsec and see wher

Re: test failure due to xmlsec

Hi Mattia, On Thu, Dec 19, 2024 at 06:59:33AM +, Mattia Verga wrote: > I got the same failure with the patch applied... I'll set up a virtual > machine to build LO in different combinations LO/xmlsec and see where > the test passes or fails. I added that test suite (with a single test) re

Re: test failure due to xmlsec

Il 18/12/24 20:49, Mattia Verga ha scritto: > Il 18/12/24 19:05, Thorsten Behrens - thb at libreoffice.org ha scritto: >> Hi Mattia, >> >> Mattia Verga wrote: >>> I've been trying to build LO 25.2.0.0.beta1 on Fedora Rawhide and saw a >>> new test failure in >>> >>> /builddir/build/BUILD/libreoffic

Re: test failure due to xmlsec

Il 18/12/24 19:05, Thorsten Behrens - thb at libreoffice.org ha scritto: > Hi Mattia, > > Mattia Verga wrote: >> I've been trying to build LO 25.2.0.0.beta1 on Fedora Rawhide and saw a >> new test failure in >> >> /builddir/build/BUILD/libreoffice-25.2.0.0-build/libreoffice-25.2.0.0.beta1/xmlsecuri

Re: test failure due to xmlsec

Hi Mattia, Mattia Verga wrote: > I've been trying to build LO 25.2.0.0.beta1 on Fedora Rawhide and saw a > new test failure in > > /builddir/build/BUILD/libreoffice-25.2.0.0-build/libreoffice-25.2.0.0.beta1/xmlsecurity/qa/xmlsec/xmlsec.cxx:100:(anonymous > > namespace)::testInsertPrivateKey::T

Re: Test failure in embeddedobj on some Windows systems

On 30/11/2022 14:03, Mike Kaganski wrote: FTR: this issue has already surfaced once on the IRC, and I recall that we tracked it down to the MS Paint OLE registration issues specific to Windows 11 (the unit test uses the "mspaint data"). Oh my, thanks for reminding me, we'd already discussed th

Re: Test failure in embeddedobj on some Windows systems

On 30.11.2022 14:45, Stephan Bergmann wrote: block in OleComponent::GetExtent (embeddedobj/source/msole/olecomponent.cxx) and into its call (done on a different thread, by that syncExecute) of void OleComponent::RunObject() {     OSL_ENSURE( m_pNativeImpl->m_pOleObject, "The pointer can not

Re: Test failure in embeddedobj on some Windows systems

On 30/11/2022 11:45, Mike Kaganski wrote: On 30.11.2022 13:18, Stephan Bergmann wrote: If anybody has an (explicitly, or implicitly via --enable-debug or --enable-dbgutil) --enable-sal-log Windows build for which CppunitTest_embeddedobj_msole succeeds and fully executes that above testSaveOnTh

Re: Test failure in embeddedobj on some Windows systems

On 30.11.2022 13:18, Stephan Bergmann wrote: If anybody has an (explicitly, or implicitly via --enable-debug or --enable-dbgutil) --enable-sal-log Windows build for which CppunitTest_embeddedobj_msole succeeds and fully executes that above testSaveOnThread because it is run with 96 DPI (so that

Re: Test failure in embeddedobj on some Windows systems

On 19/11/2022 15:37, Ilmari Lauhakangas wrote: I asked Hossein how the new dev could continue debugging the issue and he looked into it a bit: "as I understand from the code, the checks does not happen when the DPI is not 96, in which I think most of the today's displays are not. embeddedobj

Re: Test failure on some Windows systems with 125% display scaling, Chart2ImportTest::testAutomaticSizeBarChartVeryLongLabel

Hi, On Sun, Nov 20, 2022 at 03:06:16PM +0100, Regina Henschel wrote: > In this case a tolerance is no solution. The text box which is generated by > the automatic indeed differs between 96 dpi and 120 dpi, see attached > screenshots. One has six, the other has seven words in the line. > > We ca

Re: Test failure on some Windows systems with 125% display scaling, Chart2ImportTest::testAutomaticSizeBarChartVeryLongLabel

Hi Ilmari, Ilmari Lauhakangas schrieb am 19.11.2022 um 15:41: A new dev is seeing this test failure on Windows with 125% scaling, the test passes if scaling is set to 100%: C:/cygwin/home/Client/lode/dev/core/chart2/qa/extras/chart2import.cxx(2273) : error : Assertion Test name: Chart2Import

Re: Test failure

On Wed, Oct 09, 2013 at 04:56:18PM +0200, Stephan Bergmann wrote: > ...not to mention gengal flashing windows at least on Mac OS X > during a plain "make". As a start, enables all (except one) DOCX

Re: Test failure

On Wed, Oct 09, 2013 at 07:58:52PM +0200, Michael Stahl wrote: > IMHO this disabling of tests based on OS needs to end. I just tried enabling the sw filter tests on Mac, but some fixing is needed there: https://gerrit.libreoffice.org/#/c/6182/ Possibly only RTF is problematic and the rest can

Re: Test failure

On 09/10/13 16:25, Miklos Vajna wrote: > On Wed, Oct 09, 2013 at 03:01:02PM +0200, Stephan Bergmann > wrote: >> Just curious, but at least in general there's nothing in our code >> base to imply "OSX" means "without unit tests." > > I was speaking about the Writer filter tests. Those are Linux-o

Re: Test failure

On 10/09/2013 04:44 PM, Miklos Vajna wrote: (I imagine people who run 'make check' are the same ones who use dbgutil and werror. :) ) i.e., virtually everybody? ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.o

Re: Test failure

On 10/09/2013 04:32 PM, Tor Lillqvist wrote: IIRC the reason for that is --headless not really working on Windows/Mac, or something like that. But we already have other tests that cheerfully flash windows on and off for several minutes when one runs "make" on Windows and OS X. ...not to ment

Re: Test failure

>> Maybe those Writer test should be moved to be done only for "make >> check", and enabled for all platforms? > > My fear is that ATM if one of those Writer filter checks got broken, > tinderboxes go red, we spam committers, and that's annoying enough that > the problem gets fixed ASAP. For 'make

Re: Test failure

On Wed, Oct 09, 2013 at 05:32:18PM +0300, Tor Lillqvist wrote: > But we already have other tests that cheerfully flash windows on and > off for several minutes when one runs "make" on Windows and OS X. > > Or maybe it's only for "make check"? I don't remember, I nowadays tend > to do "make check

Re: Test failure

> IIRC the reason for that is --headless not really working on > Windows/Mac, or something like that. But we already have other tests that cheerfully flash windows on and off for several minutes when one runs "make" on Windows and OS X. Or maybe it's only for "make check"? I don't remember, I no

Re: Test failure

On Wed, Oct 09, 2013 at 03:01:02PM +0200, Stephan Bergmann wrote: > Just curious, but at least in general there's nothing in our code > base to imply "OSX" means "without unit tests." I was speaking about the Writer filter tests. Those are Linux-only, e.g.: http://opengrok.libreoffice.org/xref/

Re: Test failure

On 10/08/2013 08:27 PM, Siqi Liu wrote: My previous patch was tested (on OSX so without unit tests) during the Just curious, but at least in general there's nothing in our code base to imply "OSX" means "without unit tests." Stephan ___ LibreOffic

Re: Test failure

Hi Siqi, On Tue, Oct 08, 2013 at 08:27:46PM +0200, Siqi Liu wrote: > That is, whenever we reverse the hex value (the expected value) for the > unit test, the actual value coming out of the test is surprisingly reversed > as well!! Which I failed to explain... We have a relatively detailed descri

Re: Test failure

2013/10/8 Siqi Liu > Hello all, > > Hi, > I've been investigating on this issue and I've tried the patch from Julien > and it still doesn't seem to fix the problem. There unit test always fails > on the equality assertion even if we reverse that as well. > > Here is what I've got: > > When we ch

Re: Test failure

Hello all, I've been investigating on this issue and I've tried the patch from Julien and it still doesn't seem to fix the problem. There unit test always fails on the equality assertion even if we reverse that as well. Here is what I've got: When we check against sal_Int32(0xD99594) (i.e. 14259

Re: Test failure

Hello all, Sorry for the late response! This was a patch that I've submitted during the hackathon in Milan and it fixes the #fdo65295 on bugzilla. Actually we've analyzed the content of the .docx exported by writer and it seems that the startColor and the endColor were accidentally reversed so th

Re: Test failure

Hi, If StartColor and EndColor have been reversed, perhaps it was the same for qa part? So what about this patch? diff --git a/sw/qa/extras/ooxmlexport/ooxmlexport.cxx b/sw/qa/extras/ooxmlexport/ooxmlexport.cxx index f771ef9..8fdb7fb 100644 --- a/sw/qa/extras/ooxmlexport/ooxmlexport.cxx +++ b/sw/q

Re: Test failure

Le 05/10/2013 22:45, Samuel Mehrbrodt a écrit : > Hi, > > the tests don't pass after your commit > http://cgit.freedesktop.org/libreoffice/core/commit/?id=4a96bc0c0eda8aff6c165bb6a79eb95f2926bb10 Indeed reverting this commit make the build successful. Best regards. JBF -- Seuls des formats ouv