tia,
>>>>
>>>> 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/libreof
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 failu
Il 28/12/24 14:46, Mattia Verga ha scritto:
> Il 28/12/24 12:31, Caolán McNamara - caolan.mcnamara at collabora.com
> ha scritto:
>> On Sat, 2024-12-28 at 09:41 +, Mattia Verga wrote:
>>> WHile running tests for 25.2.0.1 I see a new test failure:
>>>
&g
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:
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
Il 28/12/24 12:31, Caolán McNamara - caolan.mcnamara at collabora.com ha
scritto:
> On Sat, 2024-12-28 at 09:41 +, Mattia Verga wrote:
>> WHile running tests for 25.2.0.1 I see a new test failure:
>>
>> file:///builddir/build/BUILD/libreoffice-25.2.0.1-build/libreoffic
On Sat, 2024-12-28 at 09:41 +, Mattia Verga wrote:
> WHile running tests for 25.2.0.1 I see a new test failure:
>
> file:///builddir/build/BUILD/libreoffice-25.2.0.1-build/libreoffice-
> 25.2.0.1//sw/qa/extras/layout/data//tdf157829-ltr.fodt:
> (anonymous namespace)::T
WHile running tests for 25.2.0.1 I see a new test failure:
file:///builddir/build/BUILD/libreoffice-25.2.0.1-build/libreoffice-25.2.0.1//sw/qa/extras/layout/data//tdf157829-ltr.fodt:
(anonymous namespace)::TestTdf157829LTR::TestBody finished in: 42ms
[_RUN_] (anonymous namespace
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
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
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
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 t
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.
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
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::TestBody
equality assertion f
Hi Dan,
On Tuesday, 2023-09-05 18:53:37 +0200, Dan Horák wrote:
> seems the recent change [1] to KahanSum handling causes a test failure
> on ppc64le.
That should be fixed now with
https://gerrit.libreoffice.org/c/core/+/156899
and cherry-picks are pending for 7-6, 7-5 and 7-5-8.
Unfortu
Hi Stephan,
On Fri, Sep 29, 2023 at 01:02:10PM +0200, Stephan Bergmann
wrote:
> > OTOH, I believe this workaround can fix your build while keeping other
> > builds happy as well: https://gerrit.libreoffice.org/c/core/+/157403
>
> Thanks. But no idea whether or not that is the right approach fo
On 9/29/23 12:00, Xisco Fauli wrote:
I don't have any idea why this is happening, Do you know more or less
when this failure started to happen?
Can't remember. Definitely for some weeks now. (First saw it happen
with one of the build setups on the machine, but shelved it for later
inspectio
Hello Stephan,
On 29/9/23 9:24, Stephan Bergmann wrote:
but which would of course break things for all the other builds that
now succeed.)
Does anybody have an idea what could cause this difference in the
dumped XML?
I don't have any idea why this is happening, Do you know more or less
wh
> On 29 Sep 2023, at 10:00 AM, Mattia Verga
> wrote:
>
> Hi,
>
> Fedora upgraded harfbuzz from version 8.1 to 8.2 and as a result this
> test started to fail:
This is an upstream regression, see
https://github.com/harfbuzz/harfbuzz/issues/4414.
Regards,
Khaled
On my Linux machine, CppunitTest_svgio keeps failing with
xmltesttools.cxx:95:Assertion
Test name: testTdf97542_1::TestBody
equality assertion failed
- Expected: 1
- Actual : 0
- In <>, XPath '/primitive2D/transform/objectinfo/textsimpleportion' number of
nodes is incorrect
xmltesttools.cxx:9
Hi,
Fedora upgraded harfbuzz from version 8.1 to 8.2 and as a result this
test started to fail:
[_RUN_] FontFeatureTest::testGetFontFeaturesGraphite
FontFeatureTest::testGetFontFeaturesGraphite finished in: 0ms
[_RUN_] FontFeatureTest::testGetFontFeaturesOpenType
FontFeatureTest::testGet
On 9/13/23 13:58, Eike Rathke wrote:
On Wednesday, 2023-09-13 13:45:36 +0200, Dan Horák wrote:
It would be worth a try to simply call executeFast() only if SC_USE_SSE2
is defined, so the failing platforms skip executeUnrolled(), here
https://opengrok.libreoffice.org/xref/core/sc/inc/arraysumfunc
Hi Dan,
On Wednesday, 2023-09-13 13:45:36 +0200, Dan Horák wrote:
> > It would be worth a try to simply call executeFast() only if SC_USE_SSE2
> > is defined, so the failing platforms skip executeUnrolled(), here
> > https://opengrok.libreoffice.org/xref/core/sc/inc/arraysumfunctor.hxx?r=7f15354c
> > > On 9/5/23 18:53, Dan Horák wrote:
> > > > > seems the recent change [1] to KahanSum handling causes a test failure
> > > > > on ppc64le.
> > > > >
> > > > > Running scope as unit:
> > > > > -home-sharkcz-pr
Hi,
On Thursday, 2023-09-07 11:36:33 +0200, Stephan Bergmann wrote:
> On 9/7/23 08:25, Dan Horák wrote:
> > On Thu, 7 Sep 2023 08:16:28 +0200
> > Stephan Bergmann wrote:
> > > On 9/5/23 18:53, Dan Horák wrote:
> > > > seems the recent change [1] to Kah
On Thu, 7 Sep 2023 11:36:33 +0200
Stephan Bergmann wrote:
> On 9/7/23 08:25, Dan Horák wrote:
> > On Thu, 7 Sep 2023 08:16:28 +0200
> > Stephan Bergmann wrote:
> >> On 9/5/23 18:53, Dan Horák wrote:
> >>> seems the recent change [1] to KahanSum handling ca
On 9/7/23 08:25, Dan Horák wrote:
On Thu, 7 Sep 2023 08:16:28 +0200
Stephan Bergmann wrote:
On 9/5/23 18:53, Dan Horák wrote:
seems the recent change [1] to KahanSum handling causes a test failure
on ppc64le.
Running scope as unit:
-home-sharkcz-projects-libreoffice-workdir-CppunitTest
it makes sense (and helps) :-)
Dan
> On 6/9/23 15:41, Dan Horák wrote:
> > On Tue, 5 Sep 2023 18:53:37 +0200
> > Dan Horák wrote:
> >
> >> Hello,
> >>
> >> seems the recent change [1] to KahanSum handling causes a test fail
On Thu, 7 Sep 2023 08:16:28 +0200
Stephan Bergmann wrote:
> On 9/5/23 18:53, Dan Horák wrote:
> > seems the recent change [1] to KahanSum handling causes a test failure
> > on ppc64le.
> >
> > Running scope as unit:
> > -home-sharkcz-project
On 9/5/23 18:53, Dan Horák wrote:
seems the recent change [1] to KahanSum handling causes a test failure
on ppc64le.
Running scope as unit:
-home-sharkcz-projects-libreoffice-workdir-CppunitTest-sc_statistical_functions_test.test:20230905152639:2378561.scope
[_RUN_
the recent change [1] to KahanSum handling causes a test failure
on ppc64le.
[1] https://git.libreoffice.org/core/+/1f8cc7644293e62ad6430bbeec243d3283e478d7
and with the change reverted I am getting a failure in
CppunitTest_sc_ucalc_formula2
...
testTdf147398::TestBody finished in: 11ms
[_RUN_] tes
On Tue, 5 Sep 2023 18:53:37 +0200
Dan Horák wrote:
> Hello,
>
> seems the recent change [1] to KahanSum handling causes a test failure
> on ppc64le.
>
> [1]
> https://git.libreoffice.org/core/+/1f8cc7644293e62ad6430bbeec243d3283e478d7
and with the change reverted I am
Hello,
seems the recent change [1] to KahanSum handling causes a test failure
on ppc64le.
Running scope as unit:
-home-sharkcz-projects-libreoffice-workdir-CppunitTest-sc_statistical_functions_test.test:20230905152639:2378561.scope
[_RUN_] StatisticalFunctionsTest
Hello Miklos,
On 8/3/23 9:09, Miklos Vajna wrote:
Hi Xisco,
On Fri, Mar 03, 2023 at 12:43:38PM +0100, Xisco Fauli
wrote:
Unfortunately I don't feel brave enough to change this. Is there anyone
familiar with this part of the code willing to give it a try? otherwise, I
can at least report it i
Hi Xisco,
On Fri, Mar 03, 2023 at 12:43:38PM +0100, Xisco Fauli
wrote:
> Unfortunately I don't feel brave enough to change this. Is there anyone
> familiar with this part of the code willing to give it a try? otherwise, I
> can at least report it in Bugzilla so it doesn't get lost
Please see if
Hello Miklos,
On 3/3/23 8:56, Miklos Vajna wrote:
Hmm, it feels like this is an improvement, but the root cause is why we
have a static counter for charts in the first place. Do you know where
is that counter?
There are two, the one for sc is in
sc/source/filter/excel/xeescher.cxx:1607, added
Hi Xisco,
On Thu, Mar 02, 2023 at 09:31:24AM +0100, Xisco Fauli
wrote:
> Yes, you were right. There is a static counter that increments the chart
> export file names so it failed to find 'xl/charts/chart1.xml' because it was
> exported as 'xl/charts/chart2.xml'
>
> Markus already added a mechan
Hi Miklos
On 27/2/23 8:18, Miklos Vajna wrote:
My first guess would be some static variable, but who knows.
Yes, you were right. There is a static counter that increments the chart
export file names so it failed to find 'xl/charts/chart1.xml' because it
was exported as 'xl/charts/chart2.xml'
Hi Xisco,
On Fri, Feb 24, 2023 at 02:40:23PM +0100, Xisco Fauli
wrote:
> it seems there is a test in sc/qa/unit/subsequent_export_test2.cxx that
> fails depending on the order of execution.
>
> If testTdf121260 is executed before testTdf107586, then it passes,
> otherwise, it fails with
>
> ##
Hello,
it seems there is a test in sc/qa/unit/subsequent_export_test2.cxx that
fails depending on the order of execution.
If testTdf121260 is executed before testTdf107586, then it passes,
otherwise, it fails with
##Failure Location unknown## : Error
Test name: ScExportTest2::testTdf121260
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
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
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
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
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
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
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
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: Chart2ImportTest::testAutomaticSizeBarChartVeryLongLabel
double equality
This failure was first observed in September this year and now another
new dev is facing it:
C:/cygwin/home/Client/lode/dev/core/test/source/xmltesttools.cxx(174) :
error : Assertion
Test name: testSaveOnThread::TestBody
equality assertion failed
- Expected: 0.1665in
- Actual : 1.9685in
- In
>
> Thanks for suggestions.
> Actually, I've already prepared https://gerrit.libreoffice.org/69458 -
> does it look reasonable?
>
Hi Mike,
Yes, that's also a good solution.
Best Regards,
Tamás
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.
Hi Luke, Tamás,
On 20.03.2019 9:39, Tamás Zolnai wrote:
Hi guys,
Don't waste to much time on this issue. You can just increase the
delta (INT_EPS) to a bigger value for 32 bit windows systems and
that's all. I think it's enough if the precise values are checked on
64 bit systems. This is a k
Hi guys,
Don't waste to much time on this issue. You can just increase the delta
(INT_EPS) to a bigger value for 32 bit windows systems and that's all. I
think it's enough if the precise values are checked on 64 bit systems. This
is a known issue that checking the positions of chart components is
Hey Mike,
After
https://cgit.freedesktop.org/libreoffice/core/commit/?id=166a4989a0d1e5a6271c66bceb73a27970afc882
tdf#123504: 0 and 360 are different angles in charts
My 32-bit Windows box is failing with the following error:
ChartDataTest::verify finished in: 2796ms
PivotChartDataButtonTest::
Am 27.09.2018 um 08:28 schrieb Noel Grandin:
> On Thu, 27 Sep 2018 at 08:28, Noel Grandin wrote:
>> On Wed, 26 Sep 2018 at 23:58, Jan-Marek Glogowski
>> wrote:
>>
>>> For me it looks like a multi-threaded problem, where something isn't
>>> correct processed in order. I can reproduce crashes when
On Thu, 27 Sep 2018 at 08:28, Noel Grandin wrote:
>
>
> On Wed, 26 Sep 2018 at 23:58, Jan-Marek Glogowski
> wrote:
>
>> For me it looks like a multi-threaded problem, where something isn't
>> correct processed in order. I can reproduce crashes when I run a very
>> parallel make check often, but
On Wed, 26 Sep 2018 at 23:58, Jan-Marek Glogowski wrote:
> For me it looks like a multi-threaded problem, where something isn't
> correct processed in order. I can reproduce crashes when I run a very
> parallel make check often, but never was able to get something in a
> debugger...
>
>
mst
_
Hi Luke,
failures for CppunitTest_vcl_complextext have been around for a few months.
Nobody is able to reproduce them. IMHO they fail most time with loading of the
wrong font.
Looking at the current state of
https://tinderbox.libreoffice.org/MASTER/status.html, the master Jenkins
Windows buil
Over the years, I've probably done several hundred windows builds. Until now I
have never been bitten an intermittent Unit Test failures. This month, I have
started to see fairly regular failure of VclComplexTextTest::testArabic 3 out
of ~15 builds.
Here are 2 separate examples of the Jenkins_W
On 10/03/18 19:53, Luke Benes wrote:
https://gerrit.libreoffice.org/#/c/50978/ - can you try if that fixes your
issue?
Unfortunately, the build is still failing with this patch. Do you want anything
from the logs?
That matches my understanding (as expressed in the gerrit change), that,
to
> https://gerrit.libreoffice.org/#/c/50978/ - can you try if that fixes your
> issue?
Unfortunately, the build is still failing with this patch. Do you want anything
from the logs?
To reproduce this yourself, you can copy your source tree to a folder as deep
as mine. As I said earlier, by co
I wrote:
> I'll mull over if we can somehow prevent that for this test...
>
https://gerrit.libreoffice.org/#/c/50978/ - can you try if that fixes
your issue?
Cheers,
-- Thorsten
signature.asc
Description: Digital signature
___
LibreOffice mailing lis
Hi Luke,
this one indeed clears it up:
Luke Benes wrote:
> [pid 24144] write(2, "gpg: can't connect to the agent: File name too
> long", 51) = 51
>
This is quite unexpected. There's a thread about it on the upstream
gpg list:
https://lists.gt.net/gnupg/users/79522
I'll mull over if we can someh
On 08.03.2018 04:59, Luke Benes wrote:
> Sorry, copy/paste error. Here is the correct URL:
>
> https://gist.githubusercontent.com/slacka/412bea7ad1012cb60dac6af583712736/raw/3b8309b7a5dd568c35eb6758edbb15e771e290d2/strace2.txt
>
> [pid 24144] write(2, "gpg: can't connect to the agent: File name
Sorry, copy/paste error. Here is the correct URL:
https://gist.githubusercontent.com/slacka/412bea7ad1012cb60dac6af583712736/raw/3b8309b7a5dd568c35eb6758edbb15e771e290d2/strace2.txt
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://l
Here is the updated strace log:
https://gist.githubusercontent.com/slacka/412bea7ad1012cb60dac6af583712736/raw/3b8309b7a5dd568c35eb6758edbb15e771e290d2/strace2.
Made with $ make CppunitTest_xmlsecurity_signing CPPUNITTRACE="strace -f -s 77"
2>&1 | tee trace.log
Let me know if there's anything
On 07.03.2018 01:10, Luke Benes wrote:
> Here is the strace log:
>
> https://gist.githubusercontent.com/slacka/a07fac3b1ab0396df066968e2e216c8d/raw/6e1b1414b9db9da04a306a00dd27e1446f9e1377/strace.txt
>
> Let me know if there's anything else I can do to help.
gpg fails with:
[pid 19515] write(2,
Here is the strace log:
https://gist.githubusercontent.com/slacka/a07fac3b1ab0396df066968e2e216c8d/raw/6e1b1414b9db9da04a306a00dd27e1446f9e1377/strace.txt
Let me know if there's anything else I can do to help.
___
LibreOffice mailing list
LibreOffice@li
One more clue as to what is going on. I copied the source tree from my external
HD to my home folder and the rebuilt. This time the build succeeded without any
errors.
There something about the path on my system that's triggering this bug.
___
LibreOf
Here is the new backtrace:
https://pastebin.com/uKsUJMUX
$ cat autogen.input
--enable-debug
So I think optimizations are all disabled.
Let me know if that helps.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedeskto
Luke Benes wrote:
> Let me know if there is anything else I can do to help.
>
Hi Luke,
terribly sorry, but the BTs still don't give any useful hint at what's
going wrong. Are you building with optimisation? Since appopen.cxx:240
really contains no throwing (but the called function
decryptGpgSessi
This was fixed by
https://cgit.freedesktop.org/libreoffice/core/commit/?id=4beed2ba7335fdb211aca7f70a144ffecf90a781
Thanks Noel!
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libre
should be fixed now with
https://cgit.freedesktop.org/libreoffice/core/commit/?id=4beed2ba7335fdb211aca7f70a144ffecf90a781
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice
After
https://cgit.freedesktop.org/libreoffice/core/commit/?id=0d9f3f7628f88fa66aaeea1f7148db620e17e728
I'm seeing the following Unit Test Failure under Arch with both gcc and clang:
[CUT] cppcanvas_emfplus
[DEP] LNK:CppunitTest/libtest_sd_import_tests.so
[LNK] Cppuni
Subject: Re: CppunitTest_xmlsecurity_signing Unit Test Failure on 32-bit Linux
Luke Benes wrote:
> This was on my 64-bit Ubuntu 17.10 box. Anything useful here?
>
Hi Luke,
no, not really - could you please do the 'catch throw' part, too, from
my earlier mail? And then si
Luke Benes wrote:
> This was on my 64-bit Ubuntu 17.10 box. Anything useful here?
>
Hi Luke,
no, not really - could you please do the 'catch throw' part, too, from
my earlier mail? And then single-step inside appopen.cxx, until you
hit an exception?
Cheers,
-- Thorsten
signature.asc
Descripti
Unit Test Failure on 32-bit Linux
Hi Luke,
Luke Benes wrote:
> This is not a 32/64 bit issue, as I'm seeing this on my 64 bit
> Ubuntu 17.10 system. The full, unedited log built with
> SAL_LOG="+WARN.+INFO.xmlsecurity+INFO.comphelper.crypto"
>
Hmm, nothing really he
Hi Luke,
Luke Benes wrote:
> This is not a 32/64 bit issue, as I'm seeing this on my 64 bit
> Ubuntu 17.10 system. The full, unedited log built with
> SAL_LOG="+WARN.+INFO.xmlsecurity+INFO.comphelper.crypto"
>
Hmm, nothing really helpful standing out there. If you please could:
make CppunitTest_
On Mon, Jan 29, 2018 at 05:14:35PM +0700, Andika Triwidada wrote:
> > Anyways, for now I did add that patch to my disable-flaky-tests.diff
> > (just the encrypt test)
>
> something like this?
>
> $ git diff
> diff --git a/xmlsecurity/qa/unit/signing/signing.cxx
> b/xmlsecurity/qa/unit/signing/sig
On Sun, Jan 28, 2018 at 8:16 PM, Rene Engelhard wrote:
> Hi,
>
> On Sun, Jan 28, 2018 at 08:03:58PM +0700, Andika Triwidada wrote:
>> On Sun, Jan 28, 2018 at 12:31 AM, Rene Engelhard wrote:
>> > On Sat, Jan 27, 2018 at 06:20:04PM +0100, Rene Engelhard wrote:
>> >> On Mon, Jan 22, 2018 at 09:03:06
On Mon, Jan 22, 2018 at 09:03:06PM +, Luke Benes wrote:
> The previous log was heavily trimmed to reduce size. While the OS is
> different both builds share the same external drive. Could the path length be
> a problem? (I trimmed the full path in the previous log) Or could this be
> like t
Hi,
On Sun, Jan 28, 2018 at 08:03:58PM +0700, Andika Triwidada wrote:
> On Sun, Jan 28, 2018 at 12:31 AM, Rene Engelhard wrote:
> > On Sat, Jan 27, 2018 at 06:20:04PM +0100, Rene Engelhard wrote:
> >> On Mon, Jan 22, 2018 at 09:03:06PM +, Luke Benes wrote:
> >> > The previous log was heavily
On Sun, Jan 28, 2018 at 12:31 AM, Rene Engelhard wrote:
> On Sat, Jan 27, 2018 at 06:20:04PM +0100, Rene Engelhard wrote:
>> On Mon, Jan 22, 2018 at 09:03:06PM +, Luke Benes wrote:
>> > The previous log was heavily trimmed to reduce size. While the OS is
>> > different both builds share the
On Sat, Jan 27, 2018 at 06:20:04PM +0100, Rene Engelhard wrote:
> On Mon, Jan 22, 2018 at 09:03:06PM +, Luke Benes wrote:
> > The previous log was heavily trimmed to reduce size. While the OS is
> > different both builds share the same external drive. Could the path length
> > be a problem?
This is not a 32/64 bit issue, as I'm seeing this on my 64 bit Ubuntu 17.10
system. The full, unedited log built with
SAL_LOG="+WARN.+INFO.xmlsecurity+INFO.comphelper.crypto"
Can be found here:
https://pastebin.com/inwx0Hu0
The previous log was heavily trimmed to reduce size. While the OS i
With both gcc and clang on Fedora 25, the build is failing with an assertion
failure. This issue started with commit:
https://cgit.freedesktop.org/libreoffice/core/commit/?id=8242c22f84cef1bbc8c385875b2da4713b542329
[CUT] xmlsecurity_signing
SigningTest::testODFBrokenStreamGPG finished in: 639ms
Luke Benes wrote:
> /core/unotest/source/cpp/macros_test.cxx:52:SigningTest::testODFEncryptedGPG
> assertion failed
> - Expression: xComponent.is()
> - loading failed:
> file:///core//xmlsecurity/qa/unit/signing/data/encryptedGPG.odt
>
Hi Luke,
this is weird - path is constructed exactly the sam
Hi,
On Thu, Dec 15, 2016 at 11:57:43AM -0700, slacka wrote:
> If someone wants to dig deeper, I’d be glad to run special debug builds like
> I did for Ashod’s failing Unit tests.
>
> Or, should we just blacklist my driver? What info do you need for that?
See officecfg/registry/schema/org/openof
-after-OS-reinstall-causing-Unit-Test-Failure-tp4202419p4202823.html
Sent from the Dev mailing list archive at Nabble.com.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Hey,
On Thu, Dec 15, 2016 at 12:35 PM, slacka wrote:
> Niklas Johansson wrote
> Is it the only OpenCL test that fails for you?
>
> Yes, Build finishes without error after I comment the
> testFinancialXirrFormula out. Afterwards when I open:
> core\sc\qa\unit\data\ods\opencl\financial\XIRR.ods Th
uke
--
View this message in context:
http://nabble.documentfoundation.org/OpenCL-enabled-by-default-after-OS-reinstall-causing-Unit-Test-Failure-tp4202419p4202785.html
Sent from the Dev mailing list archive at Nabble.com.___
LibreOffice mailing list
LibreOff
Hi
On 2016-12-15 01:14, slacka wrote:
the build still failed on Test name: ScOpenCLTest::testFinancialXirrFormula
Is it the only OpenCL test that fails for you?
The specific test you refer to has been failing for me for a long time
(months), though I'm sorry to say that I haven't had the ti
tools (ex make 4.0
-> 4.2)? Do we really want LODE to always use the newest version, with
everyone’s LODE install slightly different based on when they ran it.
--
View this message in context:
http://nabble.documentfoundation.org/OpenCL-enabled-by-default-after-OS-reinstall-causing-Unit
> it's not the first time OpenCL seems to break builds, for example:
>
So all build breaks must therefore be OpenCL related? OK then.
--tml
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/lib
Hi,
What makes you think there is anything OpenCL-related in there?
it's not the first time OpenCL seems to break builds, for example:
https://lists.freedesktop.org/archives/libreoffice/2016-June/074434.html
https://lists.freedesktop.org/archives/libreoffice/2015-August/069814.html
Oliver
__
> could you please tell me how to disable OpenCL during build ?
>
> maybe my build breaks have same root cause
> https://www.mail-archive.com/libreoffice@lists.freedesktop.o
> rg/msg181443.html
What makes you think there is anything OpenCL-related in there?
As there seems to be problem with a PD
Hi,
> After disabled the failing Unit Tests, I
> discovered that the new binaries enable OpenCL by default, where as in my
> old binary I cannot even enable OpenCL.
> Did something change in new Cygwin/LODE env that's causing OpenCL to be
> enabled now?
could you please tell me how to disable Op
your PATH)
--
View this message in context:
http://nabble.documentfoundation.org/OpenCL-enabled-by-default-after-OS-reinstall-causing-Unit-Test-Failure-tp4202419.html
Sent from the Dev mailing list archive at Nabble.com.
___
LibreOffice mailing list
Hi Luke,
On 12/04/2016 02:00 AM, Luke Benes wrote:
Ashod,
Ever since
https://cgit.freedesktop.org/libreoffice/core/commit/?id=9c218858f1bd83ffdd72dd943a841cffa5a93b8c
I'm getting a unit test failure in testTileInvalidationCompression. I'm seeing
this same failure under Ubuntu 16.0
Ashod,
Ever since
https://cgit.freedesktop.org/libreoffice/core/commit/?id=9c218858f1bd83ffdd72dd943a841cffa5a93b8c
I'm getting a unit test failure in testTileInvalidationCompression. I'm seeing
this same failure under Ubuntu 16.04 with gcc 5.4 and Arch with clang 3.9.
Any idea w
1 - 100 of 136 matches
Mail list logo
