Re: test failures with new fonts-crosextra-carlito
Hi,
Am 26.06.23 um 09:06 schrieb Mike Kaganski:
On 26.06.2023 8:15, Rene Engelhard wrote:
Hi,
Am 25.06.23 um 13:29 schrieb Rene Engelhard:
my beta1 (didn't try 7.5 yet) builds fail with a new verson of the
fonts-crosextra-carlito fonts (used for Calibri). LibreOffice itself
ships
My 7.5.4 builds needs the following in addition to the already
posted (where applicable):
rene@frodo:~/Debian/Pakete/LibreOffice/libreoffice/libreoffice-7.5.4.2$
diff -u sw/qa/extras/ooxmlexport/ooxmlexport14.cxx-old
sw/qa/extras/ooxmlexport/ooxmlexport14.cxx
--- sw/qa/extras/ooxmlexport/ooxmlexport14.cxx-old 2023-06-26
06:30:09.119195022 +0200
+++ sw/qa/extras/ooxmlexport/ooxmlexport14.cxx 2023-06-26
06:30:18.891263759 +0200
@@ -1346,8 +1346,7 @@
#if !defined(MACOSX)
DECLARE_OOXMLEXPORT_TEST(testTdf146346, "tdf146346.docx")
{
- // This was 2 (by bad docDefault vertical margins around tables
in footnotes)
- CPPUNIT_ASSERT_EQUAL(1, getPages());
+ CPPUNIT_ASSERT_EQUAL(2, getPages());
}
#endif
I take that one back, it seems to be flaky. I get 2, the apply the
patch, then somehow get 1, revert the patch, get 2 again etc. I'll
disable it for now.[...]
> 2. A problem in unit test, claiming one page in master, when actually
it's two.
And the test seems to be flaky...
Regards,
Rene
Bug#1028132: now ready
Hi, Am 27.06.23 um 00:15 schrieb Sebastian Ramacher: On 2023-06-18 13:57:01 +0200, Rene Engelhard wrote: Hi, hunspell-dict-ko was fixed/worked around the issue (0.7.94-1) so we can do this now. As said it's a no-op for anything except r-cran-hunspell which also is prepared in experimental together with hunspell itself. I might add a libhunspell-private-dev package later when I figured out how to best prevent this by adding a strict dependency there instead of hardcoding it... But even without that it's better to not have a copy of private headers in r-cran-hunspell. Can I upload to unstable? Please go ahead Uploaded, thanks. Andreas, you can upload r-cran-hunspell. Regards, Rene
Bug#1028132: now ready
Hi, Am 27.06.23 um 00:15 schrieb Sebastian Ramacher: On 2023-06-18 13:57:01 +0200, Rene Engelhard wrote: Hi, hunspell-dict-ko was fixed/worked around the issue (0.7.94-1) so we can do this now. As said it's a no-op for anything except r-cran-hunspell which also is prepared in experimental together with hunspell itself. I might add a libhunspell-private-dev package later when I figured out how to best prevent this by adding a strict dependency there instead of hardcoding it... But even without that it's better to not have a copy of private headers in r-cran-hunspell. Can I upload to unstable? Please go ahead Uploaded, thanks. Andreas, you can upload r-cran-hunspell. Regards, Rene
Re: Usage of Source Han Serif SC
Hi, Am 26.06.23 um 18:24 schrieb Rene Engelhard: Am 26.06.23 um 08:58 schrieb Khaled Hosny: On 25 Jun 2023, at 2:16 PM, Rene Engelhard wrote: [_RUN_] testTdf129810::TestBody file:///home/rene/LibreOffice/git/libreoffice-7-6//sw/qa/core/text/data//tdf129810.odt: ./sw/qa/core/text/text.cxx:1387:testTdf129810::TestBody greater assertion failed - Expected greater than: 13 - Actual : 13 [...] There seem to be a thinko in the test, it was supposed to be CPPUNIT_ASSERT_EQUAL not CPPUNIT_ASSERT_GREATER. Can you try that and see if the test passes? Will do. This failure is fixed, but I get a new one in the same test: [_RUN_] testTdf129810::TestBody file:///home/rene/LibreOffice/git/libreoffice-7-6//sw/qa/core/text/data//tdf129810.odt: ./sw/qa/core/text/text.cxx:1402:testTdf129810::TestBody equality assertion failed - Expected: 500 - Actual : 720 Regards, Rene
Re: Usage of Source Han Serif SC
Hi, Am 26.06.23 um 08:58 schrieb Khaled Hosny: On 25 Jun 2023, at 2:16 PM, Rene Engelhard wrote: [_RUN_] testTdf129810::TestBody file:///home/rene/LibreOffice/git/libreoffice-7-6//sw/qa/core/text/data//tdf129810.odt: ./sw/qa/core/text/text.cxx:1387:testTdf129810::TestBody greater assertion failed - Expected greater than: 13 - Actual : 13 [...] There seem to be a thinko in the test, it was supposed to be CPPUNIT_ASSERT_EQUAL not CPPUNIT_ASSERT_GREATER. Can you try that and see if the test passes? Will do. I wonder why it passes for me and Jenkins builds, different cppunittest versions? Nothing special in cppunit. Standard system-cppunit 1.15.1 with the oder patch which is also in LO. (No other patches) This should work around it: [...] FWIW, we don’t bundle any CJK fonts, so HAVE_MORE_FONTS should have no difference here. Except effectivelly disabling the test, I see. The test document embeds a (subset) version of the font (there is a comment that hints to this at the top of the test) so that the test passes even on systems without any CJK fonts (and be more reliable as well, since different fonts will have different widths and result different line breaks). Ah, I see. Must have overread that. Regards, Rene
Re: test failures with new fonts-crosextra-carlito
Hi,
Am 25.06.23 um 13:29 schrieb Rene Engelhard:
my beta1 (didn't try 7.5 yet) builds fail with a new verson of the
fonts-crosextra-carlito fonts (used for Calibri). LibreOffice itself ships
My 7.5.4 builds needs the following in addition to the already posted
(where applicable):
rene@frodo:~/Debian/Pakete/LibreOffice/libreoffice/libreoffice-7.5.4.2$
diff -u sw/qa/extras/ooxmlexport/ooxmlexport14.cxx-old
sw/qa/extras/ooxmlexport/ooxmlexport14.cxx
--- sw/qa/extras/ooxmlexport/ooxmlexport14.cxx-old 2023-06-26
06:30:09.119195022 +0200
+++ sw/qa/extras/ooxmlexport/ooxmlexport14.cxx 2023-06-26
06:30:18.891263759 +0200
@@ -1346,8 +1346,7 @@
#if !defined(MACOSX)
DECLARE_OOXMLEXPORT_TEST(testTdf146346, "tdf146346.docx")
{
-// This was 2 (by bad docDefault vertical margins around tables in
footnotes)
-CPPUNIT_ASSERT_EQUAL(1, getPages());
+CPPUNIT_ASSERT_EQUAL(2, getPages());
}
#endif
(sorry, overwrite the log, but should be obvious)
I know it said 2 was the failure before, but that's what the new font
gives me. Here even downgrading the font just makes it work, too, but
that is no option unfortunately.
This makes
https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/-/blob/debian-experimental-7.6/patches/adapt-for-new-carlito.diff
for 7.6+
and
https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/-/blob/master/patches/adapt-for-new-carlito.diff?ref_type=heads
for 7.5
so far
Regards,
Rene
Re: test failures with new fonts-crosextra-carlito
Hi,
Am 25.06.23 um 13:29 schrieb Rene Engelhard:
Anyways, this breaks some of sds import tests (I tried this in a
actual beta1 "release" build, not on master - which worked before):
Also:
[build CUT] sw_layoutwriter3
S=/data/ssd/rene/libreoffice-7.6.0~beta1 && I=$S/instdir && W=$S/workdir
&& mkdir -p $W/CppunitTest/ && rm -fr
$W/CppunitTest/sw_layoutwriter3.test.user && cp -r $W/unittest
$W/CppunitTest/sw_layoutwriter3.test.user && rm -fr
$W/CppunitTest/sw_layoutwriter3.test.core && mkdir
$W/CppunitTest/sw_layoutwriter3.test.core && cd
$W/CppunitTest/sw_layoutwriter3.test.core && ( MAX_CONCURRENCY=4
MOZILLA_CERTIFICATE_FOLDER=dbm:
SAL_DISABLE_SYNCHRONOUS_PRINTER_DETECTION=1 SAL_USE_VCLPLUGIN=svp
LIBO_LANG=C
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"$I/program:$I/program":$W/UnpackedTarball/cppunit/src/cppunit/.libs
$W/LinkTarget/Executable/cppunittester
$W/LinkTarget/CppunitTest/libtest_sw_layoutwriter3.so --headless
"-env:BRAND_BASE_DIR=file://$S/instdir" "-env:BRAND_SHARE_SUBDIR=share"
"-env:BRAND_SHARE_RESOURCE_SUBDIR=program/resource"
"-env:UserInstallation=file://$W/CppunitTest/sw_layoutwriter3.test.user"
"-env:CONFIGURATION_LAYERS=xcsxcu:file://$I/share/registry
xcsxcu:file://$W/unittest/registry-common
xcsxcu:file://$W/unittest/registry-user-ui"
"-env:UNO_TYPES=file://$I/program/types.rdb
file://$I/program/types/offapi.rdb file://$I/program/types/oovbaapi.rdb"
"-env:UNO_SERVICES=file://$W/Rdb/ure/services.rdb
file://$W/Rdb/services.rdb" -env:URE_BIN_DIR=file://$I/program
-env:URE_INTERNAL_LIB_DIR=file://$I/program
-env:LO_LIB_DIR=file://$I/program
-env:LO_JAVA_DIR=file://$I/program/classes --protector
$W/LinkTarget/Library/unoexceptionprotector.so unoexceptionprotector
--protector $W/LinkTarget/Library/unobootstrapprotector.so
unobootstrapprotector --protector
$W/LinkTarget/Library/libvclbootstrapprotector.so vclbootstrapprotector
"-env:CPPUNITTESTTARGET=$W/CppunitTest/sw_layoutwriter3.test" ) 2>&1
[_RUN_] TestTdf150616::TestBody
TestTdf150616::TestBody finished in: 1322ms
[_RUN_] testAbi11870::TestBody
file:///data/ssd/rene/libreoffice-7.6.0~beta1//sw/qa/extras/layout/data//abi11870-2.odt:
testAbi11870::TestBody finished in: 1043ms
[_RUN_] testBtlrCell::TestBody
file:///data/ssd/rene/libreoffice-7.6.0~beta1//sw/qa/extras/layout/data//btlr-cell.odt:
./test/source/xmltesttools.cxx:170:testBtlrCell::TestBody
equality assertion failed
- Expected: 1915
- Actual : 1911
- In <>, attribute 'x' of '//textarray[1]' incorrect value.
testBtlrCell::TestBody finished in: 232ms
[…]
Regards,
Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi,
Am 20.06.23 um 10:25 schrieb Adrian Bunk:
On Tue, Jun 20, 2023 at 05:52:44AM +0200, Rene Engelhard wrote:
Hi,
Am 19.06.23 um 23:29 schrieb Rene Engelhard:
The pragmatic option would be to run only a smoketest for build success
on architectures not tested by upstream.
And have Format->Character in Impress crash with Bus error like on
mipsel? That doesn't sound too good for basic quality.
There is a "smoketest" but it does just basic start. open, close stuff.
Not even basic usage.
That said, that is the smoketest on mipsel:
...
Assuming the smoketest currently also fails on riscv64,
It thankfully does, because it fails the smoketest (:-)) because its
"does a (Java) extension install?" test fails.
(Which autopkgtest disables and makes an own test out of this anyway.)
what about the
following:
- make all test failures fatal on a*64 (since upstream tests these), and
- make smoketest failures fatal on all architectures (including ports)
Sounds OKish, but that won't help the architectures even failing the
smoketest.
For that matter mipsel seems to be even more broken. A --without-java
builds also breaks at the smoketest with a segfault (tried on eller):
m -rf /home/rene/libreoffice-7.5.4/workdir/CustomTarget/smoketest
mkdir -p /home/rene/libreoffice-7.5.4/workdir/CustomTarget/smoketest/user
cp /home/rene/libreoffice-7.5.4/qadevOOo/qa/registrymodifications.xcu
/home/rene/libreoffice-7.5.4/workdir/CustomTarget/smoketest/user
[build CUT] smoketest
S=/home/rene/libreoffice-7.5.4 && I=$S/instdir && W=$S/workdir && mkdir
-p $W/CppunitTest/ && rm -fr $W/CppunitTest/smoketest.test.user && cp -r
$W/unittest $W/CppunitTest/smoketest.test.user && rm -fr
$W/CppunitTest/smoketest.test.core && mkdir
$W/CppunitTest/smoketest.test.core && cd
$W/CppunitTest/smoketest.test.core && ( MAX_CONCURRENCY=4
MOZILLA_CERTIFICATE_FOLDER=dbm:
SAL_DISABLE_SYNCHRONOUS_PRINTER_DETECTION=1 SAL_USE_VCLPLUGIN=svp
LIBO_LANG=C
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"$I/program:$I/program":$W/UnpackedTarball/cppunit/src/cppunit/.libs
$W/LinkTarget/Executable/cppunittester $W/L
inkTarget/CppunitTest/libtest_smoketest.so --headless
"-env:BRAND_BASE_DIR=file://$S/instdir" "-env:BRAND_SHARE_SUBDIR=share"
"-env:BRAND_SHARE_RESOURCE_SUBDIR=program/resource"
"-env:UserInstallation=file://$W/CppunitTest/smoketest.test.user"
"-env:UNO_TYPES=file://$I/program/types.rdb
file://$I/program/types/offapi.rdb"
"-env:UNO_SERVICES=file://$W/Rdb/ure/services.rdb"
-env:URE_BIN_DIR=file://$I/program
-env:URE_INTERNAL_LIB_DIR=file://$I/program
-env:LO_LIB_DIR=file://$I/program
-env:LO_JAVA_DIR=file://$I/program/classes --protector
$W/LinkTarget/Library/unoexceptionprotector.so unoexceptionprotector
--protector $W/Lin
kTarget/Library/unobootstrapprotector.so unobootstrapprotector
-env:arg-soffice=path:$I/program/soffice
-env:arg-user=$W/CustomTarget/smoketest
-env:arg-env=LD_LIBRARY_PATH"${LD_LIBRARY_PATH+=$LD_LIBRARY_PATH}"
-env:arg-testarg.smoketest.doc=$W/Zip/smoketestdoc.sxw
"-env:CPPUNITTESTTARGET=$W/CppunitTest/smoketest.test" ) 2>&1
[_RUN_] (anonymous namespace)::Test::test
Fatal exception: Signal 11
Stack:
/home/rene/libreoffice-7.5.4/instdir/program/libuno_sal.so.3(+0x49b08)[0x77ec9b08]
/home/rene/libreoffice-7.5.4/instdir/program/libuno_sal.so.3(+0x49d38)[0x77ec9d38]
linux-vdso.so.1(+0x550)[0x7ff4e550]
/home/rene/libreoffice-7.5.4/instdir/program/libuno_cppu.so.3(+0x15d94)[0x772d5d94]
/home/rene/libreoffice-7.5.4/instdir/program/libuno_cppu.so.3(+0x1d1fc)[0x772dd1fc]
/home/rene/libreoffice-7.5.4/instdir/program/libuno_cppu.so.3(uno_copyAndConvertData+0x30)[0x772da974]
/home/rene/libreoffice-7.5.4/instdir/program/libgcc3_uno.so(+0xbf8c)[0x6ca0bf8c]
/home/rene/libreoffice-7.5.4/instdir/program/libgcc3_uno.so(+0xcbc4)[0x6ca0cbc4]
/home/rene/libreoffice-7.5.4/instdir/program/libreflectionlo.so(+0x2942c)[0x63fc942c]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(+0x94ca0)[0x76794ca0]
/home/rene/libreoffice-7.5.4/instdir/program/libsvllo.so(_ZN14SfxBroadcaster9BroadcastERK7SfxHint+0x6c)[0x75f93a3c]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(_ZN11SbxVariable9BroadcastE9SfxHintId+0x16c)[0x768986e8]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(_ZN8SbxValueC2ERKS_+0xb0)[0x768906c8]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(_ZN11SbxVariableC2ERKS_+0x44)[0x76898874]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(_ZN9SbxMethodC1ERKS_+0x50)[0x768881f4]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(+0x13d69c)[0x7683d69c]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(+0x13e3cc)[0x7683e3cc]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(+0x131008)[0x76831008]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(+0xb4
Re: unbreaking LibreOffices tests on at least release architectures
Hi,
Am 20.06.23 um 10:25 schrieb Adrian Bunk:
On Tue, Jun 20, 2023 at 05:52:44AM +0200, Rene Engelhard wrote:
Hi,
Am 19.06.23 um 23:29 schrieb Rene Engelhard:
The pragmatic option would be to run only a smoketest for build success
on architectures not tested by upstream.
And have Format->Character in Impress crash with Bus error like on
mipsel? That doesn't sound too good for basic quality.
There is a "smoketest" but it does just basic start. open, close stuff.
Not even basic usage.
That said, that is the smoketest on mipsel:
...
Assuming the smoketest currently also fails on riscv64,
It thankfully does, because it fails the smoketest (:-)) because its
"does a (Java) extension install?" test fails.
(Which autopkgtest disables and makes an own test out of this anyway.)
what about the
following:
- make all test failures fatal on a*64 (since upstream tests these), and
- make smoketest failures fatal on all architectures (including ports)
Sounds OKish, but that won't help the architectures even failing the
smoketest.
For that matter mipsel seems to be even more broken. A --without-java
builds also breaks at the smoketest with a segfault (tried on eller):
m -rf /home/rene/libreoffice-7.5.4/workdir/CustomTarget/smoketest
mkdir -p /home/rene/libreoffice-7.5.4/workdir/CustomTarget/smoketest/user
cp /home/rene/libreoffice-7.5.4/qadevOOo/qa/registrymodifications.xcu
/home/rene/libreoffice-7.5.4/workdir/CustomTarget/smoketest/user
[build CUT] smoketest
S=/home/rene/libreoffice-7.5.4 && I=$S/instdir && W=$S/workdir && mkdir
-p $W/CppunitTest/ && rm -fr $W/CppunitTest/smoketest.test.user && cp -r
$W/unittest $W/CppunitTest/smoketest.test.user && rm -fr
$W/CppunitTest/smoketest.test.core && mkdir
$W/CppunitTest/smoketest.test.core && cd
$W/CppunitTest/smoketest.test.core && ( MAX_CONCURRENCY=4
MOZILLA_CERTIFICATE_FOLDER=dbm:
SAL_DISABLE_SYNCHRONOUS_PRINTER_DETECTION=1 SAL_USE_VCLPLUGIN=svp
LIBO_LANG=C
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"$I/program:$I/program":$W/UnpackedTarball/cppunit/src/cppunit/.libs
$W/LinkTarget/Executable/cppunittester $W/L
inkTarget/CppunitTest/libtest_smoketest.so --headless
"-env:BRAND_BASE_DIR=file://$S/instdir" "-env:BRAND_SHARE_SUBDIR=share"
"-env:BRAND_SHARE_RESOURCE_SUBDIR=program/resource"
"-env:UserInstallation=file://$W/CppunitTest/smoketest.test.user"
"-env:UNO_TYPES=file://$I/program/types.rdb
file://$I/program/types/offapi.rdb"
"-env:UNO_SERVICES=file://$W/Rdb/ure/services.rdb"
-env:URE_BIN_DIR=file://$I/program
-env:URE_INTERNAL_LIB_DIR=file://$I/program
-env:LO_LIB_DIR=file://$I/program
-env:LO_JAVA_DIR=file://$I/program/classes --protector
$W/LinkTarget/Library/unoexceptionprotector.so unoexceptionprotector
--protector $W/Lin
kTarget/Library/unobootstrapprotector.so unobootstrapprotector
-env:arg-soffice=path:$I/program/soffice
-env:arg-user=$W/CustomTarget/smoketest
-env:arg-env=LD_LIBRARY_PATH"${LD_LIBRARY_PATH+=$LD_LIBRARY_PATH}"
-env:arg-testarg.smoketest.doc=$W/Zip/smoketestdoc.sxw
"-env:CPPUNITTESTTARGET=$W/CppunitTest/smoketest.test" ) 2>&1
[_RUN_] (anonymous namespace)::Test::test
Fatal exception: Signal 11
Stack:
/home/rene/libreoffice-7.5.4/instdir/program/libuno_sal.so.3(+0x49b08)[0x77ec9b08]
/home/rene/libreoffice-7.5.4/instdir/program/libuno_sal.so.3(+0x49d38)[0x77ec9d38]
linux-vdso.so.1(+0x550)[0x7ff4e550]
/home/rene/libreoffice-7.5.4/instdir/program/libuno_cppu.so.3(+0x15d94)[0x772d5d94]
/home/rene/libreoffice-7.5.4/instdir/program/libuno_cppu.so.3(+0x1d1fc)[0x772dd1fc]
/home/rene/libreoffice-7.5.4/instdir/program/libuno_cppu.so.3(uno_copyAndConvertData+0x30)[0x772da974]
/home/rene/libreoffice-7.5.4/instdir/program/libgcc3_uno.so(+0xbf8c)[0x6ca0bf8c]
/home/rene/libreoffice-7.5.4/instdir/program/libgcc3_uno.so(+0xcbc4)[0x6ca0cbc4]
/home/rene/libreoffice-7.5.4/instdir/program/libreflectionlo.so(+0x2942c)[0x63fc942c]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(+0x94ca0)[0x76794ca0]
/home/rene/libreoffice-7.5.4/instdir/program/libsvllo.so(_ZN14SfxBroadcaster9BroadcastERK7SfxHint+0x6c)[0x75f93a3c]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(_ZN11SbxVariable9BroadcastE9SfxHintId+0x16c)[0x768986e8]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(_ZN8SbxValueC2ERKS_+0xb0)[0x768906c8]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(_ZN11SbxVariableC2ERKS_+0x44)[0x76898874]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(_ZN9SbxMethodC1ERKS_+0x50)[0x768881f4]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(+0x13d69c)[0x7683d69c]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(+0x13e3cc)[0x7683e3cc]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(+0x131008)[0x76831008]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(+0xb4
Re: unbreaking LibreOffices tests on at least release architectures
Hi,
Am 20.06.23 um 10:25 schrieb Adrian Bunk:
On Tue, Jun 20, 2023 at 05:52:44AM +0200, Rene Engelhard wrote:
Hi,
Am 19.06.23 um 23:29 schrieb Rene Engelhard:
The pragmatic option would be to run only a smoketest for build success
on architectures not tested by upstream.
And have Format->Character in Impress crash with Bus error like on
mipsel? That doesn't sound too good for basic quality.
There is a "smoketest" but it does just basic start. open, close stuff.
Not even basic usage.
That said, that is the smoketest on mipsel:
...
Assuming the smoketest currently also fails on riscv64,
It thankfully does, because it fails the smoketest (:-)) because its
"does a (Java) extension install?" test fails.
(Which autopkgtest disables and makes an own test out of this anyway.)
what about the
following:
- make all test failures fatal on a*64 (since upstream tests these), and
- make smoketest failures fatal on all architectures (including ports)
Sounds OKish, but that won't help the architectures even failing the
smoketest.
For that matter mipsel seems to be even more broken. A --without-java
builds also breaks at the smoketest with a segfault (tried on eller):
m -rf /home/rene/libreoffice-7.5.4/workdir/CustomTarget/smoketest
mkdir -p /home/rene/libreoffice-7.5.4/workdir/CustomTarget/smoketest/user
cp /home/rene/libreoffice-7.5.4/qadevOOo/qa/registrymodifications.xcu
/home/rene/libreoffice-7.5.4/workdir/CustomTarget/smoketest/user
[build CUT] smoketest
S=/home/rene/libreoffice-7.5.4 && I=$S/instdir && W=$S/workdir && mkdir
-p $W/CppunitTest/ && rm -fr $W/CppunitTest/smoketest.test.user && cp -r
$W/unittest $W/CppunitTest/smoketest.test.user && rm -fr
$W/CppunitTest/smoketest.test.core && mkdir
$W/CppunitTest/smoketest.test.core && cd
$W/CppunitTest/smoketest.test.core && ( MAX_CONCURRENCY=4
MOZILLA_CERTIFICATE_FOLDER=dbm:
SAL_DISABLE_SYNCHRONOUS_PRINTER_DETECTION=1 SAL_USE_VCLPLUGIN=svp
LIBO_LANG=C
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"$I/program:$I/program":$W/UnpackedTarball/cppunit/src/cppunit/.libs
$W/LinkTarget/Executable/cppunittester $W/L
inkTarget/CppunitTest/libtest_smoketest.so --headless
"-env:BRAND_BASE_DIR=file://$S/instdir" "-env:BRAND_SHARE_SUBDIR=share"
"-env:BRAND_SHARE_RESOURCE_SUBDIR=program/resource"
"-env:UserInstallation=file://$W/CppunitTest/smoketest.test.user"
"-env:UNO_TYPES=file://$I/program/types.rdb
file://$I/program/types/offapi.rdb"
"-env:UNO_SERVICES=file://$W/Rdb/ure/services.rdb"
-env:URE_BIN_DIR=file://$I/program
-env:URE_INTERNAL_LIB_DIR=file://$I/program
-env:LO_LIB_DIR=file://$I/program
-env:LO_JAVA_DIR=file://$I/program/classes --protector
$W/LinkTarget/Library/unoexceptionprotector.so unoexceptionprotector
--protector $W/Lin
kTarget/Library/unobootstrapprotector.so unobootstrapprotector
-env:arg-soffice=path:$I/program/soffice
-env:arg-user=$W/CustomTarget/smoketest
-env:arg-env=LD_LIBRARY_PATH"${LD_LIBRARY_PATH+=$LD_LIBRARY_PATH}"
-env:arg-testarg.smoketest.doc=$W/Zip/smoketestdoc.sxw
"-env:CPPUNITTESTTARGET=$W/CppunitTest/smoketest.test" ) 2>&1
[_RUN_] (anonymous namespace)::Test::test
Fatal exception: Signal 11
Stack:
/home/rene/libreoffice-7.5.4/instdir/program/libuno_sal.so.3(+0x49b08)[0x77ec9b08]
/home/rene/libreoffice-7.5.4/instdir/program/libuno_sal.so.3(+0x49d38)[0x77ec9d38]
linux-vdso.so.1(+0x550)[0x7ff4e550]
/home/rene/libreoffice-7.5.4/instdir/program/libuno_cppu.so.3(+0x15d94)[0x772d5d94]
/home/rene/libreoffice-7.5.4/instdir/program/libuno_cppu.so.3(+0x1d1fc)[0x772dd1fc]
/home/rene/libreoffice-7.5.4/instdir/program/libuno_cppu.so.3(uno_copyAndConvertData+0x30)[0x772da974]
/home/rene/libreoffice-7.5.4/instdir/program/libgcc3_uno.so(+0xbf8c)[0x6ca0bf8c]
/home/rene/libreoffice-7.5.4/instdir/program/libgcc3_uno.so(+0xcbc4)[0x6ca0cbc4]
/home/rene/libreoffice-7.5.4/instdir/program/libreflectionlo.so(+0x2942c)[0x63fc942c]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(+0x94ca0)[0x76794ca0]
/home/rene/libreoffice-7.5.4/instdir/program/libsvllo.so(_ZN14SfxBroadcaster9BroadcastERK7SfxHint+0x6c)[0x75f93a3c]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(_ZN11SbxVariable9BroadcastE9SfxHintId+0x16c)[0x768986e8]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(_ZN8SbxValueC2ERKS_+0xb0)[0x768906c8]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(_ZN11SbxVariableC2ERKS_+0x44)[0x76898874]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(_ZN9SbxMethodC1ERKS_+0x50)[0x768881f4]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(+0x13d69c)[0x7683d69c]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(+0x13e3cc)[0x7683e3cc]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(+0x131008)[0x76831008]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(+0xb4
Re: unbreaking LibreOffices tests on at least release architectures
Hi,
Am 20.06.23 um 10:25 schrieb Adrian Bunk:
On Tue, Jun 20, 2023 at 05:52:44AM +0200, Rene Engelhard wrote:
Hi,
Am 19.06.23 um 23:29 schrieb Rene Engelhard:
The pragmatic option would be to run only a smoketest for build success
on architectures not tested by upstream.
And have Format->Character in Impress crash with Bus error like on
mipsel? That doesn't sound too good for basic quality.
There is a "smoketest" but it does just basic start. open, close stuff.
Not even basic usage.
That said, that is the smoketest on mipsel:
...
Assuming the smoketest currently also fails on riscv64,
It thankfully does, because it fails the smoketest (:-)) because its
"does a (Java) extension install?" test fails.
(Which autopkgtest disables and makes an own test out of this anyway.)
what about the
following:
- make all test failures fatal on a*64 (since upstream tests these), and
- make smoketest failures fatal on all architectures (including ports)
Sounds OKish, but that won't help the architectures even failing the
smoketest.
For that matter mipsel seems to be even more broken. A --without-java
builds also breaks at the smoketest with a segfault (tried on eller):
m -rf /home/rene/libreoffice-7.5.4/workdir/CustomTarget/smoketest
mkdir -p /home/rene/libreoffice-7.5.4/workdir/CustomTarget/smoketest/user
cp /home/rene/libreoffice-7.5.4/qadevOOo/qa/registrymodifications.xcu
/home/rene/libreoffice-7.5.4/workdir/CustomTarget/smoketest/user
[build CUT] smoketest
S=/home/rene/libreoffice-7.5.4 && I=$S/instdir && W=$S/workdir && mkdir
-p $W/CppunitTest/ && rm -fr $W/CppunitTest/smoketest.test.user && cp -r
$W/unittest $W/CppunitTest/smoketest.test.user && rm -fr
$W/CppunitTest/smoketest.test.core && mkdir
$W/CppunitTest/smoketest.test.core && cd
$W/CppunitTest/smoketest.test.core && ( MAX_CONCURRENCY=4
MOZILLA_CERTIFICATE_FOLDER=dbm:
SAL_DISABLE_SYNCHRONOUS_PRINTER_DETECTION=1 SAL_USE_VCLPLUGIN=svp
LIBO_LANG=C
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"$I/program:$I/program":$W/UnpackedTarball/cppunit/src/cppunit/.libs
$W/LinkTarget/Executable/cppunittester $W/L
inkTarget/CppunitTest/libtest_smoketest.so --headless
"-env:BRAND_BASE_DIR=file://$S/instdir" "-env:BRAND_SHARE_SUBDIR=share"
"-env:BRAND_SHARE_RESOURCE_SUBDIR=program/resource"
"-env:UserInstallation=file://$W/CppunitTest/smoketest.test.user"
"-env:UNO_TYPES=file://$I/program/types.rdb
file://$I/program/types/offapi.rdb"
"-env:UNO_SERVICES=file://$W/Rdb/ure/services.rdb"
-env:URE_BIN_DIR=file://$I/program
-env:URE_INTERNAL_LIB_DIR=file://$I/program
-env:LO_LIB_DIR=file://$I/program
-env:LO_JAVA_DIR=file://$I/program/classes --protector
$W/LinkTarget/Library/unoexceptionprotector.so unoexceptionprotector
--protector $W/Lin
kTarget/Library/unobootstrapprotector.so unobootstrapprotector
-env:arg-soffice=path:$I/program/soffice
-env:arg-user=$W/CustomTarget/smoketest
-env:arg-env=LD_LIBRARY_PATH"${LD_LIBRARY_PATH+=$LD_LIBRARY_PATH}"
-env:arg-testarg.smoketest.doc=$W/Zip/smoketestdoc.sxw
"-env:CPPUNITTESTTARGET=$W/CppunitTest/smoketest.test" ) 2>&1
[_RUN_] (anonymous namespace)::Test::test
Fatal exception: Signal 11
Stack:
/home/rene/libreoffice-7.5.4/instdir/program/libuno_sal.so.3(+0x49b08)[0x77ec9b08]
/home/rene/libreoffice-7.5.4/instdir/program/libuno_sal.so.3(+0x49d38)[0x77ec9d38]
linux-vdso.so.1(+0x550)[0x7ff4e550]
/home/rene/libreoffice-7.5.4/instdir/program/libuno_cppu.so.3(+0x15d94)[0x772d5d94]
/home/rene/libreoffice-7.5.4/instdir/program/libuno_cppu.so.3(+0x1d1fc)[0x772dd1fc]
/home/rene/libreoffice-7.5.4/instdir/program/libuno_cppu.so.3(uno_copyAndConvertData+0x30)[0x772da974]
/home/rene/libreoffice-7.5.4/instdir/program/libgcc3_uno.so(+0xbf8c)[0x6ca0bf8c]
/home/rene/libreoffice-7.5.4/instdir/program/libgcc3_uno.so(+0xcbc4)[0x6ca0cbc4]
/home/rene/libreoffice-7.5.4/instdir/program/libreflectionlo.so(+0x2942c)[0x63fc942c]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(+0x94ca0)[0x76794ca0]
/home/rene/libreoffice-7.5.4/instdir/program/libsvllo.so(_ZN14SfxBroadcaster9BroadcastERK7SfxHint+0x6c)[0x75f93a3c]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(_ZN11SbxVariable9BroadcastE9SfxHintId+0x16c)[0x768986e8]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(_ZN8SbxValueC2ERKS_+0xb0)[0x768906c8]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(_ZN11SbxVariableC2ERKS_+0x44)[0x76898874]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(_ZN9SbxMethodC1ERKS_+0x50)[0x768881f4]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(+0x13d69c)[0x7683d69c]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(+0x13e3cc)[0x7683e3cc]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(+0x131008)[0x76831008]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(+0xb4
Re: unbreaking LibreOffices tests on at least release architectures
Hi,
Am 20.06.23 um 10:25 schrieb Adrian Bunk:
On Tue, Jun 20, 2023 at 05:52:44AM +0200, Rene Engelhard wrote:
Hi,
Am 19.06.23 um 23:29 schrieb Rene Engelhard:
The pragmatic option would be to run only a smoketest for build success
on architectures not tested by upstream.
And have Format->Character in Impress crash with Bus error like on
mipsel? That doesn't sound too good for basic quality.
There is a "smoketest" but it does just basic start. open, close stuff.
Not even basic usage.
That said, that is the smoketest on mipsel:
...
Assuming the smoketest currently also fails on riscv64,
It thankfully does, because it fails the smoketest (:-)) because its
"does a (Java) extension install?" test fails.
(Which autopkgtest disables and makes an own test out of this anyway.)
what about the
following:
- make all test failures fatal on a*64 (since upstream tests these), and
- make smoketest failures fatal on all architectures (including ports)
Sounds OKish, but that won't help the architectures even failing the
smoketest.
For that matter mipsel seems to be even more broken. A --without-java
builds also breaks at the smoketest with a segfault (tried on eller):
m -rf /home/rene/libreoffice-7.5.4/workdir/CustomTarget/smoketest
mkdir -p /home/rene/libreoffice-7.5.4/workdir/CustomTarget/smoketest/user
cp /home/rene/libreoffice-7.5.4/qadevOOo/qa/registrymodifications.xcu
/home/rene/libreoffice-7.5.4/workdir/CustomTarget/smoketest/user
[build CUT] smoketest
S=/home/rene/libreoffice-7.5.4 && I=$S/instdir && W=$S/workdir && mkdir
-p $W/CppunitTest/ && rm -fr $W/CppunitTest/smoketest.test.user && cp -r
$W/unittest $W/CppunitTest/smoketest.test.user && rm -fr
$W/CppunitTest/smoketest.test.core && mkdir
$W/CppunitTest/smoketest.test.core && cd
$W/CppunitTest/smoketest.test.core && ( MAX_CONCURRENCY=4
MOZILLA_CERTIFICATE_FOLDER=dbm:
SAL_DISABLE_SYNCHRONOUS_PRINTER_DETECTION=1 SAL_USE_VCLPLUGIN=svp
LIBO_LANG=C
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"$I/program:$I/program":$W/UnpackedTarball/cppunit/src/cppunit/.libs
$W/LinkTarget/Executable/cppunittester $W/L
inkTarget/CppunitTest/libtest_smoketest.so --headless
"-env:BRAND_BASE_DIR=file://$S/instdir" "-env:BRAND_SHARE_SUBDIR=share"
"-env:BRAND_SHARE_RESOURCE_SUBDIR=program/resource"
"-env:UserInstallation=file://$W/CppunitTest/smoketest.test.user"
"-env:UNO_TYPES=file://$I/program/types.rdb
file://$I/program/types/offapi.rdb"
"-env:UNO_SERVICES=file://$W/Rdb/ure/services.rdb"
-env:URE_BIN_DIR=file://$I/program
-env:URE_INTERNAL_LIB_DIR=file://$I/program
-env:LO_LIB_DIR=file://$I/program
-env:LO_JAVA_DIR=file://$I/program/classes --protector
$W/LinkTarget/Library/unoexceptionprotector.so unoexceptionprotector
--protector $W/Lin
kTarget/Library/unobootstrapprotector.so unobootstrapprotector
-env:arg-soffice=path:$I/program/soffice
-env:arg-user=$W/CustomTarget/smoketest
-env:arg-env=LD_LIBRARY_PATH"${LD_LIBRARY_PATH+=$LD_LIBRARY_PATH}"
-env:arg-testarg.smoketest.doc=$W/Zip/smoketestdoc.sxw
"-env:CPPUNITTESTTARGET=$W/CppunitTest/smoketest.test" ) 2>&1
[_RUN_] (anonymous namespace)::Test::test
Fatal exception: Signal 11
Stack:
/home/rene/libreoffice-7.5.4/instdir/program/libuno_sal.so.3(+0x49b08)[0x77ec9b08]
/home/rene/libreoffice-7.5.4/instdir/program/libuno_sal.so.3(+0x49d38)[0x77ec9d38]
linux-vdso.so.1(+0x550)[0x7ff4e550]
/home/rene/libreoffice-7.5.4/instdir/program/libuno_cppu.so.3(+0x15d94)[0x772d5d94]
/home/rene/libreoffice-7.5.4/instdir/program/libuno_cppu.so.3(+0x1d1fc)[0x772dd1fc]
/home/rene/libreoffice-7.5.4/instdir/program/libuno_cppu.so.3(uno_copyAndConvertData+0x30)[0x772da974]
/home/rene/libreoffice-7.5.4/instdir/program/libgcc3_uno.so(+0xbf8c)[0x6ca0bf8c]
/home/rene/libreoffice-7.5.4/instdir/program/libgcc3_uno.so(+0xcbc4)[0x6ca0cbc4]
/home/rene/libreoffice-7.5.4/instdir/program/libreflectionlo.so(+0x2942c)[0x63fc942c]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(+0x94ca0)[0x76794ca0]
/home/rene/libreoffice-7.5.4/instdir/program/libsvllo.so(_ZN14SfxBroadcaster9BroadcastERK7SfxHint+0x6c)[0x75f93a3c]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(_ZN11SbxVariable9BroadcastE9SfxHintId+0x16c)[0x768986e8]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(_ZN8SbxValueC2ERKS_+0xb0)[0x768906c8]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(_ZN11SbxVariableC2ERKS_+0x44)[0x76898874]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(_ZN9SbxMethodC1ERKS_+0x50)[0x768881f4]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(+0x13d69c)[0x7683d69c]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(+0x13e3cc)[0x7683e3cc]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(+0x131008)[0x76831008]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(+0xb4
Re: unbreaking LibreOffices tests on at least release architectures
Hi,
Am 20.06.23 um 10:25 schrieb Adrian Bunk:
On Tue, Jun 20, 2023 at 05:52:44AM +0200, Rene Engelhard wrote:
Hi,
Am 19.06.23 um 23:29 schrieb Rene Engelhard:
The pragmatic option would be to run only a smoketest for build success
on architectures not tested by upstream.
And have Format->Character in Impress crash with Bus error like on
mipsel? That doesn't sound too good for basic quality.
There is a "smoketest" but it does just basic start. open, close stuff.
Not even basic usage.
That said, that is the smoketest on mipsel:
...
Assuming the smoketest currently also fails on riscv64,
It thankfully does, because it fails the smoketest (:-)) because its
"does a (Java) extension install?" test fails.
(Which autopkgtest disables and makes an own test out of this anyway.)
what about the
following:
- make all test failures fatal on a*64 (since upstream tests these), and
- make smoketest failures fatal on all architectures (including ports)
Sounds OKish, but that won't help the architectures even failing the
smoketest.
For that matter mipsel seems to be even more broken. A --without-java
builds also breaks at the smoketest with a segfault (tried on eller):
m -rf /home/rene/libreoffice-7.5.4/workdir/CustomTarget/smoketest
mkdir -p /home/rene/libreoffice-7.5.4/workdir/CustomTarget/smoketest/user
cp /home/rene/libreoffice-7.5.4/qadevOOo/qa/registrymodifications.xcu
/home/rene/libreoffice-7.5.4/workdir/CustomTarget/smoketest/user
[build CUT] smoketest
S=/home/rene/libreoffice-7.5.4 && I=$S/instdir && W=$S/workdir && mkdir
-p $W/CppunitTest/ && rm -fr $W/CppunitTest/smoketest.test.user && cp -r
$W/unittest $W/CppunitTest/smoketest.test.user && rm -fr
$W/CppunitTest/smoketest.test.core && mkdir
$W/CppunitTest/smoketest.test.core && cd
$W/CppunitTest/smoketest.test.core && ( MAX_CONCURRENCY=4
MOZILLA_CERTIFICATE_FOLDER=dbm:
SAL_DISABLE_SYNCHRONOUS_PRINTER_DETECTION=1 SAL_USE_VCLPLUGIN=svp
LIBO_LANG=C
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"$I/program:$I/program":$W/UnpackedTarball/cppunit/src/cppunit/.libs
$W/LinkTarget/Executable/cppunittester $W/L
inkTarget/CppunitTest/libtest_smoketest.so --headless
"-env:BRAND_BASE_DIR=file://$S/instdir" "-env:BRAND_SHARE_SUBDIR=share"
"-env:BRAND_SHARE_RESOURCE_SUBDIR=program/resource"
"-env:UserInstallation=file://$W/CppunitTest/smoketest.test.user"
"-env:UNO_TYPES=file://$I/program/types.rdb
file://$I/program/types/offapi.rdb"
"-env:UNO_SERVICES=file://$W/Rdb/ure/services.rdb"
-env:URE_BIN_DIR=file://$I/program
-env:URE_INTERNAL_LIB_DIR=file://$I/program
-env:LO_LIB_DIR=file://$I/program
-env:LO_JAVA_DIR=file://$I/program/classes --protector
$W/LinkTarget/Library/unoexceptionprotector.so unoexceptionprotector
--protector $W/Lin
kTarget/Library/unobootstrapprotector.so unobootstrapprotector
-env:arg-soffice=path:$I/program/soffice
-env:arg-user=$W/CustomTarget/smoketest
-env:arg-env=LD_LIBRARY_PATH"${LD_LIBRARY_PATH+=$LD_LIBRARY_PATH}"
-env:arg-testarg.smoketest.doc=$W/Zip/smoketestdoc.sxw
"-env:CPPUNITTESTTARGET=$W/CppunitTest/smoketest.test" ) 2>&1
[_RUN_] (anonymous namespace)::Test::test
Fatal exception: Signal 11
Stack:
/home/rene/libreoffice-7.5.4/instdir/program/libuno_sal.so.3(+0x49b08)[0x77ec9b08]
/home/rene/libreoffice-7.5.4/instdir/program/libuno_sal.so.3(+0x49d38)[0x77ec9d38]
linux-vdso.so.1(+0x550)[0x7ff4e550]
/home/rene/libreoffice-7.5.4/instdir/program/libuno_cppu.so.3(+0x15d94)[0x772d5d94]
/home/rene/libreoffice-7.5.4/instdir/program/libuno_cppu.so.3(+0x1d1fc)[0x772dd1fc]
/home/rene/libreoffice-7.5.4/instdir/program/libuno_cppu.so.3(uno_copyAndConvertData+0x30)[0x772da974]
/home/rene/libreoffice-7.5.4/instdir/program/libgcc3_uno.so(+0xbf8c)[0x6ca0bf8c]
/home/rene/libreoffice-7.5.4/instdir/program/libgcc3_uno.so(+0xcbc4)[0x6ca0cbc4]
/home/rene/libreoffice-7.5.4/instdir/program/libreflectionlo.so(+0x2942c)[0x63fc942c]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(+0x94ca0)[0x76794ca0]
/home/rene/libreoffice-7.5.4/instdir/program/libsvllo.so(_ZN14SfxBroadcaster9BroadcastERK7SfxHint+0x6c)[0x75f93a3c]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(_ZN11SbxVariable9BroadcastE9SfxHintId+0x16c)[0x768986e8]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(_ZN8SbxValueC2ERKS_+0xb0)[0x768906c8]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(_ZN11SbxVariableC2ERKS_+0x44)[0x76898874]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(_ZN9SbxMethodC1ERKS_+0x50)[0x768881f4]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(+0x13d69c)[0x7683d69c]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(+0x13e3cc)[0x7683e3cc]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(+0x131008)[0x76831008]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(+0xb4
Re: unbreaking LibreOffices tests on at least release architectures
Hi,
Am 20.06.23 um 10:25 schrieb Adrian Bunk:
On Tue, Jun 20, 2023 at 05:52:44AM +0200, Rene Engelhard wrote:
Hi,
Am 19.06.23 um 23:29 schrieb Rene Engelhard:
The pragmatic option would be to run only a smoketest for build success
on architectures not tested by upstream.
And have Format->Character in Impress crash with Bus error like on
mipsel? That doesn't sound too good for basic quality.
There is a "smoketest" but it does just basic start. open, close stuff.
Not even basic usage.
That said, that is the smoketest on mipsel:
...
Assuming the smoketest currently also fails on riscv64,
It thankfully does, because it fails the smoketest (:-)) because its
"does a (Java) extension install?" test fails.
(Which autopkgtest disables and makes an own test out of this anyway.)
what about the
following:
- make all test failures fatal on a*64 (since upstream tests these), and
- make smoketest failures fatal on all architectures (including ports)
Sounds OKish, but that won't help the architectures even failing the
smoketest.
For that matter mipsel seems to be even more broken. A --without-java
builds also breaks at the smoketest with a segfault (tried on eller):
m -rf /home/rene/libreoffice-7.5.4/workdir/CustomTarget/smoketest
mkdir -p /home/rene/libreoffice-7.5.4/workdir/CustomTarget/smoketest/user
cp /home/rene/libreoffice-7.5.4/qadevOOo/qa/registrymodifications.xcu
/home/rene/libreoffice-7.5.4/workdir/CustomTarget/smoketest/user
[build CUT] smoketest
S=/home/rene/libreoffice-7.5.4 && I=$S/instdir && W=$S/workdir && mkdir
-p $W/CppunitTest/ && rm -fr $W/CppunitTest/smoketest.test.user && cp -r
$W/unittest $W/CppunitTest/smoketest.test.user && rm -fr
$W/CppunitTest/smoketest.test.core && mkdir
$W/CppunitTest/smoketest.test.core && cd
$W/CppunitTest/smoketest.test.core && ( MAX_CONCURRENCY=4
MOZILLA_CERTIFICATE_FOLDER=dbm:
SAL_DISABLE_SYNCHRONOUS_PRINTER_DETECTION=1 SAL_USE_VCLPLUGIN=svp
LIBO_LANG=C
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"$I/program:$I/program":$W/UnpackedTarball/cppunit/src/cppunit/.libs
$W/LinkTarget/Executable/cppunittester $W/L
inkTarget/CppunitTest/libtest_smoketest.so --headless
"-env:BRAND_BASE_DIR=file://$S/instdir" "-env:BRAND_SHARE_SUBDIR=share"
"-env:BRAND_SHARE_RESOURCE_SUBDIR=program/resource"
"-env:UserInstallation=file://$W/CppunitTest/smoketest.test.user"
"-env:UNO_TYPES=file://$I/program/types.rdb
file://$I/program/types/offapi.rdb"
"-env:UNO_SERVICES=file://$W/Rdb/ure/services.rdb"
-env:URE_BIN_DIR=file://$I/program
-env:URE_INTERNAL_LIB_DIR=file://$I/program
-env:LO_LIB_DIR=file://$I/program
-env:LO_JAVA_DIR=file://$I/program/classes --protector
$W/LinkTarget/Library/unoexceptionprotector.so unoexceptionprotector
--protector $W/Lin
kTarget/Library/unobootstrapprotector.so unobootstrapprotector
-env:arg-soffice=path:$I/program/soffice
-env:arg-user=$W/CustomTarget/smoketest
-env:arg-env=LD_LIBRARY_PATH"${LD_LIBRARY_PATH+=$LD_LIBRARY_PATH}"
-env:arg-testarg.smoketest.doc=$W/Zip/smoketestdoc.sxw
"-env:CPPUNITTESTTARGET=$W/CppunitTest/smoketest.test" ) 2>&1
[_RUN_] (anonymous namespace)::Test::test
Fatal exception: Signal 11
Stack:
/home/rene/libreoffice-7.5.4/instdir/program/libuno_sal.so.3(+0x49b08)[0x77ec9b08]
/home/rene/libreoffice-7.5.4/instdir/program/libuno_sal.so.3(+0x49d38)[0x77ec9d38]
linux-vdso.so.1(+0x550)[0x7ff4e550]
/home/rene/libreoffice-7.5.4/instdir/program/libuno_cppu.so.3(+0x15d94)[0x772d5d94]
/home/rene/libreoffice-7.5.4/instdir/program/libuno_cppu.so.3(+0x1d1fc)[0x772dd1fc]
/home/rene/libreoffice-7.5.4/instdir/program/libuno_cppu.so.3(uno_copyAndConvertData+0x30)[0x772da974]
/home/rene/libreoffice-7.5.4/instdir/program/libgcc3_uno.so(+0xbf8c)[0x6ca0bf8c]
/home/rene/libreoffice-7.5.4/instdir/program/libgcc3_uno.so(+0xcbc4)[0x6ca0cbc4]
/home/rene/libreoffice-7.5.4/instdir/program/libreflectionlo.so(+0x2942c)[0x63fc942c]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(+0x94ca0)[0x76794ca0]
/home/rene/libreoffice-7.5.4/instdir/program/libsvllo.so(_ZN14SfxBroadcaster9BroadcastERK7SfxHint+0x6c)[0x75f93a3c]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(_ZN11SbxVariable9BroadcastE9SfxHintId+0x16c)[0x768986e8]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(_ZN8SbxValueC2ERKS_+0xb0)[0x768906c8]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(_ZN11SbxVariableC2ERKS_+0x44)[0x76898874]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(_ZN9SbxMethodC1ERKS_+0x50)[0x768881f4]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(+0x13d69c)[0x7683d69c]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(+0x13e3cc)[0x7683e3cc]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(+0x131008)[0x76831008]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(+0xb4
Re: unbreaking LibreOffices tests on at least release architectures
Hi,
Am 20.06.23 um 10:25 schrieb Adrian Bunk:
On Tue, Jun 20, 2023 at 05:52:44AM +0200, Rene Engelhard wrote:
Hi,
Am 19.06.23 um 23:29 schrieb Rene Engelhard:
The pragmatic option would be to run only a smoketest for build success
on architectures not tested by upstream.
And have Format->Character in Impress crash with Bus error like on
mipsel? That doesn't sound too good for basic quality.
There is a "smoketest" but it does just basic start. open, close stuff.
Not even basic usage.
That said, that is the smoketest on mipsel:
...
Assuming the smoketest currently also fails on riscv64,
It thankfully does, because it fails the smoketest (:-)) because its
"does a (Java) extension install?" test fails.
(Which autopkgtest disables and makes an own test out of this anyway.)
what about the
following:
- make all test failures fatal on a*64 (since upstream tests these), and
- make smoketest failures fatal on all architectures (including ports)
Sounds OKish, but that won't help the architectures even failing the
smoketest.
For that matter mipsel seems to be even more broken. A --without-java
builds also breaks at the smoketest with a segfault (tried on eller):
m -rf /home/rene/libreoffice-7.5.4/workdir/CustomTarget/smoketest
mkdir -p /home/rene/libreoffice-7.5.4/workdir/CustomTarget/smoketest/user
cp /home/rene/libreoffice-7.5.4/qadevOOo/qa/registrymodifications.xcu
/home/rene/libreoffice-7.5.4/workdir/CustomTarget/smoketest/user
[build CUT] smoketest
S=/home/rene/libreoffice-7.5.4 && I=$S/instdir && W=$S/workdir && mkdir
-p $W/CppunitTest/ && rm -fr $W/CppunitTest/smoketest.test.user && cp -r
$W/unittest $W/CppunitTest/smoketest.test.user && rm -fr
$W/CppunitTest/smoketest.test.core && mkdir
$W/CppunitTest/smoketest.test.core && cd
$W/CppunitTest/smoketest.test.core && ( MAX_CONCURRENCY=4
MOZILLA_CERTIFICATE_FOLDER=dbm:
SAL_DISABLE_SYNCHRONOUS_PRINTER_DETECTION=1 SAL_USE_VCLPLUGIN=svp
LIBO_LANG=C
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"$I/program:$I/program":$W/UnpackedTarball/cppunit/src/cppunit/.libs
$W/LinkTarget/Executable/cppunittester $W/L
inkTarget/CppunitTest/libtest_smoketest.so --headless
"-env:BRAND_BASE_DIR=file://$S/instdir" "-env:BRAND_SHARE_SUBDIR=share"
"-env:BRAND_SHARE_RESOURCE_SUBDIR=program/resource"
"-env:UserInstallation=file://$W/CppunitTest/smoketest.test.user"
"-env:UNO_TYPES=file://$I/program/types.rdb
file://$I/program/types/offapi.rdb"
"-env:UNO_SERVICES=file://$W/Rdb/ure/services.rdb"
-env:URE_BIN_DIR=file://$I/program
-env:URE_INTERNAL_LIB_DIR=file://$I/program
-env:LO_LIB_DIR=file://$I/program
-env:LO_JAVA_DIR=file://$I/program/classes --protector
$W/LinkTarget/Library/unoexceptionprotector.so unoexceptionprotector
--protector $W/Lin
kTarget/Library/unobootstrapprotector.so unobootstrapprotector
-env:arg-soffice=path:$I/program/soffice
-env:arg-user=$W/CustomTarget/smoketest
-env:arg-env=LD_LIBRARY_PATH"${LD_LIBRARY_PATH+=$LD_LIBRARY_PATH}"
-env:arg-testarg.smoketest.doc=$W/Zip/smoketestdoc.sxw
"-env:CPPUNITTESTTARGET=$W/CppunitTest/smoketest.test" ) 2>&1
[_RUN_] (anonymous namespace)::Test::test
Fatal exception: Signal 11
Stack:
/home/rene/libreoffice-7.5.4/instdir/program/libuno_sal.so.3(+0x49b08)[0x77ec9b08]
/home/rene/libreoffice-7.5.4/instdir/program/libuno_sal.so.3(+0x49d38)[0x77ec9d38]
linux-vdso.so.1(+0x550)[0x7ff4e550]
/home/rene/libreoffice-7.5.4/instdir/program/libuno_cppu.so.3(+0x15d94)[0x772d5d94]
/home/rene/libreoffice-7.5.4/instdir/program/libuno_cppu.so.3(+0x1d1fc)[0x772dd1fc]
/home/rene/libreoffice-7.5.4/instdir/program/libuno_cppu.so.3(uno_copyAndConvertData+0x30)[0x772da974]
/home/rene/libreoffice-7.5.4/instdir/program/libgcc3_uno.so(+0xbf8c)[0x6ca0bf8c]
/home/rene/libreoffice-7.5.4/instdir/program/libgcc3_uno.so(+0xcbc4)[0x6ca0cbc4]
/home/rene/libreoffice-7.5.4/instdir/program/libreflectionlo.so(+0x2942c)[0x63fc942c]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(+0x94ca0)[0x76794ca0]
/home/rene/libreoffice-7.5.4/instdir/program/libsvllo.so(_ZN14SfxBroadcaster9BroadcastERK7SfxHint+0x6c)[0x75f93a3c]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(_ZN11SbxVariable9BroadcastE9SfxHintId+0x16c)[0x768986e8]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(_ZN8SbxValueC2ERKS_+0xb0)[0x768906c8]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(_ZN11SbxVariableC2ERKS_+0x44)[0x76898874]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(_ZN9SbxMethodC1ERKS_+0x50)[0x768881f4]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(+0x13d69c)[0x7683d69c]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(+0x13e3cc)[0x7683e3cc]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(+0x131008)[0x76831008]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(+0xb4
Re: unbreaking LibreOffices tests on at least release architectures
Hi,
Am 20.06.23 um 10:25 schrieb Adrian Bunk:
On Tue, Jun 20, 2023 at 05:52:44AM +0200, Rene Engelhard wrote:
Hi,
Am 19.06.23 um 23:29 schrieb Rene Engelhard:
The pragmatic option would be to run only a smoketest for build success
on architectures not tested by upstream.
And have Format->Character in Impress crash with Bus error like on
mipsel? That doesn't sound too good for basic quality.
There is a "smoketest" but it does just basic start. open, close stuff.
Not even basic usage.
That said, that is the smoketest on mipsel:
...
Assuming the smoketest currently also fails on riscv64,
It thankfully does, because it fails the smoketest (:-)) because its
"does a (Java) extension install?" test fails.
(Which autopkgtest disables and makes an own test out of this anyway.)
what about the
following:
- make all test failures fatal on a*64 (since upstream tests these), and
- make smoketest failures fatal on all architectures (including ports)
Sounds OKish, but that won't help the architectures even failing the
smoketest.
For that matter mipsel seems to be even more broken. A --without-java
builds also breaks at the smoketest with a segfault (tried on eller):
m -rf /home/rene/libreoffice-7.5.4/workdir/CustomTarget/smoketest
mkdir -p /home/rene/libreoffice-7.5.4/workdir/CustomTarget/smoketest/user
cp /home/rene/libreoffice-7.5.4/qadevOOo/qa/registrymodifications.xcu
/home/rene/libreoffice-7.5.4/workdir/CustomTarget/smoketest/user
[build CUT] smoketest
S=/home/rene/libreoffice-7.5.4 && I=$S/instdir && W=$S/workdir && mkdir
-p $W/CppunitTest/ && rm -fr $W/CppunitTest/smoketest.test.user && cp -r
$W/unittest $W/CppunitTest/smoketest.test.user && rm -fr
$W/CppunitTest/smoketest.test.core && mkdir
$W/CppunitTest/smoketest.test.core && cd
$W/CppunitTest/smoketest.test.core && ( MAX_CONCURRENCY=4
MOZILLA_CERTIFICATE_FOLDER=dbm:
SAL_DISABLE_SYNCHRONOUS_PRINTER_DETECTION=1 SAL_USE_VCLPLUGIN=svp
LIBO_LANG=C
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"$I/program:$I/program":$W/UnpackedTarball/cppunit/src/cppunit/.libs
$W/LinkTarget/Executable/cppunittester $W/L
inkTarget/CppunitTest/libtest_smoketest.so --headless
"-env:BRAND_BASE_DIR=file://$S/instdir" "-env:BRAND_SHARE_SUBDIR=share"
"-env:BRAND_SHARE_RESOURCE_SUBDIR=program/resource"
"-env:UserInstallation=file://$W/CppunitTest/smoketest.test.user"
"-env:UNO_TYPES=file://$I/program/types.rdb
file://$I/program/types/offapi.rdb"
"-env:UNO_SERVICES=file://$W/Rdb/ure/services.rdb"
-env:URE_BIN_DIR=file://$I/program
-env:URE_INTERNAL_LIB_DIR=file://$I/program
-env:LO_LIB_DIR=file://$I/program
-env:LO_JAVA_DIR=file://$I/program/classes --protector
$W/LinkTarget/Library/unoexceptionprotector.so unoexceptionprotector
--protector $W/Lin
kTarget/Library/unobootstrapprotector.so unobootstrapprotector
-env:arg-soffice=path:$I/program/soffice
-env:arg-user=$W/CustomTarget/smoketest
-env:arg-env=LD_LIBRARY_PATH"${LD_LIBRARY_PATH+=$LD_LIBRARY_PATH}"
-env:arg-testarg.smoketest.doc=$W/Zip/smoketestdoc.sxw
"-env:CPPUNITTESTTARGET=$W/CppunitTest/smoketest.test" ) 2>&1
[_RUN_] (anonymous namespace)::Test::test
Fatal exception: Signal 11
Stack:
/home/rene/libreoffice-7.5.4/instdir/program/libuno_sal.so.3(+0x49b08)[0x77ec9b08]
/home/rene/libreoffice-7.5.4/instdir/program/libuno_sal.so.3(+0x49d38)[0x77ec9d38]
linux-vdso.so.1(+0x550)[0x7ff4e550]
/home/rene/libreoffice-7.5.4/instdir/program/libuno_cppu.so.3(+0x15d94)[0x772d5d94]
/home/rene/libreoffice-7.5.4/instdir/program/libuno_cppu.so.3(+0x1d1fc)[0x772dd1fc]
/home/rene/libreoffice-7.5.4/instdir/program/libuno_cppu.so.3(uno_copyAndConvertData+0x30)[0x772da974]
/home/rene/libreoffice-7.5.4/instdir/program/libgcc3_uno.so(+0xbf8c)[0x6ca0bf8c]
/home/rene/libreoffice-7.5.4/instdir/program/libgcc3_uno.so(+0xcbc4)[0x6ca0cbc4]
/home/rene/libreoffice-7.5.4/instdir/program/libreflectionlo.so(+0x2942c)[0x63fc942c]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(+0x94ca0)[0x76794ca0]
/home/rene/libreoffice-7.5.4/instdir/program/libsvllo.so(_ZN14SfxBroadcaster9BroadcastERK7SfxHint+0x6c)[0x75f93a3c]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(_ZN11SbxVariable9BroadcastE9SfxHintId+0x16c)[0x768986e8]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(_ZN8SbxValueC2ERKS_+0xb0)[0x768906c8]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(_ZN11SbxVariableC2ERKS_+0x44)[0x76898874]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(_ZN9SbxMethodC1ERKS_+0x50)[0x768881f4]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(+0x13d69c)[0x7683d69c]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(+0x13e3cc)[0x7683e3cc]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(+0x131008)[0x76831008]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(+0xb4
Re: unbreaking LibreOffices tests on at least release architectures
Hi,
Am 20.06.23 um 10:25 schrieb Adrian Bunk:
On Tue, Jun 20, 2023 at 05:52:44AM +0200, Rene Engelhard wrote:
Hi,
Am 19.06.23 um 23:29 schrieb Rene Engelhard:
The pragmatic option would be to run only a smoketest for build success
on architectures not tested by upstream.
And have Format->Character in Impress crash with Bus error like on
mipsel? That doesn't sound too good for basic quality.
There is a "smoketest" but it does just basic start. open, close stuff.
Not even basic usage.
That said, that is the smoketest on mipsel:
...
Assuming the smoketest currently also fails on riscv64,
It thankfully does, because it fails the smoketest (:-)) because its
"does a (Java) extension install?" test fails.
(Which autopkgtest disables and makes an own test out of this anyway.)
what about the
following:
- make all test failures fatal on a*64 (since upstream tests these), and
- make smoketest failures fatal on all architectures (including ports)
Sounds OKish, but that won't help the architectures even failing the
smoketest.
For that matter mipsel seems to be even more broken. A --without-java
builds also breaks at the smoketest with a segfault (tried on eller):
m -rf /home/rene/libreoffice-7.5.4/workdir/CustomTarget/smoketest
mkdir -p /home/rene/libreoffice-7.5.4/workdir/CustomTarget/smoketest/user
cp /home/rene/libreoffice-7.5.4/qadevOOo/qa/registrymodifications.xcu
/home/rene/libreoffice-7.5.4/workdir/CustomTarget/smoketest/user
[build CUT] smoketest
S=/home/rene/libreoffice-7.5.4 && I=$S/instdir && W=$S/workdir && mkdir
-p $W/CppunitTest/ && rm -fr $W/CppunitTest/smoketest.test.user && cp -r
$W/unittest $W/CppunitTest/smoketest.test.user && rm -fr
$W/CppunitTest/smoketest.test.core && mkdir
$W/CppunitTest/smoketest.test.core && cd
$W/CppunitTest/smoketest.test.core && ( MAX_CONCURRENCY=4
MOZILLA_CERTIFICATE_FOLDER=dbm:
SAL_DISABLE_SYNCHRONOUS_PRINTER_DETECTION=1 SAL_USE_VCLPLUGIN=svp
LIBO_LANG=C
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"$I/program:$I/program":$W/UnpackedTarball/cppunit/src/cppunit/.libs
$W/LinkTarget/Executable/cppunittester $W/L
inkTarget/CppunitTest/libtest_smoketest.so --headless
"-env:BRAND_BASE_DIR=file://$S/instdir" "-env:BRAND_SHARE_SUBDIR=share"
"-env:BRAND_SHARE_RESOURCE_SUBDIR=program/resource"
"-env:UserInstallation=file://$W/CppunitTest/smoketest.test.user"
"-env:UNO_TYPES=file://$I/program/types.rdb
file://$I/program/types/offapi.rdb"
"-env:UNO_SERVICES=file://$W/Rdb/ure/services.rdb"
-env:URE_BIN_DIR=file://$I/program
-env:URE_INTERNAL_LIB_DIR=file://$I/program
-env:LO_LIB_DIR=file://$I/program
-env:LO_JAVA_DIR=file://$I/program/classes --protector
$W/LinkTarget/Library/unoexceptionprotector.so unoexceptionprotector
--protector $W/Lin
kTarget/Library/unobootstrapprotector.so unobootstrapprotector
-env:arg-soffice=path:$I/program/soffice
-env:arg-user=$W/CustomTarget/smoketest
-env:arg-env=LD_LIBRARY_PATH"${LD_LIBRARY_PATH+=$LD_LIBRARY_PATH}"
-env:arg-testarg.smoketest.doc=$W/Zip/smoketestdoc.sxw
"-env:CPPUNITTESTTARGET=$W/CppunitTest/smoketest.test" ) 2>&1
[_RUN_] (anonymous namespace)::Test::test
Fatal exception: Signal 11
Stack:
/home/rene/libreoffice-7.5.4/instdir/program/libuno_sal.so.3(+0x49b08)[0x77ec9b08]
/home/rene/libreoffice-7.5.4/instdir/program/libuno_sal.so.3(+0x49d38)[0x77ec9d38]
linux-vdso.so.1(+0x550)[0x7ff4e550]
/home/rene/libreoffice-7.5.4/instdir/program/libuno_cppu.so.3(+0x15d94)[0x772d5d94]
/home/rene/libreoffice-7.5.4/instdir/program/libuno_cppu.so.3(+0x1d1fc)[0x772dd1fc]
/home/rene/libreoffice-7.5.4/instdir/program/libuno_cppu.so.3(uno_copyAndConvertData+0x30)[0x772da974]
/home/rene/libreoffice-7.5.4/instdir/program/libgcc3_uno.so(+0xbf8c)[0x6ca0bf8c]
/home/rene/libreoffice-7.5.4/instdir/program/libgcc3_uno.so(+0xcbc4)[0x6ca0cbc4]
/home/rene/libreoffice-7.5.4/instdir/program/libreflectionlo.so(+0x2942c)[0x63fc942c]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(+0x94ca0)[0x76794ca0]
/home/rene/libreoffice-7.5.4/instdir/program/libsvllo.so(_ZN14SfxBroadcaster9BroadcastERK7SfxHint+0x6c)[0x75f93a3c]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(_ZN11SbxVariable9BroadcastE9SfxHintId+0x16c)[0x768986e8]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(_ZN8SbxValueC2ERKS_+0xb0)[0x768906c8]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(_ZN11SbxVariableC2ERKS_+0x44)[0x76898874]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(_ZN9SbxMethodC1ERKS_+0x50)[0x768881f4]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(+0x13d69c)[0x7683d69c]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(+0x13e3cc)[0x7683e3cc]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(+0x131008)[0x76831008]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(+0xb4
Re: unbreaking LibreOffices tests on at least release architectures
Hi,
Am 20.06.23 um 10:25 schrieb Adrian Bunk:
On Tue, Jun 20, 2023 at 05:52:44AM +0200, Rene Engelhard wrote:
Hi,
Am 19.06.23 um 23:29 schrieb Rene Engelhard:
The pragmatic option would be to run only a smoketest for build success
on architectures not tested by upstream.
And have Format->Character in Impress crash with Bus error like on
mipsel? That doesn't sound too good for basic quality.
There is a "smoketest" but it does just basic start. open, close stuff.
Not even basic usage.
That said, that is the smoketest on mipsel:
...
Assuming the smoketest currently also fails on riscv64,
It thankfully does, because it fails the smoketest (:-)) because its
"does a (Java) extension install?" test fails.
(Which autopkgtest disables and makes an own test out of this anyway.)
what about the
following:
- make all test failures fatal on a*64 (since upstream tests these), and
- make smoketest failures fatal on all architectures (including ports)
Sounds OKish, but that won't help the architectures even failing the
smoketest.
For that matter mipsel seems to be even more broken. A --without-java
builds also breaks at the smoketest with a segfault (tried on eller):
m -rf /home/rene/libreoffice-7.5.4/workdir/CustomTarget/smoketest
mkdir -p /home/rene/libreoffice-7.5.4/workdir/CustomTarget/smoketest/user
cp /home/rene/libreoffice-7.5.4/qadevOOo/qa/registrymodifications.xcu
/home/rene/libreoffice-7.5.4/workdir/CustomTarget/smoketest/user
[build CUT] smoketest
S=/home/rene/libreoffice-7.5.4 && I=$S/instdir && W=$S/workdir && mkdir
-p $W/CppunitTest/ && rm -fr $W/CppunitTest/smoketest.test.user && cp -r
$W/unittest $W/CppunitTest/smoketest.test.user && rm -fr
$W/CppunitTest/smoketest.test.core && mkdir
$W/CppunitTest/smoketest.test.core && cd
$W/CppunitTest/smoketest.test.core && ( MAX_CONCURRENCY=4
MOZILLA_CERTIFICATE_FOLDER=dbm:
SAL_DISABLE_SYNCHRONOUS_PRINTER_DETECTION=1 SAL_USE_VCLPLUGIN=svp
LIBO_LANG=C
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"$I/program:$I/program":$W/UnpackedTarball/cppunit/src/cppunit/.libs
$W/LinkTarget/Executable/cppunittester $W/L
inkTarget/CppunitTest/libtest_smoketest.so --headless
"-env:BRAND_BASE_DIR=file://$S/instdir" "-env:BRAND_SHARE_SUBDIR=share"
"-env:BRAND_SHARE_RESOURCE_SUBDIR=program/resource"
"-env:UserInstallation=file://$W/CppunitTest/smoketest.test.user"
"-env:UNO_TYPES=file://$I/program/types.rdb
file://$I/program/types/offapi.rdb"
"-env:UNO_SERVICES=file://$W/Rdb/ure/services.rdb"
-env:URE_BIN_DIR=file://$I/program
-env:URE_INTERNAL_LIB_DIR=file://$I/program
-env:LO_LIB_DIR=file://$I/program
-env:LO_JAVA_DIR=file://$I/program/classes --protector
$W/LinkTarget/Library/unoexceptionprotector.so unoexceptionprotector
--protector $W/Lin
kTarget/Library/unobootstrapprotector.so unobootstrapprotector
-env:arg-soffice=path:$I/program/soffice
-env:arg-user=$W/CustomTarget/smoketest
-env:arg-env=LD_LIBRARY_PATH"${LD_LIBRARY_PATH+=$LD_LIBRARY_PATH}"
-env:arg-testarg.smoketest.doc=$W/Zip/smoketestdoc.sxw
"-env:CPPUNITTESTTARGET=$W/CppunitTest/smoketest.test" ) 2>&1
[_RUN_] (anonymous namespace)::Test::test
Fatal exception: Signal 11
Stack:
/home/rene/libreoffice-7.5.4/instdir/program/libuno_sal.so.3(+0x49b08)[0x77ec9b08]
/home/rene/libreoffice-7.5.4/instdir/program/libuno_sal.so.3(+0x49d38)[0x77ec9d38]
linux-vdso.so.1(+0x550)[0x7ff4e550]
/home/rene/libreoffice-7.5.4/instdir/program/libuno_cppu.so.3(+0x15d94)[0x772d5d94]
/home/rene/libreoffice-7.5.4/instdir/program/libuno_cppu.so.3(+0x1d1fc)[0x772dd1fc]
/home/rene/libreoffice-7.5.4/instdir/program/libuno_cppu.so.3(uno_copyAndConvertData+0x30)[0x772da974]
/home/rene/libreoffice-7.5.4/instdir/program/libgcc3_uno.so(+0xbf8c)[0x6ca0bf8c]
/home/rene/libreoffice-7.5.4/instdir/program/libgcc3_uno.so(+0xcbc4)[0x6ca0cbc4]
/home/rene/libreoffice-7.5.4/instdir/program/libreflectionlo.so(+0x2942c)[0x63fc942c]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(+0x94ca0)[0x76794ca0]
/home/rene/libreoffice-7.5.4/instdir/program/libsvllo.so(_ZN14SfxBroadcaster9BroadcastERK7SfxHint+0x6c)[0x75f93a3c]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(_ZN11SbxVariable9BroadcastE9SfxHintId+0x16c)[0x768986e8]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(_ZN8SbxValueC2ERKS_+0xb0)[0x768906c8]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(_ZN11SbxVariableC2ERKS_+0x44)[0x76898874]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(_ZN9SbxMethodC1ERKS_+0x50)[0x768881f4]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(+0x13d69c)[0x7683d69c]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(+0x13e3cc)[0x7683e3cc]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(+0x131008)[0x76831008]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(+0xb4
Re: unbreaking LibreOffices tests on at least release architectures
Hi,
Am 20.06.23 um 10:25 schrieb Adrian Bunk:
On Tue, Jun 20, 2023 at 05:52:44AM +0200, Rene Engelhard wrote:
Hi,
Am 19.06.23 um 23:29 schrieb Rene Engelhard:
The pragmatic option would be to run only a smoketest for build success
on architectures not tested by upstream.
And have Format->Character in Impress crash with Bus error like on
mipsel? That doesn't sound too good for basic quality.
There is a "smoketest" but it does just basic start. open, close stuff.
Not even basic usage.
That said, that is the smoketest on mipsel:
...
Assuming the smoketest currently also fails on riscv64,
It thankfully does, because it fails the smoketest (:-)) because its
"does a (Java) extension install?" test fails.
(Which autopkgtest disables and makes an own test out of this anyway.)
what about the
following:
- make all test failures fatal on a*64 (since upstream tests these), and
- make smoketest failures fatal on all architectures (including ports)
Sounds OKish, but that won't help the architectures even failing the
smoketest.
For that matter mipsel seems to be even more broken. A --without-java
builds also breaks at the smoketest with a segfault (tried on eller):
m -rf /home/rene/libreoffice-7.5.4/workdir/CustomTarget/smoketest
mkdir -p /home/rene/libreoffice-7.5.4/workdir/CustomTarget/smoketest/user
cp /home/rene/libreoffice-7.5.4/qadevOOo/qa/registrymodifications.xcu
/home/rene/libreoffice-7.5.4/workdir/CustomTarget/smoketest/user
[build CUT] smoketest
S=/home/rene/libreoffice-7.5.4 && I=$S/instdir && W=$S/workdir && mkdir
-p $W/CppunitTest/ && rm -fr $W/CppunitTest/smoketest.test.user && cp -r
$W/unittest $W/CppunitTest/smoketest.test.user && rm -fr
$W/CppunitTest/smoketest.test.core && mkdir
$W/CppunitTest/smoketest.test.core && cd
$W/CppunitTest/smoketest.test.core && ( MAX_CONCURRENCY=4
MOZILLA_CERTIFICATE_FOLDER=dbm:
SAL_DISABLE_SYNCHRONOUS_PRINTER_DETECTION=1 SAL_USE_VCLPLUGIN=svp
LIBO_LANG=C
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"$I/program:$I/program":$W/UnpackedTarball/cppunit/src/cppunit/.libs
$W/LinkTarget/Executable/cppunittester $W/L
inkTarget/CppunitTest/libtest_smoketest.so --headless
"-env:BRAND_BASE_DIR=file://$S/instdir" "-env:BRAND_SHARE_SUBDIR=share"
"-env:BRAND_SHARE_RESOURCE_SUBDIR=program/resource"
"-env:UserInstallation=file://$W/CppunitTest/smoketest.test.user"
"-env:UNO_TYPES=file://$I/program/types.rdb
file://$I/program/types/offapi.rdb"
"-env:UNO_SERVICES=file://$W/Rdb/ure/services.rdb"
-env:URE_BIN_DIR=file://$I/program
-env:URE_INTERNAL_LIB_DIR=file://$I/program
-env:LO_LIB_DIR=file://$I/program
-env:LO_JAVA_DIR=file://$I/program/classes --protector
$W/LinkTarget/Library/unoexceptionprotector.so unoexceptionprotector
--protector $W/Lin
kTarget/Library/unobootstrapprotector.so unobootstrapprotector
-env:arg-soffice=path:$I/program/soffice
-env:arg-user=$W/CustomTarget/smoketest
-env:arg-env=LD_LIBRARY_PATH"${LD_LIBRARY_PATH+=$LD_LIBRARY_PATH}"
-env:arg-testarg.smoketest.doc=$W/Zip/smoketestdoc.sxw
"-env:CPPUNITTESTTARGET=$W/CppunitTest/smoketest.test" ) 2>&1
[_RUN_] (anonymous namespace)::Test::test
Fatal exception: Signal 11
Stack:
/home/rene/libreoffice-7.5.4/instdir/program/libuno_sal.so.3(+0x49b08)[0x77ec9b08]
/home/rene/libreoffice-7.5.4/instdir/program/libuno_sal.so.3(+0x49d38)[0x77ec9d38]
linux-vdso.so.1(+0x550)[0x7ff4e550]
/home/rene/libreoffice-7.5.4/instdir/program/libuno_cppu.so.3(+0x15d94)[0x772d5d94]
/home/rene/libreoffice-7.5.4/instdir/program/libuno_cppu.so.3(+0x1d1fc)[0x772dd1fc]
/home/rene/libreoffice-7.5.4/instdir/program/libuno_cppu.so.3(uno_copyAndConvertData+0x30)[0x772da974]
/home/rene/libreoffice-7.5.4/instdir/program/libgcc3_uno.so(+0xbf8c)[0x6ca0bf8c]
/home/rene/libreoffice-7.5.4/instdir/program/libgcc3_uno.so(+0xcbc4)[0x6ca0cbc4]
/home/rene/libreoffice-7.5.4/instdir/program/libreflectionlo.so(+0x2942c)[0x63fc942c]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(+0x94ca0)[0x76794ca0]
/home/rene/libreoffice-7.5.4/instdir/program/libsvllo.so(_ZN14SfxBroadcaster9BroadcastERK7SfxHint+0x6c)[0x75f93a3c]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(_ZN11SbxVariable9BroadcastE9SfxHintId+0x16c)[0x768986e8]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(_ZN8SbxValueC2ERKS_+0xb0)[0x768906c8]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(_ZN11SbxVariableC2ERKS_+0x44)[0x76898874]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(_ZN9SbxMethodC1ERKS_+0x50)[0x768881f4]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(+0x13d69c)[0x7683d69c]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(+0x13e3cc)[0x7683e3cc]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(+0x131008)[0x76831008]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(+0xb4
test failures with new fonts-crosextra-carlito
Hi,
my beta1 (didn't try 7.5 yet) builds fail with a new verson of the
fonts-crosextra-carlito fonts (used for Calibri). LibreOffice itself ships
$ grep carlito download.lst
FONT_CARLITO_TARBALL :=
c74b7223abe75949b4af367942d96c7a-crosextrafonts-carlito-20130920.tar.gz
and Debian contained
fonts-crosextra-carlito | 20220224-1| stable | source, all
until June 13 where
fonts-crosextra-carlito | 20230309-1| testing | source, all
fonts-crosextra-carlito | 20230309-1| unstable | source, all
appeared. Looking at its commits
(https://github.com/googlefonts/carlito/commits/main) it seems that it's
actually this change which causes it:
https://github.com/googlefonts/carlito/commit/a46ae30787d4a0c9817afd4056c0042fbcfbafd6
which incidetially says "Fixed name tables, inconsistency in v-metric
(to match perfectly Calibri) and missing nbspace". So looks like
actually a bugfix.
Anyways, this breaks some of sds import tests (I tried this in a actual
beta1 "release" build, not on master - which worked before):
[build CUT] sd_import_tests2
S=/data/ssd/rene/libreoffice-7.6.0~beta1 && I=$S/instdir && W=$S/workdir
&& mkdir -p $W/CppunitTest/ && rm -fr
$W/CppunitTest/sd_import_tests2.test.user && cp -r $W/unittest
$W/CppunitTest/sd_import_tests2.test.user &&rm -fr
$W/CppunitTest/sd_import_tests2.test.core && mkdir
$W/CppunitTest/sd_import_tests2.test.core && cd
$W/CppunitTest/sd_import_tests2.test.core && ( MAX_CONCURRENCY=4
MOZILLA_CERTIFICATE_FOLDER=dbm:
SAL_DISABLE_SYNCHRONOUS_PRINTER_DETECTION=1 SAL_USE_VCLPLUGIN=svp
LIBO_LANG=C
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"$I/program:$I/program":$W/UnpackedTarball/cppunit/src/cppunit/.libs
$W/LinkTarget/Executable/cppunittester
$W/LinkTarget/CppunitTest/libtest_sd_import_tests2.so --headless
"-env:BRAND_BASE_DIR=file://$S/instdir" "-env:BRAND_SHARE_SUBDIR=share"
"-env:BRAND_SHARE_RESOURCE_SUBDIR=program/resource"
"-env:UserInstallation=file://$W/CppunitTest/sd_import_tests2.test.user"
"-env:CONFIGURATION_LAYERS=xcsxcu:file://$I/share/registry
xcsxcu:file://$W/unittest/registry-common
xcsxcu:file://$W/unittest/registry-user-ui"
"-env:UNO_TYPES=file://$I/program/types.rdb
file://$I/program/types/offapi.rdb"
"-env:UNO_SERVICES=file://$W/Rdb/ure/services.rdb
file://$W/ComponentTarget/animations/source/animcore/animcore.component
file://$W/ComponentTarget/basic/util/sb.component
file://$W/ComponentTarget/chart2/source/chartcore.component
file://$W/ComponentTarget/chart2/source/controller/chartcontroller.component
file://$W/ComponentTarget/comphelper/util/comphelp.component
file://$W/ComponentTarget/configmgr/source/configmgr.component
file://$W/ComponentTarget/dbaccess/util/dba.component
file://$W/ComponentTarget/desktop/source/deployment/deployment.component
file://$W/ComponentTarget/drawinglayer/drawinglayer.component
file://$W/ComponentTarget/embeddedobj/util/embobj.component
file://$W/ComponentTarget/emfio/emfio.component
file://$W/ComponentTarget/filter/source/config/cache/filterconfig1.component
file://$W/ComponentTarget/filter/source/odfflatxml/odfflatxml.component
file://$W/ComponentTarget/filter/source/svg/svgfilter.component
file://$W/ComponentTarget/filter/source/pdf/pdffilter.component
file://$W/ComponentTarget/filter/source/xmlfilteradaptor/xmlfa.component
file://$W/ComponentTarget/filter/source/xmlfilterdetect/xmlfd.component
file://$W/ComponentTarget/filter/source/storagefilterdetect/storagefd.component
file://$W/ComponentTarget/forms/util/frm.component
file://$W/ComponentTarget/framework/util/fwk.component
file://$W/ComponentTarget/i18npool/util/i18npool.component
file://$W/ComponentTarget/linguistic/source/lng.component
file://$W/ComponentTarget/oox/util/oox.component
file://$W/ComponentTarget/package/source/xstor/xstor.component
file://$W/ComponentTarget/package/util/package2.component
file://$W/ComponentTarget/sax/source/expatwrap/expwrap.component
file://$W/ComponentTarget/sd/util/sd.component
file://$W/ComponentTarget/sd/util/sdd.component
file://$W/ComponentTarget/sdext/source/pdfimport/pdfimport.component
file://$W/ComponentTarget/sfx2/util/sfx.component
file://$W/ComponentTarget/sot/util/sot.component
file://$W/ComponentTarget/svl/source/fsstor/fsstorage.component
file://$W/ComponentTarget/svtools/util/svt.component
file://$W/ComponentTarget/svx/util/svxcore.component
file://$W/ComponentTarget/svgio/svgio.component
file://$W/ComponentTarget/toolkit/util/tk.component
file://$W/ComponentTarget/ucb/source/core/ucb1.component
file://$W/ComponentTarget/ucb/source/ucp/expand/ucpexpand1.component
file://$W/ComponentTarget/ucb/source/ucp/file/ucpfile1.component
file://$W/ComponentTarget/ucb/source/ucp/package/ucppkg1.component
file://$W/ComponentTarget/ucb/source/ucp/tdoc/ucptdoc1.component
file://$W/ComponentTarget/unotools/util/utl.component
file://$W/ComponentTarget/unoxml/source/rdf/unordf.component
Usage of Source Han Serif SC
Hi,
I get the following in my build of the libreoffice-7-6 branch:
CUT] sw_core_text
S=/home/rene/LibreOffice/git/libreoffice-7-6 && I=$S/instdir &&
W=$S/workdir && mkdir -p $W/CppunitTest/ && rm -fr
$W/CppunitTest/sw_core_text.test.user && cp -r $W/unittest
$W/CppunitTest/sw_core_text.test.user &&rm -fr
$W/CppunitTest/sw_core_text.test.core && mkdir
$W/CppunitTest/sw_core_text.test.core && cd
$W/CppunitTest/sw_core_text.test.core && ( MAX_CONCURRENCY=4
MOZILLA_CERTIFICATE_FOLDER=dbm:
SAL_DISABLE_SYNCHRONOUS_PRINTER_DETECTION=1 SAL_USE_VCLPLUGIN=svp
LIBO_LANG=C
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"$I/program:$I/program":$W/UnpackedTarball/cppunit/src/cppunit/.libs
$W/LinkTarget/Executable/cppunittester
$W/LinkTarget/CppunitTest/libtest_sw_core_text.so --headless
"-env:BRAND_BASE_DIR=file://$S/instdir" "-env:BRAND_SHARE_SUBDIR=share"
"-env:BRAND_SHARE_RESOURCE_SUBDIR=program/resource"
"-env:UserInstallation=file://$W/CppunitTest/sw_core_text.test.user"
"-env:CONFIGURATION_LAYERS=xcsxcu:file://$I/share/registry
xcsxcu:file://$W/unittest/registry-common
xcsxcu:file://$W/unittest/registry-user-ui"
"-env:UNO_TYPES=file://$I/program/types.rdb
file://$I/program/types/offapi.rdb file://$I/program/types/oovbaapi.rdb"
"-env:UNO_SERVICES=file://$W/Rdb/ure/services.rdb
file://$W/Rdb/services.rdb" -env:URE_BIN_DIR=file://$I/program
-env:URE_INTERNAL_LIB_DIR=file://$I/program
-env:LO_LIB_DIR=file://$I/program
-env:LO_JAVA_DIR=file://$I/program/classes --protector
$W/LinkTarget/Library/unoexceptionprotector.so unoexceptionprotector
--protector $W/LinkTarget/Library/unobootstrapprotector.so
unobootstrapprotector --protector
$W/LinkTarget/Library/libvclbootstrapprotector.so vclbootstrapprotector
"-env:CPPUNITTESTTARGET=$W/CppunitTest/sw_core_text.test" ) 2>&1
[...]
[_RUN_] testTdf129810::TestBody
file:///home/rene/LibreOffice/git/libreoffice-7-6//sw/qa/core/text/data//tdf129810.odt:
./sw/qa/core/text/text.cxx:1387:testTdf129810::TestBody
greater assertion failed
- Expected greater than: 13
- Actual : 13
[...]
That test was added with
commit 3548c92453b9d0d85270bc6309a91c4107e49685
Author: Khaled Hosny
Date: Fri Jun 23 19:10:49 2023 +0300
tdf#129810: Compress fullwidth CJK punctuation
When compressions CJK punctuation, compress also full width versions to
match Word behaviour.
Change-Id: Ic35cfcbacca1974b7241d657f078148bac06478e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153530
Tested-by: Jenkins
Reviewed-by: خالد حسني
(cherry picked from commit 4a92323b54e7d63a8bc0b8e62fdc6b31760dcd05)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153519
This should work around it:
diff --git a/sw/qa/core/text/text.cxx b/sw/qa/core/text/text.cxx
index a4d4540ab228..46d262f6f0b8 100644
--- a/sw/qa/core/text/text.cxx
+++ b/sw/qa/core/text/text.cxx
@@ -9,6 +9,8 @@
#include
+#include
+
#include
#include
@@ -1363,6 +1365,8 @@ CPPUNIT_TEST_FIXTURE(SwCoreTextTest,
testParaUpperMarginFlyIntersect)
CPPUNIT_ASSERT_EQUAL(521, nHeight);
}
+/* needs Source Han Serif SC*/
+#if HAVE_MORE_FONTS
CPPUNIT_TEST_FIXTURE(SwCoreTextTest, testTdf129810)
{
// Load the document, which embeds a CJK font.
@@ -1394,6 +1398,7 @@ CPPUNIT_TEST_FIXTURE(SwCoreTextTest, testTdf129810)
}
}
}
+#endif
CPPUNIT_PLUGIN_IMPLEMENT();
(keep the comment or not, don't mind, none of other checks has it but it
was/is there for my notes and the actual Debian patch file...)
But the root question is here how this ever worked? On your system it
might be thgere but on the Jenkins nodes?
Since "standard" LibreOffice builds use the stuff downloaded, but
download.lst neither contains any source fonts (anymore) nor that font
specifically...
rene@frodo:~/LibreOffice/git/libreoffice-7-6$ grep -i sans download.lst;
grep -i source download.lst; grep -i han download.lst
# so upgrading to a new version only requires changes in download.lst.
FREEHAND_SHA256SUM :=
0e422d1564a6dbf22a9af598535425271e583514c0f7ba7d9091676420de34ac
FREEHAND_TARBALL := libfreehand-0.1.2.tar.xz
rene@frodo:~/LibreOffice/git/libreoffice-7-6$
(Theer is a subset of that font in vcl/qa/cppunit/data/tdf107718.otf but
that is a) a subset b) obviously not used in sws tests)
Regards,
Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi, Am 20.06.23 um 16:52 schrieb Kurt Roeckx: On Tue, Jun 20, 2023 at 05:52:44AM +0200, Rene Engelhard wrote: Hi, Am 19.06.23 um 23:29 schrieb Rene Engelhard: The pragmatic option would be to run only a smoketest for build success on architectures not tested by upstream. And have Format->Character in Impress crash with Bus error like on mipsel? That doesn't sound too good for basic quality. There is a "smoketest" but it does just basic start. open, close stuff. Not even basic usage. That said, that is the smoketest on mipsel: The problem with a mail like this is that it really doesn't help anybody in understanding the problem. As porter, it will probably take a lot of time to get to the point where you can start looking at what the problem might be. It contains lots of information, but it's not clear what the problem is and what needs to be looked at. Except by just starting to build and run into an issue (process:8700): dconf-CRITICAL **: 02:36:13.575: unable to create directory '/run/user/2952/dconf': Permission denied. dconf will not work properly. (process:8708): dconf-CRITICAL **: 02:36:19.328: unable to create directory '/run/user/2952/dconf': Permission denied. dconf will not work properly. (process:8815): dconf-CRITICAL **: 02:36:52.467: unable to create directory '/run/user/2952/dconf': Permission denied. dconf will not work properly. Is this something the porter should look at? Is is relevant? No. That also happens everywhere, also on amd64/arm64. Fatal exception: Signal 11 It's a segfault, I know :) this should normally be trivial for you to debug, but is probably complicated for a porter to find out how to do things like attaching a debugger to the relevant process. Well, the command line is there, but I see the point. Still one could talk about this... I yet have to hear from any porter talking about actual issues (and the buildlogs *are* there). Stack: /<>/instdir/program/libuno_sal.so.3(+0x49b18)[0x77d69b18] /<>/instdir/program/libuno_sal.so.3(+0x49d48)[0x77d69d48] /usr/lib/jvm/java-17-openjdk-mipsel/lib/server/libjvm.so(+0x537b8c)[0x62417b8c] Is this some openjdk problem, not a problem in libreoffice problem? In this specific case probably openjdk. I was juat answering Adrian on the smoketest. Actually I run a --disable-java build on eller right now. ./smoketest/smoketest.cxx:187:(anonymous namespace)::Test::test assertion failed - Expression: connection_.isStillAlive() So the (TCP?) connection is not alive? Why not? That doesn't seem to be platform specific. Is that a problem in the test suite, and not libreoffice itself? Because libreoffice crashed, "obviously", so there of course is no connection anymore. The point here is that it even crashes at startup so probably being completely broken. (and I am not surprised) unknown:0:(anonymous namespace)::Test::test tearDown() failed - An uncaught exception of type com.sun.star.lang.DisposedException - Binary URP bridge already disposed at ./binaryurp/source/bridge.cxx:1048 (anonymous namespace)::Test::test finished in: 76764ms smoketest.cxx:187:Assertion Test name: (anonymous namespace)::Test::test assertion failed - Expression: connection_.isStillAlive() ##Failure Location unknown## : Error Test name: (anonymous namespace)::Test::test tearDown() failed - An uncaught exception of type com.sun.star.lang.DisposedException And then the test suite crashes because it can't actually deal with the previous the assertion failure, and the segfault above is not relevant at all? It crashes because libreoffice crashed, the connection is not there and therefore not alive. Yes, I can read that. As said, I was just pointing at a smoketest example. The most likely thing is that this is not a platform specific issue, but a either a general issue that just shows up on some platforms for whatever reason, or some problem in an other piece of software that libreoffice is using that does have a pratform specific issue. This specific one might be, yes. That's probably not true for the other architectures' failures. (E.g. the Bus error I mentioned earlier or the powerpcs having "Trace/breakpoint trap (core dumped)" or s390x or armel crashing in loading tiff files. And that is all only the first failure on earch archs, there's more, there's gazillions of failures in the architectures' build logs. Regards, Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi, Am 20.06.23 um 16:52 schrieb Kurt Roeckx: On Tue, Jun 20, 2023 at 05:52:44AM +0200, Rene Engelhard wrote: Hi, Am 19.06.23 um 23:29 schrieb Rene Engelhard: The pragmatic option would be to run only a smoketest for build success on architectures not tested by upstream. And have Format->Character in Impress crash with Bus error like on mipsel? That doesn't sound too good for basic quality. There is a "smoketest" but it does just basic start. open, close stuff. Not even basic usage. That said, that is the smoketest on mipsel: The problem with a mail like this is that it really doesn't help anybody in understanding the problem. As porter, it will probably take a lot of time to get to the point where you can start looking at what the problem might be. It contains lots of information, but it's not clear what the problem is and what needs to be looked at. Except by just starting to build and run into an issue (process:8700): dconf-CRITICAL **: 02:36:13.575: unable to create directory '/run/user/2952/dconf': Permission denied. dconf will not work properly. (process:8708): dconf-CRITICAL **: 02:36:19.328: unable to create directory '/run/user/2952/dconf': Permission denied. dconf will not work properly. (process:8815): dconf-CRITICAL **: 02:36:52.467: unable to create directory '/run/user/2952/dconf': Permission denied. dconf will not work properly. Is this something the porter should look at? Is is relevant? No. That also happens everywhere, also on amd64/arm64. Fatal exception: Signal 11 It's a segfault, I know :) this should normally be trivial for you to debug, but is probably complicated for a porter to find out how to do things like attaching a debugger to the relevant process. Well, the command line is there, but I see the point. Still one could talk about this... I yet have to hear from any porter talking about actual issues (and the buildlogs *are* there). Stack: /<>/instdir/program/libuno_sal.so.3(+0x49b18)[0x77d69b18] /<>/instdir/program/libuno_sal.so.3(+0x49d48)[0x77d69d48] /usr/lib/jvm/java-17-openjdk-mipsel/lib/server/libjvm.so(+0x537b8c)[0x62417b8c] Is this some openjdk problem, not a problem in libreoffice problem? In this specific case probably openjdk. I was juat answering Adrian on the smoketest. Actually I run a --disable-java build on eller right now. ./smoketest/smoketest.cxx:187:(anonymous namespace)::Test::test assertion failed - Expression: connection_.isStillAlive() So the (TCP?) connection is not alive? Why not? That doesn't seem to be platform specific. Is that a problem in the test suite, and not libreoffice itself? Because libreoffice crashed, "obviously", so there of course is no connection anymore. The point here is that it even crashes at startup so probably being completely broken. (and I am not surprised) unknown:0:(anonymous namespace)::Test::test tearDown() failed - An uncaught exception of type com.sun.star.lang.DisposedException - Binary URP bridge already disposed at ./binaryurp/source/bridge.cxx:1048 (anonymous namespace)::Test::test finished in: 76764ms smoketest.cxx:187:Assertion Test name: (anonymous namespace)::Test::test assertion failed - Expression: connection_.isStillAlive() ##Failure Location unknown## : Error Test name: (anonymous namespace)::Test::test tearDown() failed - An uncaught exception of type com.sun.star.lang.DisposedException And then the test suite crashes because it can't actually deal with the previous the assertion failure, and the segfault above is not relevant at all? It crashes because libreoffice crashed, the connection is not there and therefore not alive. Yes, I can read that. As said, I was just pointing at a smoketest example. The most likely thing is that this is not a platform specific issue, but a either a general issue that just shows up on some platforms for whatever reason, or some problem in an other piece of software that libreoffice is using that does have a pratform specific issue. This specific one might be, yes. That's probably not true for the other architectures' failures. (E.g. the Bus error I mentioned earlier or the powerpcs having "Trace/breakpoint trap (core dumped)" or s390x or armel crashing in loading tiff files. And that is all only the first failure on earch archs, there's more, there's gazillions of failures in the architectures' build logs. Regards, Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi, Am 20.06.23 um 16:52 schrieb Kurt Roeckx: On Tue, Jun 20, 2023 at 05:52:44AM +0200, Rene Engelhard wrote: Hi, Am 19.06.23 um 23:29 schrieb Rene Engelhard: The pragmatic option would be to run only a smoketest for build success on architectures not tested by upstream. And have Format->Character in Impress crash with Bus error like on mipsel? That doesn't sound too good for basic quality. There is a "smoketest" but it does just basic start. open, close stuff. Not even basic usage. That said, that is the smoketest on mipsel: The problem with a mail like this is that it really doesn't help anybody in understanding the problem. As porter, it will probably take a lot of time to get to the point where you can start looking at what the problem might be. It contains lots of information, but it's not clear what the problem is and what needs to be looked at. Except by just starting to build and run into an issue (process:8700): dconf-CRITICAL **: 02:36:13.575: unable to create directory '/run/user/2952/dconf': Permission denied. dconf will not work properly. (process:8708): dconf-CRITICAL **: 02:36:19.328: unable to create directory '/run/user/2952/dconf': Permission denied. dconf will not work properly. (process:8815): dconf-CRITICAL **: 02:36:52.467: unable to create directory '/run/user/2952/dconf': Permission denied. dconf will not work properly. Is this something the porter should look at? Is is relevant? No. That also happens everywhere, also on amd64/arm64. Fatal exception: Signal 11 It's a segfault, I know :) this should normally be trivial for you to debug, but is probably complicated for a porter to find out how to do things like attaching a debugger to the relevant process. Well, the command line is there, but I see the point. Still one could talk about this... I yet have to hear from any porter talking about actual issues (and the buildlogs *are* there). Stack: /<>/instdir/program/libuno_sal.so.3(+0x49b18)[0x77d69b18] /<>/instdir/program/libuno_sal.so.3(+0x49d48)[0x77d69d48] /usr/lib/jvm/java-17-openjdk-mipsel/lib/server/libjvm.so(+0x537b8c)[0x62417b8c] Is this some openjdk problem, not a problem in libreoffice problem? In this specific case probably openjdk. I was juat answering Adrian on the smoketest. Actually I run a --disable-java build on eller right now. ./smoketest/smoketest.cxx:187:(anonymous namespace)::Test::test assertion failed - Expression: connection_.isStillAlive() So the (TCP?) connection is not alive? Why not? That doesn't seem to be platform specific. Is that a problem in the test suite, and not libreoffice itself? Because libreoffice crashed, "obviously", so there of course is no connection anymore. The point here is that it even crashes at startup so probably being completely broken. (and I am not surprised) unknown:0:(anonymous namespace)::Test::test tearDown() failed - An uncaught exception of type com.sun.star.lang.DisposedException - Binary URP bridge already disposed at ./binaryurp/source/bridge.cxx:1048 (anonymous namespace)::Test::test finished in: 76764ms smoketest.cxx:187:Assertion Test name: (anonymous namespace)::Test::test assertion failed - Expression: connection_.isStillAlive() ##Failure Location unknown## : Error Test name: (anonymous namespace)::Test::test tearDown() failed - An uncaught exception of type com.sun.star.lang.DisposedException And then the test suite crashes because it can't actually deal with the previous the assertion failure, and the segfault above is not relevant at all? It crashes because libreoffice crashed, the connection is not there and therefore not alive. Yes, I can read that. As said, I was just pointing at a smoketest example. The most likely thing is that this is not a platform specific issue, but a either a general issue that just shows up on some platforms for whatever reason, or some problem in an other piece of software that libreoffice is using that does have a pratform specific issue. This specific one might be, yes. That's probably not true for the other architectures' failures. (E.g. the Bus error I mentioned earlier or the powerpcs having "Trace/breakpoint trap (core dumped)" or s390x or armel crashing in loading tiff files. And that is all only the first failure on earch archs, there's more, there's gazillions of failures in the architectures' build logs. Regards, Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi, Am 20.06.23 um 16:52 schrieb Kurt Roeckx: On Tue, Jun 20, 2023 at 05:52:44AM +0200, Rene Engelhard wrote: Hi, Am 19.06.23 um 23:29 schrieb Rene Engelhard: The pragmatic option would be to run only a smoketest for build success on architectures not tested by upstream. And have Format->Character in Impress crash with Bus error like on mipsel? That doesn't sound too good for basic quality. There is a "smoketest" but it does just basic start. open, close stuff. Not even basic usage. That said, that is the smoketest on mipsel: The problem with a mail like this is that it really doesn't help anybody in understanding the problem. As porter, it will probably take a lot of time to get to the point where you can start looking at what the problem might be. It contains lots of information, but it's not clear what the problem is and what needs to be looked at. Except by just starting to build and run into an issue (process:8700): dconf-CRITICAL **: 02:36:13.575: unable to create directory '/run/user/2952/dconf': Permission denied. dconf will not work properly. (process:8708): dconf-CRITICAL **: 02:36:19.328: unable to create directory '/run/user/2952/dconf': Permission denied. dconf will not work properly. (process:8815): dconf-CRITICAL **: 02:36:52.467: unable to create directory '/run/user/2952/dconf': Permission denied. dconf will not work properly. Is this something the porter should look at? Is is relevant? No. That also happens everywhere, also on amd64/arm64. Fatal exception: Signal 11 It's a segfault, I know :) this should normally be trivial for you to debug, but is probably complicated for a porter to find out how to do things like attaching a debugger to the relevant process. Well, the command line is there, but I see the point. Still one could talk about this... I yet have to hear from any porter talking about actual issues (and the buildlogs *are* there). Stack: /<>/instdir/program/libuno_sal.so.3(+0x49b18)[0x77d69b18] /<>/instdir/program/libuno_sal.so.3(+0x49d48)[0x77d69d48] /usr/lib/jvm/java-17-openjdk-mipsel/lib/server/libjvm.so(+0x537b8c)[0x62417b8c] Is this some openjdk problem, not a problem in libreoffice problem? In this specific case probably openjdk. I was juat answering Adrian on the smoketest. Actually I run a --disable-java build on eller right now. ./smoketest/smoketest.cxx:187:(anonymous namespace)::Test::test assertion failed - Expression: connection_.isStillAlive() So the (TCP?) connection is not alive? Why not? That doesn't seem to be platform specific. Is that a problem in the test suite, and not libreoffice itself? Because libreoffice crashed, "obviously", so there of course is no connection anymore. The point here is that it even crashes at startup so probably being completely broken. (and I am not surprised) unknown:0:(anonymous namespace)::Test::test tearDown() failed - An uncaught exception of type com.sun.star.lang.DisposedException - Binary URP bridge already disposed at ./binaryurp/source/bridge.cxx:1048 (anonymous namespace)::Test::test finished in: 76764ms smoketest.cxx:187:Assertion Test name: (anonymous namespace)::Test::test assertion failed - Expression: connection_.isStillAlive() ##Failure Location unknown## : Error Test name: (anonymous namespace)::Test::test tearDown() failed - An uncaught exception of type com.sun.star.lang.DisposedException And then the test suite crashes because it can't actually deal with the previous the assertion failure, and the segfault above is not relevant at all? It crashes because libreoffice crashed, the connection is not there and therefore not alive. Yes, I can read that. As said, I was just pointing at a smoketest example. The most likely thing is that this is not a platform specific issue, but a either a general issue that just shows up on some platforms for whatever reason, or some problem in an other piece of software that libreoffice is using that does have a pratform specific issue. This specific one might be, yes. That's probably not true for the other architectures' failures. (E.g. the Bus error I mentioned earlier or the powerpcs having "Trace/breakpoint trap (core dumped)" or s390x or armel crashing in loading tiff files. And that is all only the first failure on earch archs, there's more, there's gazillions of failures in the architectures' build logs. Regards, Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi, Am 20.06.23 um 16:52 schrieb Kurt Roeckx: On Tue, Jun 20, 2023 at 05:52:44AM +0200, Rene Engelhard wrote: Hi, Am 19.06.23 um 23:29 schrieb Rene Engelhard: The pragmatic option would be to run only a smoketest for build success on architectures not tested by upstream. And have Format->Character in Impress crash with Bus error like on mipsel? That doesn't sound too good for basic quality. There is a "smoketest" but it does just basic start. open, close stuff. Not even basic usage. That said, that is the smoketest on mipsel: The problem with a mail like this is that it really doesn't help anybody in understanding the problem. As porter, it will probably take a lot of time to get to the point where you can start looking at what the problem might be. It contains lots of information, but it's not clear what the problem is and what needs to be looked at. Except by just starting to build and run into an issue (process:8700): dconf-CRITICAL **: 02:36:13.575: unable to create directory '/run/user/2952/dconf': Permission denied. dconf will not work properly. (process:8708): dconf-CRITICAL **: 02:36:19.328: unable to create directory '/run/user/2952/dconf': Permission denied. dconf will not work properly. (process:8815): dconf-CRITICAL **: 02:36:52.467: unable to create directory '/run/user/2952/dconf': Permission denied. dconf will not work properly. Is this something the porter should look at? Is is relevant? No. That also happens everywhere, also on amd64/arm64. Fatal exception: Signal 11 It's a segfault, I know :) this should normally be trivial for you to debug, but is probably complicated for a porter to find out how to do things like attaching a debugger to the relevant process. Well, the command line is there, but I see the point. Still one could talk about this... I yet have to hear from any porter talking about actual issues (and the buildlogs *are* there). Stack: /<>/instdir/program/libuno_sal.so.3(+0x49b18)[0x77d69b18] /<>/instdir/program/libuno_sal.so.3(+0x49d48)[0x77d69d48] /usr/lib/jvm/java-17-openjdk-mipsel/lib/server/libjvm.so(+0x537b8c)[0x62417b8c] Is this some openjdk problem, not a problem in libreoffice problem? In this specific case probably openjdk. I was juat answering Adrian on the smoketest. Actually I run a --disable-java build on eller right now. ./smoketest/smoketest.cxx:187:(anonymous namespace)::Test::test assertion failed - Expression: connection_.isStillAlive() So the (TCP?) connection is not alive? Why not? That doesn't seem to be platform specific. Is that a problem in the test suite, and not libreoffice itself? Because libreoffice crashed, "obviously", so there of course is no connection anymore. The point here is that it even crashes at startup so probably being completely broken. (and I am not surprised) unknown:0:(anonymous namespace)::Test::test tearDown() failed - An uncaught exception of type com.sun.star.lang.DisposedException - Binary URP bridge already disposed at ./binaryurp/source/bridge.cxx:1048 (anonymous namespace)::Test::test finished in: 76764ms smoketest.cxx:187:Assertion Test name: (anonymous namespace)::Test::test assertion failed - Expression: connection_.isStillAlive() ##Failure Location unknown## : Error Test name: (anonymous namespace)::Test::test tearDown() failed - An uncaught exception of type com.sun.star.lang.DisposedException And then the test suite crashes because it can't actually deal with the previous the assertion failure, and the segfault above is not relevant at all? It crashes because libreoffice crashed, the connection is not there and therefore not alive. Yes, I can read that. As said, I was just pointing at a smoketest example. The most likely thing is that this is not a platform specific issue, but a either a general issue that just shows up on some platforms for whatever reason, or some problem in an other piece of software that libreoffice is using that does have a pratform specific issue. This specific one might be, yes. That's probably not true for the other architectures' failures. (E.g. the Bus error I mentioned earlier or the powerpcs having "Trace/breakpoint trap (core dumped)" or s390x or armel crashing in loading tiff files. And that is all only the first failure on earch archs, there's more, there's gazillions of failures in the architectures' build logs. Regards, Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi, Am 20.06.23 um 16:52 schrieb Kurt Roeckx: On Tue, Jun 20, 2023 at 05:52:44AM +0200, Rene Engelhard wrote: Hi, Am 19.06.23 um 23:29 schrieb Rene Engelhard: The pragmatic option would be to run only a smoketest for build success on architectures not tested by upstream. And have Format->Character in Impress crash with Bus error like on mipsel? That doesn't sound too good for basic quality. There is a "smoketest" but it does just basic start. open, close stuff. Not even basic usage. That said, that is the smoketest on mipsel: The problem with a mail like this is that it really doesn't help anybody in understanding the problem. As porter, it will probably take a lot of time to get to the point where you can start looking at what the problem might be. It contains lots of information, but it's not clear what the problem is and what needs to be looked at. Except by just starting to build and run into an issue (process:8700): dconf-CRITICAL **: 02:36:13.575: unable to create directory '/run/user/2952/dconf': Permission denied. dconf will not work properly. (process:8708): dconf-CRITICAL **: 02:36:19.328: unable to create directory '/run/user/2952/dconf': Permission denied. dconf will not work properly. (process:8815): dconf-CRITICAL **: 02:36:52.467: unable to create directory '/run/user/2952/dconf': Permission denied. dconf will not work properly. Is this something the porter should look at? Is is relevant? No. That also happens everywhere, also on amd64/arm64. Fatal exception: Signal 11 It's a segfault, I know :) this should normally be trivial for you to debug, but is probably complicated for a porter to find out how to do things like attaching a debugger to the relevant process. Well, the command line is there, but I see the point. Still one could talk about this... I yet have to hear from any porter talking about actual issues (and the buildlogs *are* there). Stack: /<>/instdir/program/libuno_sal.so.3(+0x49b18)[0x77d69b18] /<>/instdir/program/libuno_sal.so.3(+0x49d48)[0x77d69d48] /usr/lib/jvm/java-17-openjdk-mipsel/lib/server/libjvm.so(+0x537b8c)[0x62417b8c] Is this some openjdk problem, not a problem in libreoffice problem? In this specific case probably openjdk. I was juat answering Adrian on the smoketest. Actually I run a --disable-java build on eller right now. ./smoketest/smoketest.cxx:187:(anonymous namespace)::Test::test assertion failed - Expression: connection_.isStillAlive() So the (TCP?) connection is not alive? Why not? That doesn't seem to be platform specific. Is that a problem in the test suite, and not libreoffice itself? Because libreoffice crashed, "obviously", so there of course is no connection anymore. The point here is that it even crashes at startup so probably being completely broken. (and I am not surprised) unknown:0:(anonymous namespace)::Test::test tearDown() failed - An uncaught exception of type com.sun.star.lang.DisposedException - Binary URP bridge already disposed at ./binaryurp/source/bridge.cxx:1048 (anonymous namespace)::Test::test finished in: 76764ms smoketest.cxx:187:Assertion Test name: (anonymous namespace)::Test::test assertion failed - Expression: connection_.isStillAlive() ##Failure Location unknown## : Error Test name: (anonymous namespace)::Test::test tearDown() failed - An uncaught exception of type com.sun.star.lang.DisposedException And then the test suite crashes because it can't actually deal with the previous the assertion failure, and the segfault above is not relevant at all? It crashes because libreoffice crashed, the connection is not there and therefore not alive. Yes, I can read that. As said, I was just pointing at a smoketest example. The most likely thing is that this is not a platform specific issue, but a either a general issue that just shows up on some platforms for whatever reason, or some problem in an other piece of software that libreoffice is using that does have a pratform specific issue. This specific one might be, yes. That's probably not true for the other architectures' failures. (E.g. the Bus error I mentioned earlier or the powerpcs having "Trace/breakpoint trap (core dumped)" or s390x or armel crashing in loading tiff files. And that is all only the first failure on earch archs, there's more, there's gazillions of failures in the architectures' build logs. Regards, Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi, Am 20.06.23 um 16:52 schrieb Kurt Roeckx: On Tue, Jun 20, 2023 at 05:52:44AM +0200, Rene Engelhard wrote: Hi, Am 19.06.23 um 23:29 schrieb Rene Engelhard: The pragmatic option would be to run only a smoketest for build success on architectures not tested by upstream. And have Format->Character in Impress crash with Bus error like on mipsel? That doesn't sound too good for basic quality. There is a "smoketest" but it does just basic start. open, close stuff. Not even basic usage. That said, that is the smoketest on mipsel: The problem with a mail like this is that it really doesn't help anybody in understanding the problem. As porter, it will probably take a lot of time to get to the point where you can start looking at what the problem might be. It contains lots of information, but it's not clear what the problem is and what needs to be looked at. Except by just starting to build and run into an issue (process:8700): dconf-CRITICAL **: 02:36:13.575: unable to create directory '/run/user/2952/dconf': Permission denied. dconf will not work properly. (process:8708): dconf-CRITICAL **: 02:36:19.328: unable to create directory '/run/user/2952/dconf': Permission denied. dconf will not work properly. (process:8815): dconf-CRITICAL **: 02:36:52.467: unable to create directory '/run/user/2952/dconf': Permission denied. dconf will not work properly. Is this something the porter should look at? Is is relevant? No. That also happens everywhere, also on amd64/arm64. Fatal exception: Signal 11 It's a segfault, I know :) this should normally be trivial for you to debug, but is probably complicated for a porter to find out how to do things like attaching a debugger to the relevant process. Well, the command line is there, but I see the point. Still one could talk about this... I yet have to hear from any porter talking about actual issues (and the buildlogs *are* there). Stack: /<>/instdir/program/libuno_sal.so.3(+0x49b18)[0x77d69b18] /<>/instdir/program/libuno_sal.so.3(+0x49d48)[0x77d69d48] /usr/lib/jvm/java-17-openjdk-mipsel/lib/server/libjvm.so(+0x537b8c)[0x62417b8c] Is this some openjdk problem, not a problem in libreoffice problem? In this specific case probably openjdk. I was juat answering Adrian on the smoketest. Actually I run a --disable-java build on eller right now. ./smoketest/smoketest.cxx:187:(anonymous namespace)::Test::test assertion failed - Expression: connection_.isStillAlive() So the (TCP?) connection is not alive? Why not? That doesn't seem to be platform specific. Is that a problem in the test suite, and not libreoffice itself? Because libreoffice crashed, "obviously", so there of course is no connection anymore. The point here is that it even crashes at startup so probably being completely broken. (and I am not surprised) unknown:0:(anonymous namespace)::Test::test tearDown() failed - An uncaught exception of type com.sun.star.lang.DisposedException - Binary URP bridge already disposed at ./binaryurp/source/bridge.cxx:1048 (anonymous namespace)::Test::test finished in: 76764ms smoketest.cxx:187:Assertion Test name: (anonymous namespace)::Test::test assertion failed - Expression: connection_.isStillAlive() ##Failure Location unknown## : Error Test name: (anonymous namespace)::Test::test tearDown() failed - An uncaught exception of type com.sun.star.lang.DisposedException And then the test suite crashes because it can't actually deal with the previous the assertion failure, and the segfault above is not relevant at all? It crashes because libreoffice crashed, the connection is not there and therefore not alive. Yes, I can read that. As said, I was just pointing at a smoketest example. The most likely thing is that this is not a platform specific issue, but a either a general issue that just shows up on some platforms for whatever reason, or some problem in an other piece of software that libreoffice is using that does have a pratform specific issue. This specific one might be, yes. That's probably not true for the other architectures' failures. (E.g. the Bus error I mentioned earlier or the powerpcs having "Trace/breakpoint trap (core dumped)" or s390x or armel crashing in loading tiff files. And that is all only the first failure on earch archs, there's more, there's gazillions of failures in the architectures' build logs. Regards, Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi, Am 20.06.23 um 16:52 schrieb Kurt Roeckx: On Tue, Jun 20, 2023 at 05:52:44AM +0200, Rene Engelhard wrote: Hi, Am 19.06.23 um 23:29 schrieb Rene Engelhard: The pragmatic option would be to run only a smoketest for build success on architectures not tested by upstream. And have Format->Character in Impress crash with Bus error like on mipsel? That doesn't sound too good for basic quality. There is a "smoketest" but it does just basic start. open, close stuff. Not even basic usage. That said, that is the smoketest on mipsel: The problem with a mail like this is that it really doesn't help anybody in understanding the problem. As porter, it will probably take a lot of time to get to the point where you can start looking at what the problem might be. It contains lots of information, but it's not clear what the problem is and what needs to be looked at. Except by just starting to build and run into an issue (process:8700): dconf-CRITICAL **: 02:36:13.575: unable to create directory '/run/user/2952/dconf': Permission denied. dconf will not work properly. (process:8708): dconf-CRITICAL **: 02:36:19.328: unable to create directory '/run/user/2952/dconf': Permission denied. dconf will not work properly. (process:8815): dconf-CRITICAL **: 02:36:52.467: unable to create directory '/run/user/2952/dconf': Permission denied. dconf will not work properly. Is this something the porter should look at? Is is relevant? No. That also happens everywhere, also on amd64/arm64. Fatal exception: Signal 11 It's a segfault, I know :) this should normally be trivial for you to debug, but is probably complicated for a porter to find out how to do things like attaching a debugger to the relevant process. Well, the command line is there, but I see the point. Still one could talk about this... I yet have to hear from any porter talking about actual issues (and the buildlogs *are* there). Stack: /<>/instdir/program/libuno_sal.so.3(+0x49b18)[0x77d69b18] /<>/instdir/program/libuno_sal.so.3(+0x49d48)[0x77d69d48] /usr/lib/jvm/java-17-openjdk-mipsel/lib/server/libjvm.so(+0x537b8c)[0x62417b8c] Is this some openjdk problem, not a problem in libreoffice problem? In this specific case probably openjdk. I was juat answering Adrian on the smoketest. Actually I run a --disable-java build on eller right now. ./smoketest/smoketest.cxx:187:(anonymous namespace)::Test::test assertion failed - Expression: connection_.isStillAlive() So the (TCP?) connection is not alive? Why not? That doesn't seem to be platform specific. Is that a problem in the test suite, and not libreoffice itself? Because libreoffice crashed, "obviously", so there of course is no connection anymore. The point here is that it even crashes at startup so probably being completely broken. (and I am not surprised) unknown:0:(anonymous namespace)::Test::test tearDown() failed - An uncaught exception of type com.sun.star.lang.DisposedException - Binary URP bridge already disposed at ./binaryurp/source/bridge.cxx:1048 (anonymous namespace)::Test::test finished in: 76764ms smoketest.cxx:187:Assertion Test name: (anonymous namespace)::Test::test assertion failed - Expression: connection_.isStillAlive() ##Failure Location unknown## : Error Test name: (anonymous namespace)::Test::test tearDown() failed - An uncaught exception of type com.sun.star.lang.DisposedException And then the test suite crashes because it can't actually deal with the previous the assertion failure, and the segfault above is not relevant at all? It crashes because libreoffice crashed, the connection is not there and therefore not alive. Yes, I can read that. As said, I was just pointing at a smoketest example. The most likely thing is that this is not a platform specific issue, but a either a general issue that just shows up on some platforms for whatever reason, or some problem in an other piece of software that libreoffice is using that does have a pratform specific issue. This specific one might be, yes. That's probably not true for the other architectures' failures. (E.g. the Bus error I mentioned earlier or the powerpcs having "Trace/breakpoint trap (core dumped)" or s390x or armel crashing in loading tiff files. And that is all only the first failure on earch archs, there's more, there's gazillions of failures in the architectures' build logs. Regards, Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi, Am 20.06.23 um 16:52 schrieb Kurt Roeckx: On Tue, Jun 20, 2023 at 05:52:44AM +0200, Rene Engelhard wrote: Hi, Am 19.06.23 um 23:29 schrieb Rene Engelhard: The pragmatic option would be to run only a smoketest for build success on architectures not tested by upstream. And have Format->Character in Impress crash with Bus error like on mipsel? That doesn't sound too good for basic quality. There is a "smoketest" but it does just basic start. open, close stuff. Not even basic usage. That said, that is the smoketest on mipsel: The problem with a mail like this is that it really doesn't help anybody in understanding the problem. As porter, it will probably take a lot of time to get to the point where you can start looking at what the problem might be. It contains lots of information, but it's not clear what the problem is and what needs to be looked at. Except by just starting to build and run into an issue (process:8700): dconf-CRITICAL **: 02:36:13.575: unable to create directory '/run/user/2952/dconf': Permission denied. dconf will not work properly. (process:8708): dconf-CRITICAL **: 02:36:19.328: unable to create directory '/run/user/2952/dconf': Permission denied. dconf will not work properly. (process:8815): dconf-CRITICAL **: 02:36:52.467: unable to create directory '/run/user/2952/dconf': Permission denied. dconf will not work properly. Is this something the porter should look at? Is is relevant? No. That also happens everywhere, also on amd64/arm64. Fatal exception: Signal 11 It's a segfault, I know :) this should normally be trivial for you to debug, but is probably complicated for a porter to find out how to do things like attaching a debugger to the relevant process. Well, the command line is there, but I see the point. Still one could talk about this... I yet have to hear from any porter talking about actual issues (and the buildlogs *are* there). Stack: /<>/instdir/program/libuno_sal.so.3(+0x49b18)[0x77d69b18] /<>/instdir/program/libuno_sal.so.3(+0x49d48)[0x77d69d48] /usr/lib/jvm/java-17-openjdk-mipsel/lib/server/libjvm.so(+0x537b8c)[0x62417b8c] Is this some openjdk problem, not a problem in libreoffice problem? In this specific case probably openjdk. I was juat answering Adrian on the smoketest. Actually I run a --disable-java build on eller right now. ./smoketest/smoketest.cxx:187:(anonymous namespace)::Test::test assertion failed - Expression: connection_.isStillAlive() So the (TCP?) connection is not alive? Why not? That doesn't seem to be platform specific. Is that a problem in the test suite, and not libreoffice itself? Because libreoffice crashed, "obviously", so there of course is no connection anymore. The point here is that it even crashes at startup so probably being completely broken. (and I am not surprised) unknown:0:(anonymous namespace)::Test::test tearDown() failed - An uncaught exception of type com.sun.star.lang.DisposedException - Binary URP bridge already disposed at ./binaryurp/source/bridge.cxx:1048 (anonymous namespace)::Test::test finished in: 76764ms smoketest.cxx:187:Assertion Test name: (anonymous namespace)::Test::test assertion failed - Expression: connection_.isStillAlive() ##Failure Location unknown## : Error Test name: (anonymous namespace)::Test::test tearDown() failed - An uncaught exception of type com.sun.star.lang.DisposedException And then the test suite crashes because it can't actually deal with the previous the assertion failure, and the segfault above is not relevant at all? It crashes because libreoffice crashed, the connection is not there and therefore not alive. Yes, I can read that. As said, I was just pointing at a smoketest example. The most likely thing is that this is not a platform specific issue, but a either a general issue that just shows up on some platforms for whatever reason, or some problem in an other piece of software that libreoffice is using that does have a pratform specific issue. This specific one might be, yes. That's probably not true for the other architectures' failures. (E.g. the Bus error I mentioned earlier or the powerpcs having "Trace/breakpoint trap (core dumped)" or s390x or armel crashing in loading tiff files. And that is all only the first failure on earch archs, there's more, there's gazillions of failures in the architectures' build logs. Regards, Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi, Am 20.06.23 um 16:52 schrieb Kurt Roeckx: On Tue, Jun 20, 2023 at 05:52:44AM +0200, Rene Engelhard wrote: Hi, Am 19.06.23 um 23:29 schrieb Rene Engelhard: The pragmatic option would be to run only a smoketest for build success on architectures not tested by upstream. And have Format->Character in Impress crash with Bus error like on mipsel? That doesn't sound too good for basic quality. There is a "smoketest" but it does just basic start. open, close stuff. Not even basic usage. That said, that is the smoketest on mipsel: The problem with a mail like this is that it really doesn't help anybody in understanding the problem. As porter, it will probably take a lot of time to get to the point where you can start looking at what the problem might be. It contains lots of information, but it's not clear what the problem is and what needs to be looked at. Except by just starting to build and run into an issue (process:8700): dconf-CRITICAL **: 02:36:13.575: unable to create directory '/run/user/2952/dconf': Permission denied. dconf will not work properly. (process:8708): dconf-CRITICAL **: 02:36:19.328: unable to create directory '/run/user/2952/dconf': Permission denied. dconf will not work properly. (process:8815): dconf-CRITICAL **: 02:36:52.467: unable to create directory '/run/user/2952/dconf': Permission denied. dconf will not work properly. Is this something the porter should look at? Is is relevant? No. That also happens everywhere, also on amd64/arm64. Fatal exception: Signal 11 It's a segfault, I know :) this should normally be trivial for you to debug, but is probably complicated for a porter to find out how to do things like attaching a debugger to the relevant process. Well, the command line is there, but I see the point. Still one could talk about this... I yet have to hear from any porter talking about actual issues (and the buildlogs *are* there). Stack: /<>/instdir/program/libuno_sal.so.3(+0x49b18)[0x77d69b18] /<>/instdir/program/libuno_sal.so.3(+0x49d48)[0x77d69d48] /usr/lib/jvm/java-17-openjdk-mipsel/lib/server/libjvm.so(+0x537b8c)[0x62417b8c] Is this some openjdk problem, not a problem in libreoffice problem? In this specific case probably openjdk. I was juat answering Adrian on the smoketest. Actually I run a --disable-java build on eller right now. ./smoketest/smoketest.cxx:187:(anonymous namespace)::Test::test assertion failed - Expression: connection_.isStillAlive() So the (TCP?) connection is not alive? Why not? That doesn't seem to be platform specific. Is that a problem in the test suite, and not libreoffice itself? Because libreoffice crashed, "obviously", so there of course is no connection anymore. The point here is that it even crashes at startup so probably being completely broken. (and I am not surprised) unknown:0:(anonymous namespace)::Test::test tearDown() failed - An uncaught exception of type com.sun.star.lang.DisposedException - Binary URP bridge already disposed at ./binaryurp/source/bridge.cxx:1048 (anonymous namespace)::Test::test finished in: 76764ms smoketest.cxx:187:Assertion Test name: (anonymous namespace)::Test::test assertion failed - Expression: connection_.isStillAlive() ##Failure Location unknown## : Error Test name: (anonymous namespace)::Test::test tearDown() failed - An uncaught exception of type com.sun.star.lang.DisposedException And then the test suite crashes because it can't actually deal with the previous the assertion failure, and the segfault above is not relevant at all? It crashes because libreoffice crashed, the connection is not there and therefore not alive. Yes, I can read that. As said, I was just pointing at a smoketest example. The most likely thing is that this is not a platform specific issue, but a either a general issue that just shows up on some platforms for whatever reason, or some problem in an other piece of software that libreoffice is using that does have a pratform specific issue. This specific one might be, yes. That's probably not true for the other architectures' failures. (E.g. the Bus error I mentioned earlier or the powerpcs having "Trace/breakpoint trap (core dumped)" or s390x or armel crashing in loading tiff files. And that is all only the first failure on earch archs, there's more, there's gazillions of failures in the architectures' build logs. Regards, Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi, Am 20.06.23 um 16:52 schrieb Kurt Roeckx: On Tue, Jun 20, 2023 at 05:52:44AM +0200, Rene Engelhard wrote: Hi, Am 19.06.23 um 23:29 schrieb Rene Engelhard: The pragmatic option would be to run only a smoketest for build success on architectures not tested by upstream. And have Format->Character in Impress crash with Bus error like on mipsel? That doesn't sound too good for basic quality. There is a "smoketest" but it does just basic start. open, close stuff. Not even basic usage. That said, that is the smoketest on mipsel: The problem with a mail like this is that it really doesn't help anybody in understanding the problem. As porter, it will probably take a lot of time to get to the point where you can start looking at what the problem might be. It contains lots of information, but it's not clear what the problem is and what needs to be looked at. Except by just starting to build and run into an issue (process:8700): dconf-CRITICAL **: 02:36:13.575: unable to create directory '/run/user/2952/dconf': Permission denied. dconf will not work properly. (process:8708): dconf-CRITICAL **: 02:36:19.328: unable to create directory '/run/user/2952/dconf': Permission denied. dconf will not work properly. (process:8815): dconf-CRITICAL **: 02:36:52.467: unable to create directory '/run/user/2952/dconf': Permission denied. dconf will not work properly. Is this something the porter should look at? Is is relevant? No. That also happens everywhere, also on amd64/arm64. Fatal exception: Signal 11 It's a segfault, I know :) this should normally be trivial for you to debug, but is probably complicated for a porter to find out how to do things like attaching a debugger to the relevant process. Well, the command line is there, but I see the point. Still one could talk about this... I yet have to hear from any porter talking about actual issues (and the buildlogs *are* there). Stack: /<>/instdir/program/libuno_sal.so.3(+0x49b18)[0x77d69b18] /<>/instdir/program/libuno_sal.so.3(+0x49d48)[0x77d69d48] /usr/lib/jvm/java-17-openjdk-mipsel/lib/server/libjvm.so(+0x537b8c)[0x62417b8c] Is this some openjdk problem, not a problem in libreoffice problem? In this specific case probably openjdk. I was juat answering Adrian on the smoketest. Actually I run a --disable-java build on eller right now. ./smoketest/smoketest.cxx:187:(anonymous namespace)::Test::test assertion failed - Expression: connection_.isStillAlive() So the (TCP?) connection is not alive? Why not? That doesn't seem to be platform specific. Is that a problem in the test suite, and not libreoffice itself? Because libreoffice crashed, "obviously", so there of course is no connection anymore. The point here is that it even crashes at startup so probably being completely broken. (and I am not surprised) unknown:0:(anonymous namespace)::Test::test tearDown() failed - An uncaught exception of type com.sun.star.lang.DisposedException - Binary URP bridge already disposed at ./binaryurp/source/bridge.cxx:1048 (anonymous namespace)::Test::test finished in: 76764ms smoketest.cxx:187:Assertion Test name: (anonymous namespace)::Test::test assertion failed - Expression: connection_.isStillAlive() ##Failure Location unknown## : Error Test name: (anonymous namespace)::Test::test tearDown() failed - An uncaught exception of type com.sun.star.lang.DisposedException And then the test suite crashes because it can't actually deal with the previous the assertion failure, and the segfault above is not relevant at all? It crashes because libreoffice crashed, the connection is not there and therefore not alive. Yes, I can read that. As said, I was just pointing at a smoketest example. The most likely thing is that this is not a platform specific issue, but a either a general issue that just shows up on some platforms for whatever reason, or some problem in an other piece of software that libreoffice is using that does have a pratform specific issue. This specific one might be, yes. That's probably not true for the other architectures' failures. (E.g. the Bus error I mentioned earlier or the powerpcs having "Trace/breakpoint trap (core dumped)" or s390x or armel crashing in loading tiff files. And that is all only the first failure on earch archs, there's more, there's gazillions of failures in the architectures' build logs. Regards, Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi, Am 20.06.23 um 16:52 schrieb Kurt Roeckx: On Tue, Jun 20, 2023 at 05:52:44AM +0200, Rene Engelhard wrote: Hi, Am 19.06.23 um 23:29 schrieb Rene Engelhard: The pragmatic option would be to run only a smoketest for build success on architectures not tested by upstream. And have Format->Character in Impress crash with Bus error like on mipsel? That doesn't sound too good for basic quality. There is a "smoketest" but it does just basic start. open, close stuff. Not even basic usage. That said, that is the smoketest on mipsel: The problem with a mail like this is that it really doesn't help anybody in understanding the problem. As porter, it will probably take a lot of time to get to the point where you can start looking at what the problem might be. It contains lots of information, but it's not clear what the problem is and what needs to be looked at. Except by just starting to build and run into an issue (process:8700): dconf-CRITICAL **: 02:36:13.575: unable to create directory '/run/user/2952/dconf': Permission denied. dconf will not work properly. (process:8708): dconf-CRITICAL **: 02:36:19.328: unable to create directory '/run/user/2952/dconf': Permission denied. dconf will not work properly. (process:8815): dconf-CRITICAL **: 02:36:52.467: unable to create directory '/run/user/2952/dconf': Permission denied. dconf will not work properly. Is this something the porter should look at? Is is relevant? No. That also happens everywhere, also on amd64/arm64. Fatal exception: Signal 11 It's a segfault, I know :) this should normally be trivial for you to debug, but is probably complicated for a porter to find out how to do things like attaching a debugger to the relevant process. Well, the command line is there, but I see the point. Still one could talk about this... I yet have to hear from any porter talking about actual issues (and the buildlogs *are* there). Stack: /<>/instdir/program/libuno_sal.so.3(+0x49b18)[0x77d69b18] /<>/instdir/program/libuno_sal.so.3(+0x49d48)[0x77d69d48] /usr/lib/jvm/java-17-openjdk-mipsel/lib/server/libjvm.so(+0x537b8c)[0x62417b8c] Is this some openjdk problem, not a problem in libreoffice problem? In this specific case probably openjdk. I was juat answering Adrian on the smoketest. Actually I run a --disable-java build on eller right now. ./smoketest/smoketest.cxx:187:(anonymous namespace)::Test::test assertion failed - Expression: connection_.isStillAlive() So the (TCP?) connection is not alive? Why not? That doesn't seem to be platform specific. Is that a problem in the test suite, and not libreoffice itself? Because libreoffice crashed, "obviously", so there of course is no connection anymore. The point here is that it even crashes at startup so probably being completely broken. (and I am not surprised) unknown:0:(anonymous namespace)::Test::test tearDown() failed - An uncaught exception of type com.sun.star.lang.DisposedException - Binary URP bridge already disposed at ./binaryurp/source/bridge.cxx:1048 (anonymous namespace)::Test::test finished in: 76764ms smoketest.cxx:187:Assertion Test name: (anonymous namespace)::Test::test assertion failed - Expression: connection_.isStillAlive() ##Failure Location unknown## : Error Test name: (anonymous namespace)::Test::test tearDown() failed - An uncaught exception of type com.sun.star.lang.DisposedException And then the test suite crashes because it can't actually deal with the previous the assertion failure, and the segfault above is not relevant at all? It crashes because libreoffice crashed, the connection is not there and therefore not alive. Yes, I can read that. As said, I was just pointing at a smoketest example. The most likely thing is that this is not a platform specific issue, but a either a general issue that just shows up on some platforms for whatever reason, or some problem in an other piece of software that libreoffice is using that does have a pratform specific issue. This specific one might be, yes. That's probably not true for the other architectures' failures. (E.g. the Bus error I mentioned earlier or the powerpcs having "Trace/breakpoint trap (core dumped)" or s390x or armel crashing in loading tiff files. And that is all only the first failure on earch archs, there's more, there's gazillions of failures in the architectures' build logs. Regards, Rene
Bug#1038690: marked as pending in liborcus
Control: tag -1 pending Hello, Bug #1038690 in liborcus reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/libreoffice-team/liborcus/-/commit/ac02b408cdc74e04b936b83013778ddc26d1c2a1 Update tests/control: 0.17->0.18 (closes: #1038690) (this message was generated automatically) -- Greetings https://bugs.debian.org/1038690
Re: unbreaking LibreOffices tests on at least release architectures
Hi,
Am 19.06.23 um 23:29 schrieb Rene Engelhard:
The pragmatic option would be to run only a smoketest for build success
on architectures not tested by upstream.
And have Format->Character in Impress crash with Bus error like on
mipsel? That doesn't sound too good for basic quality.
There is a "smoketest" but it does just basic start. open, close stuff.
Not even basic usage.
That said, that is the smoketest on mipsel:
[build CUT] smoketest
S=/<> && I=$S/instdir && W=$S/workdir && mkdir -p
$W/CppunitTest/ && rm -fr $W/CppunitTest/smoketest.test.user && cp -r
$W/unittest $W/CppunitTest/smoketest.test.user &&rm -fr
$W/CppunitTest/smoketest.test.core && mkdir
$W/CppunitTest/smoketest.test.core && cd
$W/CppunitTest/smoketest.test.core && ( MAX_CONCURRENCY=4
MOZILLA_CERTIFICATE_FOLDER=dbm:
SAL_DISABLE_SYNCHRONOUS_PRINTER_DETECTION=1 SAL_USE_VCLPLUGIN=svp
LIBO_LANG=C
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"$I/program:$I/program":$W/UnpackedTarball/cppunit/src/cppunit/.libs
$W/LinkTarget/Executable/cppunittester
$W/LinkTarget/CppunitTest/libtest_smoketest.so --headless
"-env:BRAND_BASE_DIR=file://$S/instdir" "-env:BRAND_SHARE_SUBDIR=share"
"-env:BRAND_SHARE_RESOURCE_SUBDIR=program/resource"
"-env:UserInstallation=file://$W/CppunitTest/smoketest.test.user"
"-env:UNO_TYPES=file://$I/program/types.rdb
file://$I/program/types/offapi.rdb"
"-env:UNO_SERVICES=file://$W/Rdb/ure/services.rdb"
-env:URE_BIN_DIR=file://$I/program
-env:URE_INTERNAL_LIB_DIR=file://$I/program
-env:LO_LIB_DIR=file://$I/program
-env:LO_JAVA_DIR=file://$I/program/classes --protector
$W/LinkTarget/Library/unoexceptionprotector.so unoexceptionprotector
--protector $W/LinkTarget/Library/unobootstrapprotector.so
unobootstrapprotector -env:arg-soffice=path:$I/program/soffice
-env:arg-user=$W/CustomTarget/smoketest
-env:arg-env=LD_LIBRARY_PATH"${LD_LIBRARY_PATH+=$LD_LIBRARY_PATH}"
-env:arg-testarg.smoketest.doc=$W/Zip/smoketestdoc.sxw
"-env:CPPUNITTESTTARGET=$W/CppunitTest/smoketest.test" ) 2>&1
[_RUN_] (anonymous namespace)::Test::test
(process:8700): dconf-CRITICAL **: 02:36:13.575: unable to create
directory '/run/user/2952/dconf': Permission denied. dconf will not
work properly.
(process:8708): dconf-CRITICAL **: 02:36:19.328: unable to create
directory '/run/user/2952/dconf': Permission denied. dconf will not
work properly.
(process:8815): dconf-CRITICAL **: 02:36:52.467: unable to create
directory '/run/user/2952/dconf': Permission denied. dconf will not
work properly.
Fatal exception: Signal 11
Stack:
/<>/instdir/program/libuno_sal.so.3(+0x49b18)[0x77d69b18]
/<>/instdir/program/libuno_sal.so.3(+0x49d48)[0x77d69d48]
/usr/lib/jvm/java-17-openjdk-mipsel/lib/server/libjvm.so(+0x537b8c)[0x62417b8c]
./smoketest/smoketest.cxx:187:(anonymous namespace)::Test::test
assertion failed
- Expression: connection_.isStillAlive()
unknown:0:(anonymous namespace)::Test::test
tearDown() failed
- An uncaught exception of type com.sun.star.lang.DisposedException
- Binary URP bridge already disposed at ./binaryurp/source/bridge.cxx:1048
(anonymous namespace)::Test::test finished in: 76764ms
smoketest.cxx:187:Assertion
Test name: (anonymous namespace)::Test::test
assertion failed
- Expression: connection_.isStillAlive()
##Failure Location unknown## : Error
Test name: (anonymous namespace)::Test::test
tearDown() failed
- An uncaught exception of type com.sun.star.lang.DisposedException
- Binary URP bridge already disposed at ./binaryurp/source/bridge.cxx:1048
Failures !!!
Run: 1 Failure total: 2 Failures: 1 Errors: 1
make[3]: *** [/<>/solenv/gbuild/CppunitTest.mk:121:
/<>/workdir/CppunitTest/smoketest.test] Error 1
Regards,
Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi,
Am 19.06.23 um 23:29 schrieb Rene Engelhard:
The pragmatic option would be to run only a smoketest for build success
on architectures not tested by upstream.
And have Format->Character in Impress crash with Bus error like on
mipsel? That doesn't sound too good for basic quality.
There is a "smoketest" but it does just basic start. open, close stuff.
Not even basic usage.
That said, that is the smoketest on mipsel:
[build CUT] smoketest
S=/<> && I=$S/instdir && W=$S/workdir && mkdir -p
$W/CppunitTest/ && rm -fr $W/CppunitTest/smoketest.test.user && cp -r
$W/unittest $W/CppunitTest/smoketest.test.user &&rm -fr
$W/CppunitTest/smoketest.test.core && mkdir
$W/CppunitTest/smoketest.test.core && cd
$W/CppunitTest/smoketest.test.core && ( MAX_CONCURRENCY=4
MOZILLA_CERTIFICATE_FOLDER=dbm:
SAL_DISABLE_SYNCHRONOUS_PRINTER_DETECTION=1 SAL_USE_VCLPLUGIN=svp
LIBO_LANG=C
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"$I/program:$I/program":$W/UnpackedTarball/cppunit/src/cppunit/.libs
$W/LinkTarget/Executable/cppunittester
$W/LinkTarget/CppunitTest/libtest_smoketest.so --headless
"-env:BRAND_BASE_DIR=file://$S/instdir" "-env:BRAND_SHARE_SUBDIR=share"
"-env:BRAND_SHARE_RESOURCE_SUBDIR=program/resource"
"-env:UserInstallation=file://$W/CppunitTest/smoketest.test.user"
"-env:UNO_TYPES=file://$I/program/types.rdb
file://$I/program/types/offapi.rdb"
"-env:UNO_SERVICES=file://$W/Rdb/ure/services.rdb"
-env:URE_BIN_DIR=file://$I/program
-env:URE_INTERNAL_LIB_DIR=file://$I/program
-env:LO_LIB_DIR=file://$I/program
-env:LO_JAVA_DIR=file://$I/program/classes --protector
$W/LinkTarget/Library/unoexceptionprotector.so unoexceptionprotector
--protector $W/LinkTarget/Library/unobootstrapprotector.so
unobootstrapprotector -env:arg-soffice=path:$I/program/soffice
-env:arg-user=$W/CustomTarget/smoketest
-env:arg-env=LD_LIBRARY_PATH"${LD_LIBRARY_PATH+=$LD_LIBRARY_PATH}"
-env:arg-testarg.smoketest.doc=$W/Zip/smoketestdoc.sxw
"-env:CPPUNITTESTTARGET=$W/CppunitTest/smoketest.test" ) 2>&1
[_RUN_] (anonymous namespace)::Test::test
(process:8700): dconf-CRITICAL **: 02:36:13.575: unable to create
directory '/run/user/2952/dconf': Permission denied. dconf will not
work properly.
(process:8708): dconf-CRITICAL **: 02:36:19.328: unable to create
directory '/run/user/2952/dconf': Permission denied. dconf will not
work properly.
(process:8815): dconf-CRITICAL **: 02:36:52.467: unable to create
directory '/run/user/2952/dconf': Permission denied. dconf will not
work properly.
Fatal exception: Signal 11
Stack:
/<>/instdir/program/libuno_sal.so.3(+0x49b18)[0x77d69b18]
/<>/instdir/program/libuno_sal.so.3(+0x49d48)[0x77d69d48]
/usr/lib/jvm/java-17-openjdk-mipsel/lib/server/libjvm.so(+0x537b8c)[0x62417b8c]
./smoketest/smoketest.cxx:187:(anonymous namespace)::Test::test
assertion failed
- Expression: connection_.isStillAlive()
unknown:0:(anonymous namespace)::Test::test
tearDown() failed
- An uncaught exception of type com.sun.star.lang.DisposedException
- Binary URP bridge already disposed at ./binaryurp/source/bridge.cxx:1048
(anonymous namespace)::Test::test finished in: 76764ms
smoketest.cxx:187:Assertion
Test name: (anonymous namespace)::Test::test
assertion failed
- Expression: connection_.isStillAlive()
##Failure Location unknown## : Error
Test name: (anonymous namespace)::Test::test
tearDown() failed
- An uncaught exception of type com.sun.star.lang.DisposedException
- Binary URP bridge already disposed at ./binaryurp/source/bridge.cxx:1048
Failures !!!
Run: 1 Failure total: 2 Failures: 1 Errors: 1
make[3]: *** [/<>/solenv/gbuild/CppunitTest.mk:121:
/<>/workdir/CppunitTest/smoketest.test] Error 1
Regards,
Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi,
Am 19.06.23 um 23:29 schrieb Rene Engelhard:
The pragmatic option would be to run only a smoketest for build success
on architectures not tested by upstream.
And have Format->Character in Impress crash with Bus error like on
mipsel? That doesn't sound too good for basic quality.
There is a "smoketest" but it does just basic start. open, close stuff.
Not even basic usage.
That said, that is the smoketest on mipsel:
[build CUT] smoketest
S=/<> && I=$S/instdir && W=$S/workdir && mkdir -p
$W/CppunitTest/ && rm -fr $W/CppunitTest/smoketest.test.user && cp -r
$W/unittest $W/CppunitTest/smoketest.test.user &&rm -fr
$W/CppunitTest/smoketest.test.core && mkdir
$W/CppunitTest/smoketest.test.core && cd
$W/CppunitTest/smoketest.test.core && ( MAX_CONCURRENCY=4
MOZILLA_CERTIFICATE_FOLDER=dbm:
SAL_DISABLE_SYNCHRONOUS_PRINTER_DETECTION=1 SAL_USE_VCLPLUGIN=svp
LIBO_LANG=C
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"$I/program:$I/program":$W/UnpackedTarball/cppunit/src/cppunit/.libs
$W/LinkTarget/Executable/cppunittester
$W/LinkTarget/CppunitTest/libtest_smoketest.so --headless
"-env:BRAND_BASE_DIR=file://$S/instdir" "-env:BRAND_SHARE_SUBDIR=share"
"-env:BRAND_SHARE_RESOURCE_SUBDIR=program/resource"
"-env:UserInstallation=file://$W/CppunitTest/smoketest.test.user"
"-env:UNO_TYPES=file://$I/program/types.rdb
file://$I/program/types/offapi.rdb"
"-env:UNO_SERVICES=file://$W/Rdb/ure/services.rdb"
-env:URE_BIN_DIR=file://$I/program
-env:URE_INTERNAL_LIB_DIR=file://$I/program
-env:LO_LIB_DIR=file://$I/program
-env:LO_JAVA_DIR=file://$I/program/classes --protector
$W/LinkTarget/Library/unoexceptionprotector.so unoexceptionprotector
--protector $W/LinkTarget/Library/unobootstrapprotector.so
unobootstrapprotector -env:arg-soffice=path:$I/program/soffice
-env:arg-user=$W/CustomTarget/smoketest
-env:arg-env=LD_LIBRARY_PATH"${LD_LIBRARY_PATH+=$LD_LIBRARY_PATH}"
-env:arg-testarg.smoketest.doc=$W/Zip/smoketestdoc.sxw
"-env:CPPUNITTESTTARGET=$W/CppunitTest/smoketest.test" ) 2>&1
[_RUN_] (anonymous namespace)::Test::test
(process:8700): dconf-CRITICAL **: 02:36:13.575: unable to create
directory '/run/user/2952/dconf': Permission denied. dconf will not
work properly.
(process:8708): dconf-CRITICAL **: 02:36:19.328: unable to create
directory '/run/user/2952/dconf': Permission denied. dconf will not
work properly.
(process:8815): dconf-CRITICAL **: 02:36:52.467: unable to create
directory '/run/user/2952/dconf': Permission denied. dconf will not
work properly.
Fatal exception: Signal 11
Stack:
/<>/instdir/program/libuno_sal.so.3(+0x49b18)[0x77d69b18]
/<>/instdir/program/libuno_sal.so.3(+0x49d48)[0x77d69d48]
/usr/lib/jvm/java-17-openjdk-mipsel/lib/server/libjvm.so(+0x537b8c)[0x62417b8c]
./smoketest/smoketest.cxx:187:(anonymous namespace)::Test::test
assertion failed
- Expression: connection_.isStillAlive()
unknown:0:(anonymous namespace)::Test::test
tearDown() failed
- An uncaught exception of type com.sun.star.lang.DisposedException
- Binary URP bridge already disposed at ./binaryurp/source/bridge.cxx:1048
(anonymous namespace)::Test::test finished in: 76764ms
smoketest.cxx:187:Assertion
Test name: (anonymous namespace)::Test::test
assertion failed
- Expression: connection_.isStillAlive()
##Failure Location unknown## : Error
Test name: (anonymous namespace)::Test::test
tearDown() failed
- An uncaught exception of type com.sun.star.lang.DisposedException
- Binary URP bridge already disposed at ./binaryurp/source/bridge.cxx:1048
Failures !!!
Run: 1 Failure total: 2 Failures: 1 Errors: 1
make[3]: *** [/<>/solenv/gbuild/CppunitTest.mk:121:
/<>/workdir/CppunitTest/smoketest.test] Error 1
Regards,
Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi,
Am 19.06.23 um 23:29 schrieb Rene Engelhard:
The pragmatic option would be to run only a smoketest for build success
on architectures not tested by upstream.
And have Format->Character in Impress crash with Bus error like on
mipsel? That doesn't sound too good for basic quality.
There is a "smoketest" but it does just basic start. open, close stuff.
Not even basic usage.
That said, that is the smoketest on mipsel:
[build CUT] smoketest
S=/<> && I=$S/instdir && W=$S/workdir && mkdir -p
$W/CppunitTest/ && rm -fr $W/CppunitTest/smoketest.test.user && cp -r
$W/unittest $W/CppunitTest/smoketest.test.user &&rm -fr
$W/CppunitTest/smoketest.test.core && mkdir
$W/CppunitTest/smoketest.test.core && cd
$W/CppunitTest/smoketest.test.core && ( MAX_CONCURRENCY=4
MOZILLA_CERTIFICATE_FOLDER=dbm:
SAL_DISABLE_SYNCHRONOUS_PRINTER_DETECTION=1 SAL_USE_VCLPLUGIN=svp
LIBO_LANG=C
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"$I/program:$I/program":$W/UnpackedTarball/cppunit/src/cppunit/.libs
$W/LinkTarget/Executable/cppunittester
$W/LinkTarget/CppunitTest/libtest_smoketest.so --headless
"-env:BRAND_BASE_DIR=file://$S/instdir" "-env:BRAND_SHARE_SUBDIR=share"
"-env:BRAND_SHARE_RESOURCE_SUBDIR=program/resource"
"-env:UserInstallation=file://$W/CppunitTest/smoketest.test.user"
"-env:UNO_TYPES=file://$I/program/types.rdb
file://$I/program/types/offapi.rdb"
"-env:UNO_SERVICES=file://$W/Rdb/ure/services.rdb"
-env:URE_BIN_DIR=file://$I/program
-env:URE_INTERNAL_LIB_DIR=file://$I/program
-env:LO_LIB_DIR=file://$I/program
-env:LO_JAVA_DIR=file://$I/program/classes --protector
$W/LinkTarget/Library/unoexceptionprotector.so unoexceptionprotector
--protector $W/LinkTarget/Library/unobootstrapprotector.so
unobootstrapprotector -env:arg-soffice=path:$I/program/soffice
-env:arg-user=$W/CustomTarget/smoketest
-env:arg-env=LD_LIBRARY_PATH"${LD_LIBRARY_PATH+=$LD_LIBRARY_PATH}"
-env:arg-testarg.smoketest.doc=$W/Zip/smoketestdoc.sxw
"-env:CPPUNITTESTTARGET=$W/CppunitTest/smoketest.test" ) 2>&1
[_RUN_] (anonymous namespace)::Test::test
(process:8700): dconf-CRITICAL **: 02:36:13.575: unable to create
directory '/run/user/2952/dconf': Permission denied. dconf will not
work properly.
(process:8708): dconf-CRITICAL **: 02:36:19.328: unable to create
directory '/run/user/2952/dconf': Permission denied. dconf will not
work properly.
(process:8815): dconf-CRITICAL **: 02:36:52.467: unable to create
directory '/run/user/2952/dconf': Permission denied. dconf will not
work properly.
Fatal exception: Signal 11
Stack:
/<>/instdir/program/libuno_sal.so.3(+0x49b18)[0x77d69b18]
/<>/instdir/program/libuno_sal.so.3(+0x49d48)[0x77d69d48]
/usr/lib/jvm/java-17-openjdk-mipsel/lib/server/libjvm.so(+0x537b8c)[0x62417b8c]
./smoketest/smoketest.cxx:187:(anonymous namespace)::Test::test
assertion failed
- Expression: connection_.isStillAlive()
unknown:0:(anonymous namespace)::Test::test
tearDown() failed
- An uncaught exception of type com.sun.star.lang.DisposedException
- Binary URP bridge already disposed at ./binaryurp/source/bridge.cxx:1048
(anonymous namespace)::Test::test finished in: 76764ms
smoketest.cxx:187:Assertion
Test name: (anonymous namespace)::Test::test
assertion failed
- Expression: connection_.isStillAlive()
##Failure Location unknown## : Error
Test name: (anonymous namespace)::Test::test
tearDown() failed
- An uncaught exception of type com.sun.star.lang.DisposedException
- Binary URP bridge already disposed at ./binaryurp/source/bridge.cxx:1048
Failures !!!
Run: 1 Failure total: 2 Failures: 1 Errors: 1
make[3]: *** [/<>/solenv/gbuild/CppunitTest.mk:121:
/<>/workdir/CppunitTest/smoketest.test] Error 1
Regards,
Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi,
Am 19.06.23 um 23:29 schrieb Rene Engelhard:
The pragmatic option would be to run only a smoketest for build success
on architectures not tested by upstream.
And have Format->Character in Impress crash with Bus error like on
mipsel? That doesn't sound too good for basic quality.
There is a "smoketest" but it does just basic start. open, close stuff.
Not even basic usage.
That said, that is the smoketest on mipsel:
[build CUT] smoketest
S=/<> && I=$S/instdir && W=$S/workdir && mkdir -p
$W/CppunitTest/ && rm -fr $W/CppunitTest/smoketest.test.user && cp -r
$W/unittest $W/CppunitTest/smoketest.test.user &&rm -fr
$W/CppunitTest/smoketest.test.core && mkdir
$W/CppunitTest/smoketest.test.core && cd
$W/CppunitTest/smoketest.test.core && ( MAX_CONCURRENCY=4
MOZILLA_CERTIFICATE_FOLDER=dbm:
SAL_DISABLE_SYNCHRONOUS_PRINTER_DETECTION=1 SAL_USE_VCLPLUGIN=svp
LIBO_LANG=C
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"$I/program:$I/program":$W/UnpackedTarball/cppunit/src/cppunit/.libs
$W/LinkTarget/Executable/cppunittester
$W/LinkTarget/CppunitTest/libtest_smoketest.so --headless
"-env:BRAND_BASE_DIR=file://$S/instdir" "-env:BRAND_SHARE_SUBDIR=share"
"-env:BRAND_SHARE_RESOURCE_SUBDIR=program/resource"
"-env:UserInstallation=file://$W/CppunitTest/smoketest.test.user"
"-env:UNO_TYPES=file://$I/program/types.rdb
file://$I/program/types/offapi.rdb"
"-env:UNO_SERVICES=file://$W/Rdb/ure/services.rdb"
-env:URE_BIN_DIR=file://$I/program
-env:URE_INTERNAL_LIB_DIR=file://$I/program
-env:LO_LIB_DIR=file://$I/program
-env:LO_JAVA_DIR=file://$I/program/classes --protector
$W/LinkTarget/Library/unoexceptionprotector.so unoexceptionprotector
--protector $W/LinkTarget/Library/unobootstrapprotector.so
unobootstrapprotector -env:arg-soffice=path:$I/program/soffice
-env:arg-user=$W/CustomTarget/smoketest
-env:arg-env=LD_LIBRARY_PATH"${LD_LIBRARY_PATH+=$LD_LIBRARY_PATH}"
-env:arg-testarg.smoketest.doc=$W/Zip/smoketestdoc.sxw
"-env:CPPUNITTESTTARGET=$W/CppunitTest/smoketest.test" ) 2>&1
[_RUN_] (anonymous namespace)::Test::test
(process:8700): dconf-CRITICAL **: 02:36:13.575: unable to create
directory '/run/user/2952/dconf': Permission denied. dconf will not
work properly.
(process:8708): dconf-CRITICAL **: 02:36:19.328: unable to create
directory '/run/user/2952/dconf': Permission denied. dconf will not
work properly.
(process:8815): dconf-CRITICAL **: 02:36:52.467: unable to create
directory '/run/user/2952/dconf': Permission denied. dconf will not
work properly.
Fatal exception: Signal 11
Stack:
/<>/instdir/program/libuno_sal.so.3(+0x49b18)[0x77d69b18]
/<>/instdir/program/libuno_sal.so.3(+0x49d48)[0x77d69d48]
/usr/lib/jvm/java-17-openjdk-mipsel/lib/server/libjvm.so(+0x537b8c)[0x62417b8c]
./smoketest/smoketest.cxx:187:(anonymous namespace)::Test::test
assertion failed
- Expression: connection_.isStillAlive()
unknown:0:(anonymous namespace)::Test::test
tearDown() failed
- An uncaught exception of type com.sun.star.lang.DisposedException
- Binary URP bridge already disposed at ./binaryurp/source/bridge.cxx:1048
(anonymous namespace)::Test::test finished in: 76764ms
smoketest.cxx:187:Assertion
Test name: (anonymous namespace)::Test::test
assertion failed
- Expression: connection_.isStillAlive()
##Failure Location unknown## : Error
Test name: (anonymous namespace)::Test::test
tearDown() failed
- An uncaught exception of type com.sun.star.lang.DisposedException
- Binary URP bridge already disposed at ./binaryurp/source/bridge.cxx:1048
Failures !!!
Run: 1 Failure total: 2 Failures: 1 Errors: 1
make[3]: *** [/<>/solenv/gbuild/CppunitTest.mk:121:
/<>/workdir/CppunitTest/smoketest.test] Error 1
Regards,
Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi,
Am 19.06.23 um 23:29 schrieb Rene Engelhard:
The pragmatic option would be to run only a smoketest for build success
on architectures not tested by upstream.
And have Format->Character in Impress crash with Bus error like on
mipsel? That doesn't sound too good for basic quality.
There is a "smoketest" but it does just basic start. open, close stuff.
Not even basic usage.
That said, that is the smoketest on mipsel:
[build CUT] smoketest
S=/<> && I=$S/instdir && W=$S/workdir && mkdir -p
$W/CppunitTest/ && rm -fr $W/CppunitTest/smoketest.test.user && cp -r
$W/unittest $W/CppunitTest/smoketest.test.user &&rm -fr
$W/CppunitTest/smoketest.test.core && mkdir
$W/CppunitTest/smoketest.test.core && cd
$W/CppunitTest/smoketest.test.core && ( MAX_CONCURRENCY=4
MOZILLA_CERTIFICATE_FOLDER=dbm:
SAL_DISABLE_SYNCHRONOUS_PRINTER_DETECTION=1 SAL_USE_VCLPLUGIN=svp
LIBO_LANG=C
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"$I/program:$I/program":$W/UnpackedTarball/cppunit/src/cppunit/.libs
$W/LinkTarget/Executable/cppunittester
$W/LinkTarget/CppunitTest/libtest_smoketest.so --headless
"-env:BRAND_BASE_DIR=file://$S/instdir" "-env:BRAND_SHARE_SUBDIR=share"
"-env:BRAND_SHARE_RESOURCE_SUBDIR=program/resource"
"-env:UserInstallation=file://$W/CppunitTest/smoketest.test.user"
"-env:UNO_TYPES=file://$I/program/types.rdb
file://$I/program/types/offapi.rdb"
"-env:UNO_SERVICES=file://$W/Rdb/ure/services.rdb"
-env:URE_BIN_DIR=file://$I/program
-env:URE_INTERNAL_LIB_DIR=file://$I/program
-env:LO_LIB_DIR=file://$I/program
-env:LO_JAVA_DIR=file://$I/program/classes --protector
$W/LinkTarget/Library/unoexceptionprotector.so unoexceptionprotector
--protector $W/LinkTarget/Library/unobootstrapprotector.so
unobootstrapprotector -env:arg-soffice=path:$I/program/soffice
-env:arg-user=$W/CustomTarget/smoketest
-env:arg-env=LD_LIBRARY_PATH"${LD_LIBRARY_PATH+=$LD_LIBRARY_PATH}"
-env:arg-testarg.smoketest.doc=$W/Zip/smoketestdoc.sxw
"-env:CPPUNITTESTTARGET=$W/CppunitTest/smoketest.test" ) 2>&1
[_RUN_] (anonymous namespace)::Test::test
(process:8700): dconf-CRITICAL **: 02:36:13.575: unable to create
directory '/run/user/2952/dconf': Permission denied. dconf will not
work properly.
(process:8708): dconf-CRITICAL **: 02:36:19.328: unable to create
directory '/run/user/2952/dconf': Permission denied. dconf will not
work properly.
(process:8815): dconf-CRITICAL **: 02:36:52.467: unable to create
directory '/run/user/2952/dconf': Permission denied. dconf will not
work properly.
Fatal exception: Signal 11
Stack:
/<>/instdir/program/libuno_sal.so.3(+0x49b18)[0x77d69b18]
/<>/instdir/program/libuno_sal.so.3(+0x49d48)[0x77d69d48]
/usr/lib/jvm/java-17-openjdk-mipsel/lib/server/libjvm.so(+0x537b8c)[0x62417b8c]
./smoketest/smoketest.cxx:187:(anonymous namespace)::Test::test
assertion failed
- Expression: connection_.isStillAlive()
unknown:0:(anonymous namespace)::Test::test
tearDown() failed
- An uncaught exception of type com.sun.star.lang.DisposedException
- Binary URP bridge already disposed at ./binaryurp/source/bridge.cxx:1048
(anonymous namespace)::Test::test finished in: 76764ms
smoketest.cxx:187:Assertion
Test name: (anonymous namespace)::Test::test
assertion failed
- Expression: connection_.isStillAlive()
##Failure Location unknown## : Error
Test name: (anonymous namespace)::Test::test
tearDown() failed
- An uncaught exception of type com.sun.star.lang.DisposedException
- Binary URP bridge already disposed at ./binaryurp/source/bridge.cxx:1048
Failures !!!
Run: 1 Failure total: 2 Failures: 1 Errors: 1
make[3]: *** [/<>/solenv/gbuild/CppunitTest.mk:121:
/<>/workdir/CppunitTest/smoketest.test] Error 1
Regards,
Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi,
Am 19.06.23 um 23:29 schrieb Rene Engelhard:
The pragmatic option would be to run only a smoketest for build success
on architectures not tested by upstream.
And have Format->Character in Impress crash with Bus error like on
mipsel? That doesn't sound too good for basic quality.
There is a "smoketest" but it does just basic start. open, close stuff.
Not even basic usage.
That said, that is the smoketest on mipsel:
[build CUT] smoketest
S=/<> && I=$S/instdir && W=$S/workdir && mkdir -p
$W/CppunitTest/ && rm -fr $W/CppunitTest/smoketest.test.user && cp -r
$W/unittest $W/CppunitTest/smoketest.test.user &&rm -fr
$W/CppunitTest/smoketest.test.core && mkdir
$W/CppunitTest/smoketest.test.core && cd
$W/CppunitTest/smoketest.test.core && ( MAX_CONCURRENCY=4
MOZILLA_CERTIFICATE_FOLDER=dbm:
SAL_DISABLE_SYNCHRONOUS_PRINTER_DETECTION=1 SAL_USE_VCLPLUGIN=svp
LIBO_LANG=C
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"$I/program:$I/program":$W/UnpackedTarball/cppunit/src/cppunit/.libs
$W/LinkTarget/Executable/cppunittester
$W/LinkTarget/CppunitTest/libtest_smoketest.so --headless
"-env:BRAND_BASE_DIR=file://$S/instdir" "-env:BRAND_SHARE_SUBDIR=share"
"-env:BRAND_SHARE_RESOURCE_SUBDIR=program/resource"
"-env:UserInstallation=file://$W/CppunitTest/smoketest.test.user"
"-env:UNO_TYPES=file://$I/program/types.rdb
file://$I/program/types/offapi.rdb"
"-env:UNO_SERVICES=file://$W/Rdb/ure/services.rdb"
-env:URE_BIN_DIR=file://$I/program
-env:URE_INTERNAL_LIB_DIR=file://$I/program
-env:LO_LIB_DIR=file://$I/program
-env:LO_JAVA_DIR=file://$I/program/classes --protector
$W/LinkTarget/Library/unoexceptionprotector.so unoexceptionprotector
--protector $W/LinkTarget/Library/unobootstrapprotector.so
unobootstrapprotector -env:arg-soffice=path:$I/program/soffice
-env:arg-user=$W/CustomTarget/smoketest
-env:arg-env=LD_LIBRARY_PATH"${LD_LIBRARY_PATH+=$LD_LIBRARY_PATH}"
-env:arg-testarg.smoketest.doc=$W/Zip/smoketestdoc.sxw
"-env:CPPUNITTESTTARGET=$W/CppunitTest/smoketest.test" ) 2>&1
[_RUN_] (anonymous namespace)::Test::test
(process:8700): dconf-CRITICAL **: 02:36:13.575: unable to create
directory '/run/user/2952/dconf': Permission denied. dconf will not
work properly.
(process:8708): dconf-CRITICAL **: 02:36:19.328: unable to create
directory '/run/user/2952/dconf': Permission denied. dconf will not
work properly.
(process:8815): dconf-CRITICAL **: 02:36:52.467: unable to create
directory '/run/user/2952/dconf': Permission denied. dconf will not
work properly.
Fatal exception: Signal 11
Stack:
/<>/instdir/program/libuno_sal.so.3(+0x49b18)[0x77d69b18]
/<>/instdir/program/libuno_sal.so.3(+0x49d48)[0x77d69d48]
/usr/lib/jvm/java-17-openjdk-mipsel/lib/server/libjvm.so(+0x537b8c)[0x62417b8c]
./smoketest/smoketest.cxx:187:(anonymous namespace)::Test::test
assertion failed
- Expression: connection_.isStillAlive()
unknown:0:(anonymous namespace)::Test::test
tearDown() failed
- An uncaught exception of type com.sun.star.lang.DisposedException
- Binary URP bridge already disposed at ./binaryurp/source/bridge.cxx:1048
(anonymous namespace)::Test::test finished in: 76764ms
smoketest.cxx:187:Assertion
Test name: (anonymous namespace)::Test::test
assertion failed
- Expression: connection_.isStillAlive()
##Failure Location unknown## : Error
Test name: (anonymous namespace)::Test::test
tearDown() failed
- An uncaught exception of type com.sun.star.lang.DisposedException
- Binary URP bridge already disposed at ./binaryurp/source/bridge.cxx:1048
Failures !!!
Run: 1 Failure total: 2 Failures: 1 Errors: 1
make[3]: *** [/<>/solenv/gbuild/CppunitTest.mk:121:
/<>/workdir/CppunitTest/smoketest.test] Error 1
Regards,
Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi,
Am 19.06.23 um 23:29 schrieb Rene Engelhard:
The pragmatic option would be to run only a smoketest for build success
on architectures not tested by upstream.
And have Format->Character in Impress crash with Bus error like on
mipsel? That doesn't sound too good for basic quality.
There is a "smoketest" but it does just basic start. open, close stuff.
Not even basic usage.
That said, that is the smoketest on mipsel:
[build CUT] smoketest
S=/<> && I=$S/instdir && W=$S/workdir && mkdir -p
$W/CppunitTest/ && rm -fr $W/CppunitTest/smoketest.test.user && cp -r
$W/unittest $W/CppunitTest/smoketest.test.user &&rm -fr
$W/CppunitTest/smoketest.test.core && mkdir
$W/CppunitTest/smoketest.test.core && cd
$W/CppunitTest/smoketest.test.core && ( MAX_CONCURRENCY=4
MOZILLA_CERTIFICATE_FOLDER=dbm:
SAL_DISABLE_SYNCHRONOUS_PRINTER_DETECTION=1 SAL_USE_VCLPLUGIN=svp
LIBO_LANG=C
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"$I/program:$I/program":$W/UnpackedTarball/cppunit/src/cppunit/.libs
$W/LinkTarget/Executable/cppunittester
$W/LinkTarget/CppunitTest/libtest_smoketest.so --headless
"-env:BRAND_BASE_DIR=file://$S/instdir" "-env:BRAND_SHARE_SUBDIR=share"
"-env:BRAND_SHARE_RESOURCE_SUBDIR=program/resource"
"-env:UserInstallation=file://$W/CppunitTest/smoketest.test.user"
"-env:UNO_TYPES=file://$I/program/types.rdb
file://$I/program/types/offapi.rdb"
"-env:UNO_SERVICES=file://$W/Rdb/ure/services.rdb"
-env:URE_BIN_DIR=file://$I/program
-env:URE_INTERNAL_LIB_DIR=file://$I/program
-env:LO_LIB_DIR=file://$I/program
-env:LO_JAVA_DIR=file://$I/program/classes --protector
$W/LinkTarget/Library/unoexceptionprotector.so unoexceptionprotector
--protector $W/LinkTarget/Library/unobootstrapprotector.so
unobootstrapprotector -env:arg-soffice=path:$I/program/soffice
-env:arg-user=$W/CustomTarget/smoketest
-env:arg-env=LD_LIBRARY_PATH"${LD_LIBRARY_PATH+=$LD_LIBRARY_PATH}"
-env:arg-testarg.smoketest.doc=$W/Zip/smoketestdoc.sxw
"-env:CPPUNITTESTTARGET=$W/CppunitTest/smoketest.test" ) 2>&1
[_RUN_] (anonymous namespace)::Test::test
(process:8700): dconf-CRITICAL **: 02:36:13.575: unable to create
directory '/run/user/2952/dconf': Permission denied. dconf will not
work properly.
(process:8708): dconf-CRITICAL **: 02:36:19.328: unable to create
directory '/run/user/2952/dconf': Permission denied. dconf will not
work properly.
(process:8815): dconf-CRITICAL **: 02:36:52.467: unable to create
directory '/run/user/2952/dconf': Permission denied. dconf will not
work properly.
Fatal exception: Signal 11
Stack:
/<>/instdir/program/libuno_sal.so.3(+0x49b18)[0x77d69b18]
/<>/instdir/program/libuno_sal.so.3(+0x49d48)[0x77d69d48]
/usr/lib/jvm/java-17-openjdk-mipsel/lib/server/libjvm.so(+0x537b8c)[0x62417b8c]
./smoketest/smoketest.cxx:187:(anonymous namespace)::Test::test
assertion failed
- Expression: connection_.isStillAlive()
unknown:0:(anonymous namespace)::Test::test
tearDown() failed
- An uncaught exception of type com.sun.star.lang.DisposedException
- Binary URP bridge already disposed at ./binaryurp/source/bridge.cxx:1048
(anonymous namespace)::Test::test finished in: 76764ms
smoketest.cxx:187:Assertion
Test name: (anonymous namespace)::Test::test
assertion failed
- Expression: connection_.isStillAlive()
##Failure Location unknown## : Error
Test name: (anonymous namespace)::Test::test
tearDown() failed
- An uncaught exception of type com.sun.star.lang.DisposedException
- Binary URP bridge already disposed at ./binaryurp/source/bridge.cxx:1048
Failures !!!
Run: 1 Failure total: 2 Failures: 1 Errors: 1
make[3]: *** [/<>/solenv/gbuild/CppunitTest.mk:121:
/<>/workdir/CppunitTest/smoketest.test] Error 1
Regards,
Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi,
Am 19.06.23 um 23:29 schrieb Rene Engelhard:
The pragmatic option would be to run only a smoketest for build success
on architectures not tested by upstream.
And have Format->Character in Impress crash with Bus error like on
mipsel? That doesn't sound too good for basic quality.
There is a "smoketest" but it does just basic start. open, close stuff.
Not even basic usage.
That said, that is the smoketest on mipsel:
[build CUT] smoketest
S=/<> && I=$S/instdir && W=$S/workdir && mkdir -p
$W/CppunitTest/ && rm -fr $W/CppunitTest/smoketest.test.user && cp -r
$W/unittest $W/CppunitTest/smoketest.test.user &&rm -fr
$W/CppunitTest/smoketest.test.core && mkdir
$W/CppunitTest/smoketest.test.core && cd
$W/CppunitTest/smoketest.test.core && ( MAX_CONCURRENCY=4
MOZILLA_CERTIFICATE_FOLDER=dbm:
SAL_DISABLE_SYNCHRONOUS_PRINTER_DETECTION=1 SAL_USE_VCLPLUGIN=svp
LIBO_LANG=C
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"$I/program:$I/program":$W/UnpackedTarball/cppunit/src/cppunit/.libs
$W/LinkTarget/Executable/cppunittester
$W/LinkTarget/CppunitTest/libtest_smoketest.so --headless
"-env:BRAND_BASE_DIR=file://$S/instdir" "-env:BRAND_SHARE_SUBDIR=share"
"-env:BRAND_SHARE_RESOURCE_SUBDIR=program/resource"
"-env:UserInstallation=file://$W/CppunitTest/smoketest.test.user"
"-env:UNO_TYPES=file://$I/program/types.rdb
file://$I/program/types/offapi.rdb"
"-env:UNO_SERVICES=file://$W/Rdb/ure/services.rdb"
-env:URE_BIN_DIR=file://$I/program
-env:URE_INTERNAL_LIB_DIR=file://$I/program
-env:LO_LIB_DIR=file://$I/program
-env:LO_JAVA_DIR=file://$I/program/classes --protector
$W/LinkTarget/Library/unoexceptionprotector.so unoexceptionprotector
--protector $W/LinkTarget/Library/unobootstrapprotector.so
unobootstrapprotector -env:arg-soffice=path:$I/program/soffice
-env:arg-user=$W/CustomTarget/smoketest
-env:arg-env=LD_LIBRARY_PATH"${LD_LIBRARY_PATH+=$LD_LIBRARY_PATH}"
-env:arg-testarg.smoketest.doc=$W/Zip/smoketestdoc.sxw
"-env:CPPUNITTESTTARGET=$W/CppunitTest/smoketest.test" ) 2>&1
[_RUN_] (anonymous namespace)::Test::test
(process:8700): dconf-CRITICAL **: 02:36:13.575: unable to create
directory '/run/user/2952/dconf': Permission denied. dconf will not
work properly.
(process:8708): dconf-CRITICAL **: 02:36:19.328: unable to create
directory '/run/user/2952/dconf': Permission denied. dconf will not
work properly.
(process:8815): dconf-CRITICAL **: 02:36:52.467: unable to create
directory '/run/user/2952/dconf': Permission denied. dconf will not
work properly.
Fatal exception: Signal 11
Stack:
/<>/instdir/program/libuno_sal.so.3(+0x49b18)[0x77d69b18]
/<>/instdir/program/libuno_sal.so.3(+0x49d48)[0x77d69d48]
/usr/lib/jvm/java-17-openjdk-mipsel/lib/server/libjvm.so(+0x537b8c)[0x62417b8c]
./smoketest/smoketest.cxx:187:(anonymous namespace)::Test::test
assertion failed
- Expression: connection_.isStillAlive()
unknown:0:(anonymous namespace)::Test::test
tearDown() failed
- An uncaught exception of type com.sun.star.lang.DisposedException
- Binary URP bridge already disposed at ./binaryurp/source/bridge.cxx:1048
(anonymous namespace)::Test::test finished in: 76764ms
smoketest.cxx:187:Assertion
Test name: (anonymous namespace)::Test::test
assertion failed
- Expression: connection_.isStillAlive()
##Failure Location unknown## : Error
Test name: (anonymous namespace)::Test::test
tearDown() failed
- An uncaught exception of type com.sun.star.lang.DisposedException
- Binary URP bridge already disposed at ./binaryurp/source/bridge.cxx:1048
Failures !!!
Run: 1 Failure total: 2 Failures: 1 Errors: 1
make[3]: *** [/<>/solenv/gbuild/CppunitTest.mk:121:
/<>/workdir/CppunitTest/smoketest.test] Error 1
Regards,
Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi,
Am 19.06.23 um 23:29 schrieb Rene Engelhard:
The pragmatic option would be to run only a smoketest for build success
on architectures not tested by upstream.
And have Format->Character in Impress crash with Bus error like on
mipsel? That doesn't sound too good for basic quality.
There is a "smoketest" but it does just basic start. open, close stuff.
Not even basic usage.
That said, that is the smoketest on mipsel:
[build CUT] smoketest
S=/<> && I=$S/instdir && W=$S/workdir && mkdir -p
$W/CppunitTest/ && rm -fr $W/CppunitTest/smoketest.test.user && cp -r
$W/unittest $W/CppunitTest/smoketest.test.user &&rm -fr
$W/CppunitTest/smoketest.test.core && mkdir
$W/CppunitTest/smoketest.test.core && cd
$W/CppunitTest/smoketest.test.core && ( MAX_CONCURRENCY=4
MOZILLA_CERTIFICATE_FOLDER=dbm:
SAL_DISABLE_SYNCHRONOUS_PRINTER_DETECTION=1 SAL_USE_VCLPLUGIN=svp
LIBO_LANG=C
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"$I/program:$I/program":$W/UnpackedTarball/cppunit/src/cppunit/.libs
$W/LinkTarget/Executable/cppunittester
$W/LinkTarget/CppunitTest/libtest_smoketest.so --headless
"-env:BRAND_BASE_DIR=file://$S/instdir" "-env:BRAND_SHARE_SUBDIR=share"
"-env:BRAND_SHARE_RESOURCE_SUBDIR=program/resource"
"-env:UserInstallation=file://$W/CppunitTest/smoketest.test.user"
"-env:UNO_TYPES=file://$I/program/types.rdb
file://$I/program/types/offapi.rdb"
"-env:UNO_SERVICES=file://$W/Rdb/ure/services.rdb"
-env:URE_BIN_DIR=file://$I/program
-env:URE_INTERNAL_LIB_DIR=file://$I/program
-env:LO_LIB_DIR=file://$I/program
-env:LO_JAVA_DIR=file://$I/program/classes --protector
$W/LinkTarget/Library/unoexceptionprotector.so unoexceptionprotector
--protector $W/LinkTarget/Library/unobootstrapprotector.so
unobootstrapprotector -env:arg-soffice=path:$I/program/soffice
-env:arg-user=$W/CustomTarget/smoketest
-env:arg-env=LD_LIBRARY_PATH"${LD_LIBRARY_PATH+=$LD_LIBRARY_PATH}"
-env:arg-testarg.smoketest.doc=$W/Zip/smoketestdoc.sxw
"-env:CPPUNITTESTTARGET=$W/CppunitTest/smoketest.test" ) 2>&1
[_RUN_] (anonymous namespace)::Test::test
(process:8700): dconf-CRITICAL **: 02:36:13.575: unable to create
directory '/run/user/2952/dconf': Permission denied. dconf will not
work properly.
(process:8708): dconf-CRITICAL **: 02:36:19.328: unable to create
directory '/run/user/2952/dconf': Permission denied. dconf will not
work properly.
(process:8815): dconf-CRITICAL **: 02:36:52.467: unable to create
directory '/run/user/2952/dconf': Permission denied. dconf will not
work properly.
Fatal exception: Signal 11
Stack:
/<>/instdir/program/libuno_sal.so.3(+0x49b18)[0x77d69b18]
/<>/instdir/program/libuno_sal.so.3(+0x49d48)[0x77d69d48]
/usr/lib/jvm/java-17-openjdk-mipsel/lib/server/libjvm.so(+0x537b8c)[0x62417b8c]
./smoketest/smoketest.cxx:187:(anonymous namespace)::Test::test
assertion failed
- Expression: connection_.isStillAlive()
unknown:0:(anonymous namespace)::Test::test
tearDown() failed
- An uncaught exception of type com.sun.star.lang.DisposedException
- Binary URP bridge already disposed at ./binaryurp/source/bridge.cxx:1048
(anonymous namespace)::Test::test finished in: 76764ms
smoketest.cxx:187:Assertion
Test name: (anonymous namespace)::Test::test
assertion failed
- Expression: connection_.isStillAlive()
##Failure Location unknown## : Error
Test name: (anonymous namespace)::Test::test
tearDown() failed
- An uncaught exception of type com.sun.star.lang.DisposedException
- Binary URP bridge already disposed at ./binaryurp/source/bridge.cxx:1048
Failures !!!
Run: 1 Failure total: 2 Failures: 1 Errors: 1
make[3]: *** [/<>/solenv/gbuild/CppunitTest.mk:121:
/<>/workdir/CppunitTest/smoketest.test] Error 1
Regards,
Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi,
Am 19.06.23 um 23:29 schrieb Rene Engelhard:
The pragmatic option would be to run only a smoketest for build success
on architectures not tested by upstream.
And have Format->Character in Impress crash with Bus error like on
mipsel? That doesn't sound too good for basic quality.
There is a "smoketest" but it does just basic start. open, close stuff.
Not even basic usage.
That said, that is the smoketest on mipsel:
[build CUT] smoketest
S=/<> && I=$S/instdir && W=$S/workdir && mkdir -p
$W/CppunitTest/ && rm -fr $W/CppunitTest/smoketest.test.user && cp -r
$W/unittest $W/CppunitTest/smoketest.test.user &&rm -fr
$W/CppunitTest/smoketest.test.core && mkdir
$W/CppunitTest/smoketest.test.core && cd
$W/CppunitTest/smoketest.test.core && ( MAX_CONCURRENCY=4
MOZILLA_CERTIFICATE_FOLDER=dbm:
SAL_DISABLE_SYNCHRONOUS_PRINTER_DETECTION=1 SAL_USE_VCLPLUGIN=svp
LIBO_LANG=C
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"$I/program:$I/program":$W/UnpackedTarball/cppunit/src/cppunit/.libs
$W/LinkTarget/Executable/cppunittester
$W/LinkTarget/CppunitTest/libtest_smoketest.so --headless
"-env:BRAND_BASE_DIR=file://$S/instdir" "-env:BRAND_SHARE_SUBDIR=share"
"-env:BRAND_SHARE_RESOURCE_SUBDIR=program/resource"
"-env:UserInstallation=file://$W/CppunitTest/smoketest.test.user"
"-env:UNO_TYPES=file://$I/program/types.rdb
file://$I/program/types/offapi.rdb"
"-env:UNO_SERVICES=file://$W/Rdb/ure/services.rdb"
-env:URE_BIN_DIR=file://$I/program
-env:URE_INTERNAL_LIB_DIR=file://$I/program
-env:LO_LIB_DIR=file://$I/program
-env:LO_JAVA_DIR=file://$I/program/classes --protector
$W/LinkTarget/Library/unoexceptionprotector.so unoexceptionprotector
--protector $W/LinkTarget/Library/unobootstrapprotector.so
unobootstrapprotector -env:arg-soffice=path:$I/program/soffice
-env:arg-user=$W/CustomTarget/smoketest
-env:arg-env=LD_LIBRARY_PATH"${LD_LIBRARY_PATH+=$LD_LIBRARY_PATH}"
-env:arg-testarg.smoketest.doc=$W/Zip/smoketestdoc.sxw
"-env:CPPUNITTESTTARGET=$W/CppunitTest/smoketest.test" ) 2>&1
[_RUN_] (anonymous namespace)::Test::test
(process:8700): dconf-CRITICAL **: 02:36:13.575: unable to create
directory '/run/user/2952/dconf': Permission denied. dconf will not
work properly.
(process:8708): dconf-CRITICAL **: 02:36:19.328: unable to create
directory '/run/user/2952/dconf': Permission denied. dconf will not
work properly.
(process:8815): dconf-CRITICAL **: 02:36:52.467: unable to create
directory '/run/user/2952/dconf': Permission denied. dconf will not
work properly.
Fatal exception: Signal 11
Stack:
/<>/instdir/program/libuno_sal.so.3(+0x49b18)[0x77d69b18]
/<>/instdir/program/libuno_sal.so.3(+0x49d48)[0x77d69d48]
/usr/lib/jvm/java-17-openjdk-mipsel/lib/server/libjvm.so(+0x537b8c)[0x62417b8c]
./smoketest/smoketest.cxx:187:(anonymous namespace)::Test::test
assertion failed
- Expression: connection_.isStillAlive()
unknown:0:(anonymous namespace)::Test::test
tearDown() failed
- An uncaught exception of type com.sun.star.lang.DisposedException
- Binary URP bridge already disposed at ./binaryurp/source/bridge.cxx:1048
(anonymous namespace)::Test::test finished in: 76764ms
smoketest.cxx:187:Assertion
Test name: (anonymous namespace)::Test::test
assertion failed
- Expression: connection_.isStillAlive()
##Failure Location unknown## : Error
Test name: (anonymous namespace)::Test::test
tearDown() failed
- An uncaught exception of type com.sun.star.lang.DisposedException
- Binary URP bridge already disposed at ./binaryurp/source/bridge.cxx:1048
Failures !!!
Run: 1 Failure total: 2 Failures: 1 Errors: 1
make[3]: *** [/<>/solenv/gbuild/CppunitTest.mk:121:
/<>/workdir/CppunitTest/smoketest.test] Error 1
Regards,
Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi,
Am 19.06.23 um 23:29 schrieb Rene Engelhard:
The pragmatic option would be to run only a smoketest for build success
on architectures not tested by upstream.
And have Format->Character in Impress crash with Bus error like on
mipsel? That doesn't sound too good for basic quality.
There is a "smoketest" but it does just basic start. open, close stuff.
Not even basic usage.
That said, that is the smoketest on mipsel:
[build CUT] smoketest
S=/<> && I=$S/instdir && W=$S/workdir && mkdir -p
$W/CppunitTest/ && rm -fr $W/CppunitTest/smoketest.test.user && cp -r
$W/unittest $W/CppunitTest/smoketest.test.user &&rm -fr
$W/CppunitTest/smoketest.test.core && mkdir
$W/CppunitTest/smoketest.test.core && cd
$W/CppunitTest/smoketest.test.core && ( MAX_CONCURRENCY=4
MOZILLA_CERTIFICATE_FOLDER=dbm:
SAL_DISABLE_SYNCHRONOUS_PRINTER_DETECTION=1 SAL_USE_VCLPLUGIN=svp
LIBO_LANG=C
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"$I/program:$I/program":$W/UnpackedTarball/cppunit/src/cppunit/.libs
$W/LinkTarget/Executable/cppunittester
$W/LinkTarget/CppunitTest/libtest_smoketest.so --headless
"-env:BRAND_BASE_DIR=file://$S/instdir" "-env:BRAND_SHARE_SUBDIR=share"
"-env:BRAND_SHARE_RESOURCE_SUBDIR=program/resource"
"-env:UserInstallation=file://$W/CppunitTest/smoketest.test.user"
"-env:UNO_TYPES=file://$I/program/types.rdb
file://$I/program/types/offapi.rdb"
"-env:UNO_SERVICES=file://$W/Rdb/ure/services.rdb"
-env:URE_BIN_DIR=file://$I/program
-env:URE_INTERNAL_LIB_DIR=file://$I/program
-env:LO_LIB_DIR=file://$I/program
-env:LO_JAVA_DIR=file://$I/program/classes --protector
$W/LinkTarget/Library/unoexceptionprotector.so unoexceptionprotector
--protector $W/LinkTarget/Library/unobootstrapprotector.so
unobootstrapprotector -env:arg-soffice=path:$I/program/soffice
-env:arg-user=$W/CustomTarget/smoketest
-env:arg-env=LD_LIBRARY_PATH"${LD_LIBRARY_PATH+=$LD_LIBRARY_PATH}"
-env:arg-testarg.smoketest.doc=$W/Zip/smoketestdoc.sxw
"-env:CPPUNITTESTTARGET=$W/CppunitTest/smoketest.test" ) 2>&1
[_RUN_] (anonymous namespace)::Test::test
(process:8700): dconf-CRITICAL **: 02:36:13.575: unable to create
directory '/run/user/2952/dconf': Permission denied. dconf will not
work properly.
(process:8708): dconf-CRITICAL **: 02:36:19.328: unable to create
directory '/run/user/2952/dconf': Permission denied. dconf will not
work properly.
(process:8815): dconf-CRITICAL **: 02:36:52.467: unable to create
directory '/run/user/2952/dconf': Permission denied. dconf will not
work properly.
Fatal exception: Signal 11
Stack:
/<>/instdir/program/libuno_sal.so.3(+0x49b18)[0x77d69b18]
/<>/instdir/program/libuno_sal.so.3(+0x49d48)[0x77d69d48]
/usr/lib/jvm/java-17-openjdk-mipsel/lib/server/libjvm.so(+0x537b8c)[0x62417b8c]
./smoketest/smoketest.cxx:187:(anonymous namespace)::Test::test
assertion failed
- Expression: connection_.isStillAlive()
unknown:0:(anonymous namespace)::Test::test
tearDown() failed
- An uncaught exception of type com.sun.star.lang.DisposedException
- Binary URP bridge already disposed at ./binaryurp/source/bridge.cxx:1048
(anonymous namespace)::Test::test finished in: 76764ms
smoketest.cxx:187:Assertion
Test name: (anonymous namespace)::Test::test
assertion failed
- Expression: connection_.isStillAlive()
##Failure Location unknown## : Error
Test name: (anonymous namespace)::Test::test
tearDown() failed
- An uncaught exception of type com.sun.star.lang.DisposedException
- Binary URP bridge already disposed at ./binaryurp/source/bridge.cxx:1048
Failures !!!
Run: 1 Failure total: 2 Failures: 1 Errors: 1
make[3]: *** [/<>/solenv/gbuild/CppunitTest.mk:121:
/<>/workdir/CppunitTest/smoketest.test] Error 1
Regards,
Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi, Am 20.06.23 um 00:03 schrieb Jeffrey Walton: You can usually uncover them by building the package with CFLAGS=" ... -fsanitize=undefined ... " and CXXFLAGS=" ... -fsanitize=undefined ... ". The UBsan sanitizer operates on real data. There are no false positives. I'd personally assume this isn't UB since upstream builds with UBsan for testing (admittedly not on mipsel, though). But once can investigate here... Regards, Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi, Am 20.06.23 um 00:03 schrieb Jeffrey Walton: You can usually uncover them by building the package with CFLAGS=" ... -fsanitize=undefined ... " and CXXFLAGS=" ... -fsanitize=undefined ... ". The UBsan sanitizer operates on real data. There are no false positives. I'd personally assume this isn't UB since upstream builds with UBsan for testing (admittedly not on mipsel, though). But once can investigate here... Regards, Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi, Am 20.06.23 um 00:03 schrieb Jeffrey Walton: You can usually uncover them by building the package with CFLAGS=" ... -fsanitize=undefined ... " and CXXFLAGS=" ... -fsanitize=undefined ... ". The UBsan sanitizer operates on real data. There are no false positives. I'd personally assume this isn't UB since upstream builds with UBsan for testing (admittedly not on mipsel, though). But once can investigate here... Regards, Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi, Am 20.06.23 um 00:03 schrieb Jeffrey Walton: You can usually uncover them by building the package with CFLAGS=" ... -fsanitize=undefined ... " and CXXFLAGS=" ... -fsanitize=undefined ... ". The UBsan sanitizer operates on real data. There are no false positives. I'd personally assume this isn't UB since upstream builds with UBsan for testing (admittedly not on mipsel, though). But once can investigate here... Regards, Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi, Am 20.06.23 um 00:03 schrieb Jeffrey Walton: You can usually uncover them by building the package with CFLAGS=" ... -fsanitize=undefined ... " and CXXFLAGS=" ... -fsanitize=undefined ... ". The UBsan sanitizer operates on real data. There are no false positives. I'd personally assume this isn't UB since upstream builds with UBsan for testing (admittedly not on mipsel, though). But once can investigate here... Regards, Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi, Am 20.06.23 um 00:03 schrieb Jeffrey Walton: You can usually uncover them by building the package with CFLAGS=" ... -fsanitize=undefined ... " and CXXFLAGS=" ... -fsanitize=undefined ... ". The UBsan sanitizer operates on real data. There are no false positives. I'd personally assume this isn't UB since upstream builds with UBsan for testing (admittedly not on mipsel, though). But once can investigate here... Regards, Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi, Am 20.06.23 um 00:03 schrieb Jeffrey Walton: You can usually uncover them by building the package with CFLAGS=" ... -fsanitize=undefined ... " and CXXFLAGS=" ... -fsanitize=undefined ... ". The UBsan sanitizer operates on real data. There are no false positives. I'd personally assume this isn't UB since upstream builds with UBsan for testing (admittedly not on mipsel, though). But once can investigate here... Regards, Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi, Am 20.06.23 um 00:03 schrieb Jeffrey Walton: You can usually uncover them by building the package with CFLAGS=" ... -fsanitize=undefined ... " and CXXFLAGS=" ... -fsanitize=undefined ... ". The UBsan sanitizer operates on real data. There are no false positives. I'd personally assume this isn't UB since upstream builds with UBsan for testing (admittedly not on mipsel, though). But once can investigate here... Regards, Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi, Am 20.06.23 um 00:03 schrieb Jeffrey Walton: You can usually uncover them by building the package with CFLAGS=" ... -fsanitize=undefined ... " and CXXFLAGS=" ... -fsanitize=undefined ... ". The UBsan sanitizer operates on real data. There are no false positives. I'd personally assume this isn't UB since upstream builds with UBsan for testing (admittedly not on mipsel, though). But once can investigate here... Regards, Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi, Am 20.06.23 um 00:03 schrieb Jeffrey Walton: You can usually uncover them by building the package with CFLAGS=" ... -fsanitize=undefined ... " and CXXFLAGS=" ... -fsanitize=undefined ... ". The UBsan sanitizer operates on real data. There are no false positives. I'd personally assume this isn't UB since upstream builds with UBsan for testing (admittedly not on mipsel, though). But once can investigate here... Regards, Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi, Am 20.06.23 um 00:03 schrieb Jeffrey Walton: You can usually uncover them by building the package with CFLAGS=" ... -fsanitize=undefined ... " and CXXFLAGS=" ... -fsanitize=undefined ... ". The UBsan sanitizer operates on real data. There are no false positives. I'd personally assume this isn't UB since upstream builds with UBsan for testing (admittedly not on mipsel, though). But once can investigate here... Regards, Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi, Am 20.06.23 um 00:03 schrieb Jeffrey Walton: You can usually uncover them by building the package with CFLAGS=" ... -fsanitize=undefined ... " and CXXFLAGS=" ... -fsanitize=undefined ... ". The UBsan sanitizer operates on real data. There are no false positives. I'd personally assume this isn't UB since upstream builds with UBsan for testing (admittedly not on mipsel, though). But once can investigate here... Regards, Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi, Am 19.06.23 um 23:19 schrieb Adrian Bunk: On Sun, Jun 18, 2023 at 09:31:05AM +0200, Rene Engelhard wrote: ... I won't be of much help here unfortunately, except maybe testing patches, but then again there's porterboxes ... You are the only one who could realistically debug many of these. E.g. on armel it says: Fatal exception: Signal 6 Stack: /<>/instdir/program/libuno_sal.so.3(+0x3c2e4)[0xb6ec32e4] /<>/instdir/program/libuno_sal.so.3(+0x3c534)[0xb6ec3534] /lib/arm-linux-gnueabi/libc.so.6(__default_rt_sa_restorer+0x0)[0xb6ad58f0] /lib/arm-linux-gnueabi/libc.so.6(+0x7f47c)[0xb6b1e47c] /lib/arm-linux-gnueabi/libc.so.6(gsignal+0x14)[0xb6ad4360] Aborted (core dumped) Fixing something like this would involve generating a backtrace, and then you are likely the only person in Debian who could tell what is actually going on there. Not really. There are likely also build or debug tricks you know that a porter would not know. True, I can help with those if needed. (As I already pointed out for zelenka, though it's basically setting some variables in rules) Debugging something like this is only feasible with reasonable effort if a porter who knows the port with its caveats debugs it together with a package maintainer who knows the internals of the package. I didn't say I was not helping, I said I am of no help if it comes to actually fix it if it involves architecture knowledge. [...] For such a complex package I would expect 32bit breakage in every release if upstream no longer tests on 32bit. Indeed, though at least for 32bit *build* issues they keep fixing them if I report them. The pragmatic option would be to run only a smoketest for build success on architectures not tested by upstream. And have Format->Character in Impress crash with Bus error like on mipsel? That doesn't sound too good for basic quality. There is a "smoketest" but it does just basic start. open, close stuff. Not even basic usage. Regards, Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi, Am 19.06.23 um 23:19 schrieb Adrian Bunk: On Sun, Jun 18, 2023 at 09:31:05AM +0200, Rene Engelhard wrote: ... I won't be of much help here unfortunately, except maybe testing patches, but then again there's porterboxes ... You are the only one who could realistically debug many of these. E.g. on armel it says: Fatal exception: Signal 6 Stack: /<>/instdir/program/libuno_sal.so.3(+0x3c2e4)[0xb6ec32e4] /<>/instdir/program/libuno_sal.so.3(+0x3c534)[0xb6ec3534] /lib/arm-linux-gnueabi/libc.so.6(__default_rt_sa_restorer+0x0)[0xb6ad58f0] /lib/arm-linux-gnueabi/libc.so.6(+0x7f47c)[0xb6b1e47c] /lib/arm-linux-gnueabi/libc.so.6(gsignal+0x14)[0xb6ad4360] Aborted (core dumped) Fixing something like this would involve generating a backtrace, and then you are likely the only person in Debian who could tell what is actually going on there. Not really. There are likely also build or debug tricks you know that a porter would not know. True, I can help with those if needed. (As I already pointed out for zelenka, though it's basically setting some variables in rules) Debugging something like this is only feasible with reasonable effort if a porter who knows the port with its caveats debugs it together with a package maintainer who knows the internals of the package. I didn't say I was not helping, I said I am of no help if it comes to actually fix it if it involves architecture knowledge. [...] For such a complex package I would expect 32bit breakage in every release if upstream no longer tests on 32bit. Indeed, though at least for 32bit *build* issues they keep fixing them if I report them. The pragmatic option would be to run only a smoketest for build success on architectures not tested by upstream. And have Format->Character in Impress crash with Bus error like on mipsel? That doesn't sound too good for basic quality. There is a "smoketest" but it does just basic start. open, close stuff. Not even basic usage. Regards, Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi, Am 19.06.23 um 23:19 schrieb Adrian Bunk: On Sun, Jun 18, 2023 at 09:31:05AM +0200, Rene Engelhard wrote: ... I won't be of much help here unfortunately, except maybe testing patches, but then again there's porterboxes ... You are the only one who could realistically debug many of these. E.g. on armel it says: Fatal exception: Signal 6 Stack: /<>/instdir/program/libuno_sal.so.3(+0x3c2e4)[0xb6ec32e4] /<>/instdir/program/libuno_sal.so.3(+0x3c534)[0xb6ec3534] /lib/arm-linux-gnueabi/libc.so.6(__default_rt_sa_restorer+0x0)[0xb6ad58f0] /lib/arm-linux-gnueabi/libc.so.6(+0x7f47c)[0xb6b1e47c] /lib/arm-linux-gnueabi/libc.so.6(gsignal+0x14)[0xb6ad4360] Aborted (core dumped) Fixing something like this would involve generating a backtrace, and then you are likely the only person in Debian who could tell what is actually going on there. Not really. There are likely also build or debug tricks you know that a porter would not know. True, I can help with those if needed. (As I already pointed out for zelenka, though it's basically setting some variables in rules) Debugging something like this is only feasible with reasonable effort if a porter who knows the port with its caveats debugs it together with a package maintainer who knows the internals of the package. I didn't say I was not helping, I said I am of no help if it comes to actually fix it if it involves architecture knowledge. [...] For such a complex package I would expect 32bit breakage in every release if upstream no longer tests on 32bit. Indeed, though at least for 32bit *build* issues they keep fixing them if I report them. The pragmatic option would be to run only a smoketest for build success on architectures not tested by upstream. And have Format->Character in Impress crash with Bus error like on mipsel? That doesn't sound too good for basic quality. There is a "smoketest" but it does just basic start. open, close stuff. Not even basic usage. Regards, Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi, Am 19.06.23 um 23:19 schrieb Adrian Bunk: On Sun, Jun 18, 2023 at 09:31:05AM +0200, Rene Engelhard wrote: ... I won't be of much help here unfortunately, except maybe testing patches, but then again there's porterboxes ... You are the only one who could realistically debug many of these. E.g. on armel it says: Fatal exception: Signal 6 Stack: /<>/instdir/program/libuno_sal.so.3(+0x3c2e4)[0xb6ec32e4] /<>/instdir/program/libuno_sal.so.3(+0x3c534)[0xb6ec3534] /lib/arm-linux-gnueabi/libc.so.6(__default_rt_sa_restorer+0x0)[0xb6ad58f0] /lib/arm-linux-gnueabi/libc.so.6(+0x7f47c)[0xb6b1e47c] /lib/arm-linux-gnueabi/libc.so.6(gsignal+0x14)[0xb6ad4360] Aborted (core dumped) Fixing something like this would involve generating a backtrace, and then you are likely the only person in Debian who could tell what is actually going on there. Not really. There are likely also build or debug tricks you know that a porter would not know. True, I can help with those if needed. (As I already pointed out for zelenka, though it's basically setting some variables in rules) Debugging something like this is only feasible with reasonable effort if a porter who knows the port with its caveats debugs it together with a package maintainer who knows the internals of the package. I didn't say I was not helping, I said I am of no help if it comes to actually fix it if it involves architecture knowledge. [...] For such a complex package I would expect 32bit breakage in every release if upstream no longer tests on 32bit. Indeed, though at least for 32bit *build* issues they keep fixing them if I report them. The pragmatic option would be to run only a smoketest for build success on architectures not tested by upstream. And have Format->Character in Impress crash with Bus error like on mipsel? That doesn't sound too good for basic quality. There is a "smoketest" but it does just basic start. open, close stuff. Not even basic usage. Regards, Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi, Am 19.06.23 um 23:19 schrieb Adrian Bunk: On Sun, Jun 18, 2023 at 09:31:05AM +0200, Rene Engelhard wrote: ... I won't be of much help here unfortunately, except maybe testing patches, but then again there's porterboxes ... You are the only one who could realistically debug many of these. E.g. on armel it says: Fatal exception: Signal 6 Stack: /<>/instdir/program/libuno_sal.so.3(+0x3c2e4)[0xb6ec32e4] /<>/instdir/program/libuno_sal.so.3(+0x3c534)[0xb6ec3534] /lib/arm-linux-gnueabi/libc.so.6(__default_rt_sa_restorer+0x0)[0xb6ad58f0] /lib/arm-linux-gnueabi/libc.so.6(+0x7f47c)[0xb6b1e47c] /lib/arm-linux-gnueabi/libc.so.6(gsignal+0x14)[0xb6ad4360] Aborted (core dumped) Fixing something like this would involve generating a backtrace, and then you are likely the only person in Debian who could tell what is actually going on there. Not really. There are likely also build or debug tricks you know that a porter would not know. True, I can help with those if needed. (As I already pointed out for zelenka, though it's basically setting some variables in rules) Debugging something like this is only feasible with reasonable effort if a porter who knows the port with its caveats debugs it together with a package maintainer who knows the internals of the package. I didn't say I was not helping, I said I am of no help if it comes to actually fix it if it involves architecture knowledge. [...] For such a complex package I would expect 32bit breakage in every release if upstream no longer tests on 32bit. Indeed, though at least for 32bit *build* issues they keep fixing them if I report them. The pragmatic option would be to run only a smoketest for build success on architectures not tested by upstream. And have Format->Character in Impress crash with Bus error like on mipsel? That doesn't sound too good for basic quality. There is a "smoketest" but it does just basic start. open, close stuff. Not even basic usage. Regards, Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi, Am 19.06.23 um 23:19 schrieb Adrian Bunk: On Sun, Jun 18, 2023 at 09:31:05AM +0200, Rene Engelhard wrote: ... I won't be of much help here unfortunately, except maybe testing patches, but then again there's porterboxes ... You are the only one who could realistically debug many of these. E.g. on armel it says: Fatal exception: Signal 6 Stack: /<>/instdir/program/libuno_sal.so.3(+0x3c2e4)[0xb6ec32e4] /<>/instdir/program/libuno_sal.so.3(+0x3c534)[0xb6ec3534] /lib/arm-linux-gnueabi/libc.so.6(__default_rt_sa_restorer+0x0)[0xb6ad58f0] /lib/arm-linux-gnueabi/libc.so.6(+0x7f47c)[0xb6b1e47c] /lib/arm-linux-gnueabi/libc.so.6(gsignal+0x14)[0xb6ad4360] Aborted (core dumped) Fixing something like this would involve generating a backtrace, and then you are likely the only person in Debian who could tell what is actually going on there. Not really. There are likely also build or debug tricks you know that a porter would not know. True, I can help with those if needed. (As I already pointed out for zelenka, though it's basically setting some variables in rules) Debugging something like this is only feasible with reasonable effort if a porter who knows the port with its caveats debugs it together with a package maintainer who knows the internals of the package. I didn't say I was not helping, I said I am of no help if it comes to actually fix it if it involves architecture knowledge. [...] For such a complex package I would expect 32bit breakage in every release if upstream no longer tests on 32bit. Indeed, though at least for 32bit *build* issues they keep fixing them if I report them. The pragmatic option would be to run only a smoketest for build success on architectures not tested by upstream. And have Format->Character in Impress crash with Bus error like on mipsel? That doesn't sound too good for basic quality. There is a "smoketest" but it does just basic start. open, close stuff. Not even basic usage. Regards, Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi, Am 19.06.23 um 23:19 schrieb Adrian Bunk: On Sun, Jun 18, 2023 at 09:31:05AM +0200, Rene Engelhard wrote: ... I won't be of much help here unfortunately, except maybe testing patches, but then again there's porterboxes ... You are the only one who could realistically debug many of these. E.g. on armel it says: Fatal exception: Signal 6 Stack: /<>/instdir/program/libuno_sal.so.3(+0x3c2e4)[0xb6ec32e4] /<>/instdir/program/libuno_sal.so.3(+0x3c534)[0xb6ec3534] /lib/arm-linux-gnueabi/libc.so.6(__default_rt_sa_restorer+0x0)[0xb6ad58f0] /lib/arm-linux-gnueabi/libc.so.6(+0x7f47c)[0xb6b1e47c] /lib/arm-linux-gnueabi/libc.so.6(gsignal+0x14)[0xb6ad4360] Aborted (core dumped) Fixing something like this would involve generating a backtrace, and then you are likely the only person in Debian who could tell what is actually going on there. Not really. There are likely also build or debug tricks you know that a porter would not know. True, I can help with those if needed. (As I already pointed out for zelenka, though it's basically setting some variables in rules) Debugging something like this is only feasible with reasonable effort if a porter who knows the port with its caveats debugs it together with a package maintainer who knows the internals of the package. I didn't say I was not helping, I said I am of no help if it comes to actually fix it if it involves architecture knowledge. [...] For such a complex package I would expect 32bit breakage in every release if upstream no longer tests on 32bit. Indeed, though at least for 32bit *build* issues they keep fixing them if I report them. The pragmatic option would be to run only a smoketest for build success on architectures not tested by upstream. And have Format->Character in Impress crash with Bus error like on mipsel? That doesn't sound too good for basic quality. There is a "smoketest" but it does just basic start. open, close stuff. Not even basic usage. Regards, Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi, Am 19.06.23 um 23:19 schrieb Adrian Bunk: On Sun, Jun 18, 2023 at 09:31:05AM +0200, Rene Engelhard wrote: ... I won't be of much help here unfortunately, except maybe testing patches, but then again there's porterboxes ... You are the only one who could realistically debug many of these. E.g. on armel it says: Fatal exception: Signal 6 Stack: /<>/instdir/program/libuno_sal.so.3(+0x3c2e4)[0xb6ec32e4] /<>/instdir/program/libuno_sal.so.3(+0x3c534)[0xb6ec3534] /lib/arm-linux-gnueabi/libc.so.6(__default_rt_sa_restorer+0x0)[0xb6ad58f0] /lib/arm-linux-gnueabi/libc.so.6(+0x7f47c)[0xb6b1e47c] /lib/arm-linux-gnueabi/libc.so.6(gsignal+0x14)[0xb6ad4360] Aborted (core dumped) Fixing something like this would involve generating a backtrace, and then you are likely the only person in Debian who could tell what is actually going on there. Not really. There are likely also build or debug tricks you know that a porter would not know. True, I can help with those if needed. (As I already pointed out for zelenka, though it's basically setting some variables in rules) Debugging something like this is only feasible with reasonable effort if a porter who knows the port with its caveats debugs it together with a package maintainer who knows the internals of the package. I didn't say I was not helping, I said I am of no help if it comes to actually fix it if it involves architecture knowledge. [...] For such a complex package I would expect 32bit breakage in every release if upstream no longer tests on 32bit. Indeed, though at least for 32bit *build* issues they keep fixing them if I report them. The pragmatic option would be to run only a smoketest for build success on architectures not tested by upstream. And have Format->Character in Impress crash with Bus error like on mipsel? That doesn't sound too good for basic quality. There is a "smoketest" but it does just basic start. open, close stuff. Not even basic usage. Regards, Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi, Am 19.06.23 um 23:19 schrieb Adrian Bunk: On Sun, Jun 18, 2023 at 09:31:05AM +0200, Rene Engelhard wrote: ... I won't be of much help here unfortunately, except maybe testing patches, but then again there's porterboxes ... You are the only one who could realistically debug many of these. E.g. on armel it says: Fatal exception: Signal 6 Stack: /<>/instdir/program/libuno_sal.so.3(+0x3c2e4)[0xb6ec32e4] /<>/instdir/program/libuno_sal.so.3(+0x3c534)[0xb6ec3534] /lib/arm-linux-gnueabi/libc.so.6(__default_rt_sa_restorer+0x0)[0xb6ad58f0] /lib/arm-linux-gnueabi/libc.so.6(+0x7f47c)[0xb6b1e47c] /lib/arm-linux-gnueabi/libc.so.6(gsignal+0x14)[0xb6ad4360] Aborted (core dumped) Fixing something like this would involve generating a backtrace, and then you are likely the only person in Debian who could tell what is actually going on there. Not really. There are likely also build or debug tricks you know that a porter would not know. True, I can help with those if needed. (As I already pointed out for zelenka, though it's basically setting some variables in rules) Debugging something like this is only feasible with reasonable effort if a porter who knows the port with its caveats debugs it together with a package maintainer who knows the internals of the package. I didn't say I was not helping, I said I am of no help if it comes to actually fix it if it involves architecture knowledge. [...] For such a complex package I would expect 32bit breakage in every release if upstream no longer tests on 32bit. Indeed, though at least for 32bit *build* issues they keep fixing them if I report them. The pragmatic option would be to run only a smoketest for build success on architectures not tested by upstream. And have Format->Character in Impress crash with Bus error like on mipsel? That doesn't sound too good for basic quality. There is a "smoketest" but it does just basic start. open, close stuff. Not even basic usage. Regards, Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi, Am 19.06.23 um 23:19 schrieb Adrian Bunk: On Sun, Jun 18, 2023 at 09:31:05AM +0200, Rene Engelhard wrote: ... I won't be of much help here unfortunately, except maybe testing patches, but then again there's porterboxes ... You are the only one who could realistically debug many of these. E.g. on armel it says: Fatal exception: Signal 6 Stack: /<>/instdir/program/libuno_sal.so.3(+0x3c2e4)[0xb6ec32e4] /<>/instdir/program/libuno_sal.so.3(+0x3c534)[0xb6ec3534] /lib/arm-linux-gnueabi/libc.so.6(__default_rt_sa_restorer+0x0)[0xb6ad58f0] /lib/arm-linux-gnueabi/libc.so.6(+0x7f47c)[0xb6b1e47c] /lib/arm-linux-gnueabi/libc.so.6(gsignal+0x14)[0xb6ad4360] Aborted (core dumped) Fixing something like this would involve generating a backtrace, and then you are likely the only person in Debian who could tell what is actually going on there. Not really. There are likely also build or debug tricks you know that a porter would not know. True, I can help with those if needed. (As I already pointed out for zelenka, though it's basically setting some variables in rules) Debugging something like this is only feasible with reasonable effort if a porter who knows the port with its caveats debugs it together with a package maintainer who knows the internals of the package. I didn't say I was not helping, I said I am of no help if it comes to actually fix it if it involves architecture knowledge. [...] For such a complex package I would expect 32bit breakage in every release if upstream no longer tests on 32bit. Indeed, though at least for 32bit *build* issues they keep fixing them if I report them. The pragmatic option would be to run only a smoketest for build success on architectures not tested by upstream. And have Format->Character in Impress crash with Bus error like on mipsel? That doesn't sound too good for basic quality. There is a "smoketest" but it does just basic start. open, close stuff. Not even basic usage. Regards, Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi, Am 19.06.23 um 23:19 schrieb Adrian Bunk: On Sun, Jun 18, 2023 at 09:31:05AM +0200, Rene Engelhard wrote: ... I won't be of much help here unfortunately, except maybe testing patches, but then again there's porterboxes ... You are the only one who could realistically debug many of these. E.g. on armel it says: Fatal exception: Signal 6 Stack: /<>/instdir/program/libuno_sal.so.3(+0x3c2e4)[0xb6ec32e4] /<>/instdir/program/libuno_sal.so.3(+0x3c534)[0xb6ec3534] /lib/arm-linux-gnueabi/libc.so.6(__default_rt_sa_restorer+0x0)[0xb6ad58f0] /lib/arm-linux-gnueabi/libc.so.6(+0x7f47c)[0xb6b1e47c] /lib/arm-linux-gnueabi/libc.so.6(gsignal+0x14)[0xb6ad4360] Aborted (core dumped) Fixing something like this would involve generating a backtrace, and then you are likely the only person in Debian who could tell what is actually going on there. Not really. There are likely also build or debug tricks you know that a porter would not know. True, I can help with those if needed. (As I already pointed out for zelenka, though it's basically setting some variables in rules) Debugging something like this is only feasible with reasonable effort if a porter who knows the port with its caveats debugs it together with a package maintainer who knows the internals of the package. I didn't say I was not helping, I said I am of no help if it comes to actually fix it if it involves architecture knowledge. [...] For such a complex package I would expect 32bit breakage in every release if upstream no longer tests on 32bit. Indeed, though at least for 32bit *build* issues they keep fixing them if I report them. The pragmatic option would be to run only a smoketest for build success on architectures not tested by upstream. And have Format->Character in Impress crash with Bus error like on mipsel? That doesn't sound too good for basic quality. There is a "smoketest" but it does just basic start. open, close stuff. Not even basic usage. Regards, Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi, Am 19.06.23 um 23:19 schrieb Adrian Bunk: On Sun, Jun 18, 2023 at 09:31:05AM +0200, Rene Engelhard wrote: ... I won't be of much help here unfortunately, except maybe testing patches, but then again there's porterboxes ... You are the only one who could realistically debug many of these. E.g. on armel it says: Fatal exception: Signal 6 Stack: /<>/instdir/program/libuno_sal.so.3(+0x3c2e4)[0xb6ec32e4] /<>/instdir/program/libuno_sal.so.3(+0x3c534)[0xb6ec3534] /lib/arm-linux-gnueabi/libc.so.6(__default_rt_sa_restorer+0x0)[0xb6ad58f0] /lib/arm-linux-gnueabi/libc.so.6(+0x7f47c)[0xb6b1e47c] /lib/arm-linux-gnueabi/libc.so.6(gsignal+0x14)[0xb6ad4360] Aborted (core dumped) Fixing something like this would involve generating a backtrace, and then you are likely the only person in Debian who could tell what is actually going on there. Not really. There are likely also build or debug tricks you know that a porter would not know. True, I can help with those if needed. (As I already pointed out for zelenka, though it's basically setting some variables in rules) Debugging something like this is only feasible with reasonable effort if a porter who knows the port with its caveats debugs it together with a package maintainer who knows the internals of the package. I didn't say I was not helping, I said I am of no help if it comes to actually fix it if it involves architecture knowledge. [...] For such a complex package I would expect 32bit breakage in every release if upstream no longer tests on 32bit. Indeed, though at least for 32bit *build* issues they keep fixing them if I report them. The pragmatic option would be to run only a smoketest for build success on architectures not tested by upstream. And have Format->Character in Impress crash with Bus error like on mipsel? That doesn't sound too good for basic quality. There is a "smoketest" but it does just basic start. open, close stuff. Not even basic usage. Regards, Rene
[Git][java-team/hsqldb] Pushed new branch bookworm
Rene Engelhard pushed new branch bookworm at Debian Java Maintainers / hsqldb -- View it on GitLab: https://salsa.debian.org/java-team/hsqldb/-/tree/bookworm You're receiving this email because of your account on salsa.debian.org. ___ pkg-java-commits mailing list pkg-java-comm...@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-java-commits
[Git][java-team/hsqldb][bullseye] 2 commits: fix CVE-2023-1183
Rene Engelhard pushed to branch bullseye at Debian Java Maintainers / hsqldb
Commits:
a768daa1 by Rene Engelhard at 2023-06-15T23:10:31+02:00
fix CVE-2023-1183
- - - - -
0eeccaf4 by Rene Engelhard at 2023-06-17T12:51:54+02:00
update CVE-2023-1183.diff
- - - - -
3 changed files:
- debian/changelog
- + debian/patches/CVE-2023-1183.diff
- debian/patches/series
Changes:
=
debian/changelog
=
@@ -1,3 +1,11 @@
+hsqldb (2.5.1-1+deb11u2) bullseye-security; urgency=medium
+
+ * Team upload.
+
+ * fix CVE-2023-1183
+
+ -- Rene Engelhard Sat, 17 Jun 2023 12:51:34 +0200
+
hsqldb (2.5.1-1+deb11u1) bullseye-security; urgency=high
* Team upload.
=
debian/patches/CVE-2023-1183.diff
=
@@ -0,0 +1,26 @@
+diff --git a/hsqldb/src/org/hsqldb/StatementCommand.java
b/hsqldb/src/org/hsqldb/StatementCommand.java
+index ab29d28..eaef1ab 100644
+--- a/hsqldb/src/org/hsqldb/StatementCommand.java
b/hsqldb/src/org/hsqldb/StatementCommand.java
+@@ -963,6 +963,10 @@ public class StatementCommand extends Statement {
+ try {
+ session.checkAdmin();
+
++if (session.isProcessingScript() ||
session.isProcessingLog()) {
++return Result.updateZeroResult;
++}
++
+ if (name == null) {
+ return session.database.getScript(false);
+ } else {
+@@ -1028,6 +1032,10 @@ public class StatementCommand extends Statement {
+ int mode = ((Integer)
arguments[1]).intValue();
+ Boolean isVersioning = (Boolean) arguments[2];
+
++if (session.isProcessingScript() ||
session.isProcessingLog()) {
++return Result.updateZeroResult;
++}
++
+ return ScriptLoader.loadScriptData(
+ session, pathName, mode, isVersioning.booleanValue());
+ } catch (HsqlException e) {
=
debian/patches/series
=
@@ -1 +1,2 @@
CVE-2022-41853.patch
+CVE-2023-1183.diff
View it on GitLab:
https://salsa.debian.org/java-team/hsqldb/-/compare/e28073a39e82e541501b2450b82143acd3c57715...0eeccaf4c3b29a425bc27dad534ec7a672bec3da
--
View it on GitLab:
https://salsa.debian.org/java-team/hsqldb/-/compare/e28073a39e82e541501b2450b82143acd3c57715...0eeccaf4c3b29a425bc27dad534ec7a672bec3da
You're receiving this email because of your account on salsa.debian.org.
___
pkg-java-commits mailing list
pkg-java-comm...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-java-commits
Re: unbreaking LibreOffices tests on at least release architectures
Hi again, some more comments. Am 18.06.23 um 21:28 schrieb Rob Landley: No, that's how I read it too. You said getting the _architectures_ removed, not getting libreoffice removed from those architectures. That is hilarious. The subject says we are talking about LibreOffice here, not generally about Debian. I might have written architectures, but from the context it should have been clear. Anyway, I corrected it. Of course I mean "getting those architectures removed from unstable" *for libreoffice*. here. Besides that it would also have been clear from actually reading the IRC log which incidentially also says "17:24 < elbrus> if I were you, I'd make them fatal everywhere and ask for removal from architectures where reasonable tests fail 17:25 < elbrus> extreme case you only ship on amd64 and arm64" (libreoffice) *removal from architectures* This is the same GPLv3 package that Red Hat just dropped support for? As I said in my other reply, even if it was GPLv3 it wouldn't be relevant at all. LibreOffice is not GPLv3 though and never was. How long has the problem you're treating as a crisis been brewing? Basically ever since people ported, the tests back then pass and then new tests broke and noone seriously cared until me as not-porter needed to sweep it under the carpet eo get it "ready" for release (because it otherwise was supposed to be removed). Or since people added a new arch in LibreOffice but didn't dare of finishing it so that even the important tests pass. Even if it works now, who says that with ignored tests something fundamental breaks (like python thingies in riscv64, which is a integral part of many LO things). Or some basic functionality? Causing a RC bug which is unfixable for me. Replying with something completely unrelated doesn't help here. No idea why you bring up GPLv3 or RH stopping support for it (which is bad for this case, though, since at least they did fix some tests on s390x etc., but we actually do have porters, too) here on a mail which just aims at porting LibreOffice / making it actually pass its tests to improve quality. Regards, Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi again, some more comments. Am 18.06.23 um 21:28 schrieb Rob Landley: No, that's how I read it too. You said getting the _architectures_ removed, not getting libreoffice removed from those architectures. That is hilarious. The subject says we are talking about LibreOffice here, not generally about Debian. I might have written architectures, but from the context it should have been clear. Anyway, I corrected it. Of course I mean "getting those architectures removed from unstable" *for libreoffice*. here. Besides that it would also have been clear from actually reading the IRC log which incidentially also says "17:24 < elbrus> if I were you, I'd make them fatal everywhere and ask for removal from architectures where reasonable tests fail 17:25 < elbrus> extreme case you only ship on amd64 and arm64" (libreoffice) *removal from architectures* This is the same GPLv3 package that Red Hat just dropped support for? As I said in my other reply, even if it was GPLv3 it wouldn't be relevant at all. LibreOffice is not GPLv3 though and never was. How long has the problem you're treating as a crisis been brewing? Basically ever since people ported, the tests back then pass and then new tests broke and noone seriously cared until me as not-porter needed to sweep it under the carpet eo get it "ready" for release (because it otherwise was supposed to be removed). Or since people added a new arch in LibreOffice but didn't dare of finishing it so that even the important tests pass. Even if it works now, who says that with ignored tests something fundamental breaks (like python thingies in riscv64, which is a integral part of many LO things). Or some basic functionality? Causing a RC bug which is unfixable for me. Replying with something completely unrelated doesn't help here. No idea why you bring up GPLv3 or RH stopping support for it (which is bad for this case, though, since at least they did fix some tests on s390x etc., but we actually do have porters, too) here on a mail which just aims at porting LibreOffice / making it actually pass its tests to improve quality. Regards, Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi again, some more comments. Am 18.06.23 um 21:28 schrieb Rob Landley: No, that's how I read it too. You said getting the _architectures_ removed, not getting libreoffice removed from those architectures. That is hilarious. The subject says we are talking about LibreOffice here, not generally about Debian. I might have written architectures, but from the context it should have been clear. Anyway, I corrected it. Of course I mean "getting those architectures removed from unstable" *for libreoffice*. here. Besides that it would also have been clear from actually reading the IRC log which incidentially also says "17:24 < elbrus> if I were you, I'd make them fatal everywhere and ask for removal from architectures where reasonable tests fail 17:25 < elbrus> extreme case you only ship on amd64 and arm64" (libreoffice) *removal from architectures* This is the same GPLv3 package that Red Hat just dropped support for? As I said in my other reply, even if it was GPLv3 it wouldn't be relevant at all. LibreOffice is not GPLv3 though and never was. How long has the problem you're treating as a crisis been brewing? Basically ever since people ported, the tests back then pass and then new tests broke and noone seriously cared until me as not-porter needed to sweep it under the carpet eo get it "ready" for release (because it otherwise was supposed to be removed). Or since people added a new arch in LibreOffice but didn't dare of finishing it so that even the important tests pass. Even if it works now, who says that with ignored tests something fundamental breaks (like python thingies in riscv64, which is a integral part of many LO things). Or some basic functionality? Causing a RC bug which is unfixable for me. Replying with something completely unrelated doesn't help here. No idea why you bring up GPLv3 or RH stopping support for it (which is bad for this case, though, since at least they did fix some tests on s390x etc., but we actually do have porters, too) here on a mail which just aims at porting LibreOffice / making it actually pass its tests to improve quality. Regards, Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi again, some more comments. Am 18.06.23 um 21:28 schrieb Rob Landley: No, that's how I read it too. You said getting the _architectures_ removed, not getting libreoffice removed from those architectures. That is hilarious. The subject says we are talking about LibreOffice here, not generally about Debian. I might have written architectures, but from the context it should have been clear. Anyway, I corrected it. Of course I mean "getting those architectures removed from unstable" *for libreoffice*. here. Besides that it would also have been clear from actually reading the IRC log which incidentially also says "17:24 < elbrus> if I were you, I'd make them fatal everywhere and ask for removal from architectures where reasonable tests fail 17:25 < elbrus> extreme case you only ship on amd64 and arm64" (libreoffice) *removal from architectures* This is the same GPLv3 package that Red Hat just dropped support for? As I said in my other reply, even if it was GPLv3 it wouldn't be relevant at all. LibreOffice is not GPLv3 though and never was. How long has the problem you're treating as a crisis been brewing? Basically ever since people ported, the tests back then pass and then new tests broke and noone seriously cared until me as not-porter needed to sweep it under the carpet eo get it "ready" for release (because it otherwise was supposed to be removed). Or since people added a new arch in LibreOffice but didn't dare of finishing it so that even the important tests pass. Even if it works now, who says that with ignored tests something fundamental breaks (like python thingies in riscv64, which is a integral part of many LO things). Or some basic functionality? Causing a RC bug which is unfixable for me. Replying with something completely unrelated doesn't help here. No idea why you bring up GPLv3 or RH stopping support for it (which is bad for this case, though, since at least they did fix some tests on s390x etc., but we actually do have porters, too) here on a mail which just aims at porting LibreOffice / making it actually pass its tests to improve quality. Regards, Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi again, some more comments. Am 18.06.23 um 21:28 schrieb Rob Landley: No, that's how I read it too. You said getting the _architectures_ removed, not getting libreoffice removed from those architectures. That is hilarious. The subject says we are talking about LibreOffice here, not generally about Debian. I might have written architectures, but from the context it should have been clear. Anyway, I corrected it. Of course I mean "getting those architectures removed from unstable" *for libreoffice*. here. Besides that it would also have been clear from actually reading the IRC log which incidentially also says "17:24 < elbrus> if I were you, I'd make them fatal everywhere and ask for removal from architectures where reasonable tests fail 17:25 < elbrus> extreme case you only ship on amd64 and arm64" (libreoffice) *removal from architectures* This is the same GPLv3 package that Red Hat just dropped support for? As I said in my other reply, even if it was GPLv3 it wouldn't be relevant at all. LibreOffice is not GPLv3 though and never was. How long has the problem you're treating as a crisis been brewing? Basically ever since people ported, the tests back then pass and then new tests broke and noone seriously cared until me as not-porter needed to sweep it under the carpet eo get it "ready" for release (because it otherwise was supposed to be removed). Or since people added a new arch in LibreOffice but didn't dare of finishing it so that even the important tests pass. Even if it works now, who says that with ignored tests something fundamental breaks (like python thingies in riscv64, which is a integral part of many LO things). Or some basic functionality? Causing a RC bug which is unfixable for me. Replying with something completely unrelated doesn't help here. No idea why you bring up GPLv3 or RH stopping support for it (which is bad for this case, though, since at least they did fix some tests on s390x etc., but we actually do have porters, too) here on a mail which just aims at porting LibreOffice / making it actually pass its tests to improve quality. Regards, Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi again, some more comments. Am 18.06.23 um 21:28 schrieb Rob Landley: No, that's how I read it too. You said getting the _architectures_ removed, not getting libreoffice removed from those architectures. That is hilarious. The subject says we are talking about LibreOffice here, not generally about Debian. I might have written architectures, but from the context it should have been clear. Anyway, I corrected it. Of course I mean "getting those architectures removed from unstable" *for libreoffice*. here. Besides that it would also have been clear from actually reading the IRC log which incidentially also says "17:24 < elbrus> if I were you, I'd make them fatal everywhere and ask for removal from architectures where reasonable tests fail 17:25 < elbrus> extreme case you only ship on amd64 and arm64" (libreoffice) *removal from architectures* This is the same GPLv3 package that Red Hat just dropped support for? As I said in my other reply, even if it was GPLv3 it wouldn't be relevant at all. LibreOffice is not GPLv3 though and never was. How long has the problem you're treating as a crisis been brewing? Basically ever since people ported, the tests back then pass and then new tests broke and noone seriously cared until me as not-porter needed to sweep it under the carpet eo get it "ready" for release (because it otherwise was supposed to be removed). Or since people added a new arch in LibreOffice but didn't dare of finishing it so that even the important tests pass. Even if it works now, who says that with ignored tests something fundamental breaks (like python thingies in riscv64, which is a integral part of many LO things). Or some basic functionality? Causing a RC bug which is unfixable for me. Replying with something completely unrelated doesn't help here. No idea why you bring up GPLv3 or RH stopping support for it (which is bad for this case, though, since at least they did fix some tests on s390x etc., but we actually do have porters, too) here on a mail which just aims at porting LibreOffice / making it actually pass its tests to improve quality. Regards, Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi again, some more comments. Am 18.06.23 um 21:28 schrieb Rob Landley: No, that's how I read it too. You said getting the _architectures_ removed, not getting libreoffice removed from those architectures. That is hilarious. The subject says we are talking about LibreOffice here, not generally about Debian. I might have written architectures, but from the context it should have been clear. Anyway, I corrected it. Of course I mean "getting those architectures removed from unstable" *for libreoffice*. here. Besides that it would also have been clear from actually reading the IRC log which incidentially also says "17:24 < elbrus> if I were you, I'd make them fatal everywhere and ask for removal from architectures where reasonable tests fail 17:25 < elbrus> extreme case you only ship on amd64 and arm64" (libreoffice) *removal from architectures* This is the same GPLv3 package that Red Hat just dropped support for? As I said in my other reply, even if it was GPLv3 it wouldn't be relevant at all. LibreOffice is not GPLv3 though and never was. How long has the problem you're treating as a crisis been brewing? Basically ever since people ported, the tests back then pass and then new tests broke and noone seriously cared until me as not-porter needed to sweep it under the carpet eo get it "ready" for release (because it otherwise was supposed to be removed). Or since people added a new arch in LibreOffice but didn't dare of finishing it so that even the important tests pass. Even if it works now, who says that with ignored tests something fundamental breaks (like python thingies in riscv64, which is a integral part of many LO things). Or some basic functionality? Causing a RC bug which is unfixable for me. Replying with something completely unrelated doesn't help here. No idea why you bring up GPLv3 or RH stopping support for it (which is bad for this case, though, since at least they did fix some tests on s390x etc., but we actually do have porters, too) here on a mail which just aims at porting LibreOffice / making it actually pass its tests to improve quality. Regards, Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi again, some more comments. Am 18.06.23 um 21:28 schrieb Rob Landley: No, that's how I read it too. You said getting the _architectures_ removed, not getting libreoffice removed from those architectures. That is hilarious. The subject says we are talking about LibreOffice here, not generally about Debian. I might have written architectures, but from the context it should have been clear. Anyway, I corrected it. Of course I mean "getting those architectures removed from unstable" *for libreoffice*. here. Besides that it would also have been clear from actually reading the IRC log which incidentially also says "17:24 < elbrus> if I were you, I'd make them fatal everywhere and ask for removal from architectures where reasonable tests fail 17:25 < elbrus> extreme case you only ship on amd64 and arm64" (libreoffice) *removal from architectures* This is the same GPLv3 package that Red Hat just dropped support for? As I said in my other reply, even if it was GPLv3 it wouldn't be relevant at all. LibreOffice is not GPLv3 though and never was. How long has the problem you're treating as a crisis been brewing? Basically ever since people ported, the tests back then pass and then new tests broke and noone seriously cared until me as not-porter needed to sweep it under the carpet eo get it "ready" for release (because it otherwise was supposed to be removed). Or since people added a new arch in LibreOffice but didn't dare of finishing it so that even the important tests pass. Even if it works now, who says that with ignored tests something fundamental breaks (like python thingies in riscv64, which is a integral part of many LO things). Or some basic functionality? Causing a RC bug which is unfixable for me. Replying with something completely unrelated doesn't help here. No idea why you bring up GPLv3 or RH stopping support for it (which is bad for this case, though, since at least they did fix some tests on s390x etc., but we actually do have porters, too) here on a mail which just aims at porting LibreOffice / making it actually pass its tests to improve quality. Regards, Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi again, some more comments. Am 18.06.23 um 21:28 schrieb Rob Landley: No, that's how I read it too. You said getting the _architectures_ removed, not getting libreoffice removed from those architectures. That is hilarious. The subject says we are talking about LibreOffice here, not generally about Debian. I might have written architectures, but from the context it should have been clear. Anyway, I corrected it. Of course I mean "getting those architectures removed from unstable" *for libreoffice*. here. Besides that it would also have been clear from actually reading the IRC log which incidentially also says "17:24 < elbrus> if I were you, I'd make them fatal everywhere and ask for removal from architectures where reasonable tests fail 17:25 < elbrus> extreme case you only ship on amd64 and arm64" (libreoffice) *removal from architectures* This is the same GPLv3 package that Red Hat just dropped support for? As I said in my other reply, even if it was GPLv3 it wouldn't be relevant at all. LibreOffice is not GPLv3 though and never was. How long has the problem you're treating as a crisis been brewing? Basically ever since people ported, the tests back then pass and then new tests broke and noone seriously cared until me as not-porter needed to sweep it under the carpet eo get it "ready" for release (because it otherwise was supposed to be removed). Or since people added a new arch in LibreOffice but didn't dare of finishing it so that even the important tests pass. Even if it works now, who says that with ignored tests something fundamental breaks (like python thingies in riscv64, which is a integral part of many LO things). Or some basic functionality? Causing a RC bug which is unfixable for me. Replying with something completely unrelated doesn't help here. No idea why you bring up GPLv3 or RH stopping support for it (which is bad for this case, though, since at least they did fix some tests on s390x etc., but we actually do have porters, too) here on a mail which just aims at porting LibreOffice / making it actually pass its tests to improve quality. Regards, Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi again, some more comments. Am 18.06.23 um 21:28 schrieb Rob Landley: No, that's how I read it too. You said getting the _architectures_ removed, not getting libreoffice removed from those architectures. That is hilarious. The subject says we are talking about LibreOffice here, not generally about Debian. I might have written architectures, but from the context it should have been clear. Anyway, I corrected it. Of course I mean "getting those architectures removed from unstable" *for libreoffice*. here. Besides that it would also have been clear from actually reading the IRC log which incidentially also says "17:24 < elbrus> if I were you, I'd make them fatal everywhere and ask for removal from architectures where reasonable tests fail 17:25 < elbrus> extreme case you only ship on amd64 and arm64" (libreoffice) *removal from architectures* This is the same GPLv3 package that Red Hat just dropped support for? As I said in my other reply, even if it was GPLv3 it wouldn't be relevant at all. LibreOffice is not GPLv3 though and never was. How long has the problem you're treating as a crisis been brewing? Basically ever since people ported, the tests back then pass and then new tests broke and noone seriously cared until me as not-porter needed to sweep it under the carpet eo get it "ready" for release (because it otherwise was supposed to be removed). Or since people added a new arch in LibreOffice but didn't dare of finishing it so that even the important tests pass. Even if it works now, who says that with ignored tests something fundamental breaks (like python thingies in riscv64, which is a integral part of many LO things). Or some basic functionality? Causing a RC bug which is unfixable for me. Replying with something completely unrelated doesn't help here. No idea why you bring up GPLv3 or RH stopping support for it (which is bad for this case, though, since at least they did fix some tests on s390x etc., but we actually do have porters, too) here on a mail which just aims at porting LibreOffice / making it actually pass its tests to improve quality. Regards, Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi again, some more comments. Am 18.06.23 um 21:28 schrieb Rob Landley: No, that's how I read it too. You said getting the _architectures_ removed, not getting libreoffice removed from those architectures. That is hilarious. The subject says we are talking about LibreOffice here, not generally about Debian. I might have written architectures, but from the context it should have been clear. Anyway, I corrected it. Of course I mean "getting those architectures removed from unstable" *for libreoffice*. here. Besides that it would also have been clear from actually reading the IRC log which incidentially also says "17:24 < elbrus> if I were you, I'd make them fatal everywhere and ask for removal from architectures where reasonable tests fail 17:25 < elbrus> extreme case you only ship on amd64 and arm64" (libreoffice) *removal from architectures* This is the same GPLv3 package that Red Hat just dropped support for? As I said in my other reply, even if it was GPLv3 it wouldn't be relevant at all. LibreOffice is not GPLv3 though and never was. How long has the problem you're treating as a crisis been brewing? Basically ever since people ported, the tests back then pass and then new tests broke and noone seriously cared until me as not-porter needed to sweep it under the carpet eo get it "ready" for release (because it otherwise was supposed to be removed). Or since people added a new arch in LibreOffice but didn't dare of finishing it so that even the important tests pass. Even if it works now, who says that with ignored tests something fundamental breaks (like python thingies in riscv64, which is a integral part of many LO things). Or some basic functionality? Causing a RC bug which is unfixable for me. Replying with something completely unrelated doesn't help here. No idea why you bring up GPLv3 or RH stopping support for it (which is bad for this case, though, since at least they did fix some tests on s390x etc., but we actually do have porters, too) here on a mail which just aims at porting LibreOffice / making it actually pass its tests to improve quality. Regards, Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi again, some more comments. Am 18.06.23 um 21:28 schrieb Rob Landley: No, that's how I read it too. You said getting the _architectures_ removed, not getting libreoffice removed from those architectures. That is hilarious. The subject says we are talking about LibreOffice here, not generally about Debian. I might have written architectures, but from the context it should have been clear. Anyway, I corrected it. Of course I mean "getting those architectures removed from unstable" *for libreoffice*. here. Besides that it would also have been clear from actually reading the IRC log which incidentially also says "17:24 < elbrus> if I were you, I'd make them fatal everywhere and ask for removal from architectures where reasonable tests fail 17:25 < elbrus> extreme case you only ship on amd64 and arm64" (libreoffice) *removal from architectures* This is the same GPLv3 package that Red Hat just dropped support for? As I said in my other reply, even if it was GPLv3 it wouldn't be relevant at all. LibreOffice is not GPLv3 though and never was. How long has the problem you're treating as a crisis been brewing? Basically ever since people ported, the tests back then pass and then new tests broke and noone seriously cared until me as not-porter needed to sweep it under the carpet eo get it "ready" for release (because it otherwise was supposed to be removed). Or since people added a new arch in LibreOffice but didn't dare of finishing it so that even the important tests pass. Even if it works now, who says that with ignored tests something fundamental breaks (like python thingies in riscv64, which is a integral part of many LO things). Or some basic functionality? Causing a RC bug which is unfixable for me. Replying with something completely unrelated doesn't help here. No idea why you bring up GPLv3 or RH stopping support for it (which is bad for this case, though, since at least they did fix some tests on s390x etc., but we actually do have porters, too) here on a mail which just aims at porting LibreOffice / making it actually pass its tests to improve quality. Regards, Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi, Am 18.06.23 um 21:28 schrieb Rob Landley: Of course I mean "getting those architectures removed from unstable" *for libreoffice*. This is the same GPLv3 package that Red Hat just dropped support for? GPLv3 doesn't have anything to do with this here. https://lwn.net/Articles/933525/ Indeed. When gcc switched to GPLv3 llvm appeared. When Samba switched to GPLv3 Apple wrote their own and Linux grew the ksmbd in-kernel server. Three years ago Samba maintainer Jeremy Allison lamented that "Both GPLv3 and the AGPL have been rejected soundly by most developers" and talked about how he regretted the move and the damage it had done to the project, https://archive.org/details/copyleftconf2020-allison Can we please talk about the actual issue at and - that is not the license. That is the tests being broken on anything except amd64 and arm64. How long has the problem you're treating as a crisis been brewing? Far too long, as I said it was swept under the carpet for too long. Regards, Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi, Am 18.06.23 um 21:28 schrieb Rob Landley: Of course I mean "getting those architectures removed from unstable" *for libreoffice*. This is the same GPLv3 package that Red Hat just dropped support for? GPLv3 doesn't have anything to do with this here. https://lwn.net/Articles/933525/ Indeed. When gcc switched to GPLv3 llvm appeared. When Samba switched to GPLv3 Apple wrote their own and Linux grew the ksmbd in-kernel server. Three years ago Samba maintainer Jeremy Allison lamented that "Both GPLv3 and the AGPL have been rejected soundly by most developers" and talked about how he regretted the move and the damage it had done to the project, https://archive.org/details/copyleftconf2020-allison Can we please talk about the actual issue at and - that is not the license. That is the tests being broken on anything except amd64 and arm64. How long has the problem you're treating as a crisis been brewing? Far too long, as I said it was swept under the carpet for too long. Regards, Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi, Am 18.06.23 um 21:28 schrieb Rob Landley: Of course I mean "getting those architectures removed from unstable" *for libreoffice*. This is the same GPLv3 package that Red Hat just dropped support for? GPLv3 doesn't have anything to do with this here. https://lwn.net/Articles/933525/ Indeed. When gcc switched to GPLv3 llvm appeared. When Samba switched to GPLv3 Apple wrote their own and Linux grew the ksmbd in-kernel server. Three years ago Samba maintainer Jeremy Allison lamented that "Both GPLv3 and the AGPL have been rejected soundly by most developers" and talked about how he regretted the move and the damage it had done to the project, https://archive.org/details/copyleftconf2020-allison Can we please talk about the actual issue at and - that is not the license. That is the tests being broken on anything except amd64 and arm64. How long has the problem you're treating as a crisis been brewing? Far too long, as I said it was swept under the carpet for too long. Regards, Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi, Am 18.06.23 um 21:28 schrieb Rob Landley: Of course I mean "getting those architectures removed from unstable" *for libreoffice*. This is the same GPLv3 package that Red Hat just dropped support for? GPLv3 doesn't have anything to do with this here. https://lwn.net/Articles/933525/ Indeed. When gcc switched to GPLv3 llvm appeared. When Samba switched to GPLv3 Apple wrote their own and Linux grew the ksmbd in-kernel server. Three years ago Samba maintainer Jeremy Allison lamented that "Both GPLv3 and the AGPL have been rejected soundly by most developers" and talked about how he regretted the move and the damage it had done to the project, https://archive.org/details/copyleftconf2020-allison Can we please talk about the actual issue at and - that is not the license. That is the tests being broken on anything except amd64 and arm64. How long has the problem you're treating as a crisis been brewing? Far too long, as I said it was swept under the carpet for too long. Regards, Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi, Am 18.06.23 um 21:28 schrieb Rob Landley: Of course I mean "getting those architectures removed from unstable" *for libreoffice*. This is the same GPLv3 package that Red Hat just dropped support for? GPLv3 doesn't have anything to do with this here. https://lwn.net/Articles/933525/ Indeed. When gcc switched to GPLv3 llvm appeared. When Samba switched to GPLv3 Apple wrote their own and Linux grew the ksmbd in-kernel server. Three years ago Samba maintainer Jeremy Allison lamented that "Both GPLv3 and the AGPL have been rejected soundly by most developers" and talked about how he regretted the move and the damage it had done to the project, https://archive.org/details/copyleftconf2020-allison Can we please talk about the actual issue at and - that is not the license. That is the tests being broken on anything except amd64 and arm64. How long has the problem you're treating as a crisis been brewing? Far too long, as I said it was swept under the carpet for too long. Regards, Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi, Am 18.06.23 um 21:28 schrieb Rob Landley: Of course I mean "getting those architectures removed from unstable" *for libreoffice*. This is the same GPLv3 package that Red Hat just dropped support for? GPLv3 doesn't have anything to do with this here. https://lwn.net/Articles/933525/ Indeed. When gcc switched to GPLv3 llvm appeared. When Samba switched to GPLv3 Apple wrote their own and Linux grew the ksmbd in-kernel server. Three years ago Samba maintainer Jeremy Allison lamented that "Both GPLv3 and the AGPL have been rejected soundly by most developers" and talked about how he regretted the move and the damage it had done to the project, https://archive.org/details/copyleftconf2020-allison Can we please talk about the actual issue at and - that is not the license. That is the tests being broken on anything except amd64 and arm64. How long has the problem you're treating as a crisis been brewing? Far too long, as I said it was swept under the carpet for too long. Regards, Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi, Am 18.06.23 um 21:28 schrieb Rob Landley: Of course I mean "getting those architectures removed from unstable" *for libreoffice*. This is the same GPLv3 package that Red Hat just dropped support for? GPLv3 doesn't have anything to do with this here. https://lwn.net/Articles/933525/ Indeed. When gcc switched to GPLv3 llvm appeared. When Samba switched to GPLv3 Apple wrote their own and Linux grew the ksmbd in-kernel server. Three years ago Samba maintainer Jeremy Allison lamented that "Both GPLv3 and the AGPL have been rejected soundly by most developers" and talked about how he regretted the move and the damage it had done to the project, https://archive.org/details/copyleftconf2020-allison Can we please talk about the actual issue at and - that is not the license. That is the tests being broken on anything except amd64 and arm64. How long has the problem you're treating as a crisis been brewing? Far too long, as I said it was swept under the carpet for too long. Regards, Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi, Am 18.06.23 um 21:28 schrieb Rob Landley: Of course I mean "getting those architectures removed from unstable" *for libreoffice*. This is the same GPLv3 package that Red Hat just dropped support for? GPLv3 doesn't have anything to do with this here. https://lwn.net/Articles/933525/ Indeed. When gcc switched to GPLv3 llvm appeared. When Samba switched to GPLv3 Apple wrote their own and Linux grew the ksmbd in-kernel server. Three years ago Samba maintainer Jeremy Allison lamented that "Both GPLv3 and the AGPL have been rejected soundly by most developers" and talked about how he regretted the move and the damage it had done to the project, https://archive.org/details/copyleftconf2020-allison Can we please talk about the actual issue at and - that is not the license. That is the tests being broken on anything except amd64 and arm64. How long has the problem you're treating as a crisis been brewing? Far too long, as I said it was swept under the carpet for too long. Regards, Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi, Am 18.06.23 um 21:28 schrieb Rob Landley: Of course I mean "getting those architectures removed from unstable" *for libreoffice*. This is the same GPLv3 package that Red Hat just dropped support for? GPLv3 doesn't have anything to do with this here. https://lwn.net/Articles/933525/ Indeed. When gcc switched to GPLv3 llvm appeared. When Samba switched to GPLv3 Apple wrote their own and Linux grew the ksmbd in-kernel server. Three years ago Samba maintainer Jeremy Allison lamented that "Both GPLv3 and the AGPL have been rejected soundly by most developers" and talked about how he regretted the move and the damage it had done to the project, https://archive.org/details/copyleftconf2020-allison Can we please talk about the actual issue at and - that is not the license. That is the tests being broken on anything except amd64 and arm64. How long has the problem you're treating as a crisis been brewing? Far too long, as I said it was swept under the carpet for too long. Regards, Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi, Am 18.06.23 um 21:28 schrieb Rob Landley: Of course I mean "getting those architectures removed from unstable" *for libreoffice*. This is the same GPLv3 package that Red Hat just dropped support for? GPLv3 doesn't have anything to do with this here. https://lwn.net/Articles/933525/ Indeed. When gcc switched to GPLv3 llvm appeared. When Samba switched to GPLv3 Apple wrote their own and Linux grew the ksmbd in-kernel server. Three years ago Samba maintainer Jeremy Allison lamented that "Both GPLv3 and the AGPL have been rejected soundly by most developers" and talked about how he regretted the move and the damage it had done to the project, https://archive.org/details/copyleftconf2020-allison Can we please talk about the actual issue at and - that is not the license. That is the tests being broken on anything except amd64 and arm64. How long has the problem you're treating as a crisis been brewing? Far too long, as I said it was swept under the carpet for too long. Regards, Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi, Am 18.06.23 um 21:28 schrieb Rob Landley: Of course I mean "getting those architectures removed from unstable" *for libreoffice*. This is the same GPLv3 package that Red Hat just dropped support for? GPLv3 doesn't have anything to do with this here. https://lwn.net/Articles/933525/ Indeed. When gcc switched to GPLv3 llvm appeared. When Samba switched to GPLv3 Apple wrote their own and Linux grew the ksmbd in-kernel server. Three years ago Samba maintainer Jeremy Allison lamented that "Both GPLv3 and the AGPL have been rejected soundly by most developers" and talked about how he regretted the move and the damage it had done to the project, https://archive.org/details/copyleftconf2020-allison Can we please talk about the actual issue at and - that is not the license. That is the tests being broken on anything except amd64 and arm64. How long has the problem you're treating as a crisis been brewing? Far too long, as I said it was swept under the carpet for too long. Regards, Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi, Am 18.06.23 um 21:28 schrieb Rob Landley: Of course I mean "getting those architectures removed from unstable" *for libreoffice*. This is the same GPLv3 package that Red Hat just dropped support for? GPLv3 doesn't have anything to do with this here. https://lwn.net/Articles/933525/ Indeed. When gcc switched to GPLv3 llvm appeared. When Samba switched to GPLv3 Apple wrote their own and Linux grew the ksmbd in-kernel server. Three years ago Samba maintainer Jeremy Allison lamented that "Both GPLv3 and the AGPL have been rejected soundly by most developers" and talked about how he regretted the move and the damage it had done to the project, https://archive.org/details/copyleftconf2020-allison Can we please talk about the actual issue at and - that is not the license. That is the tests being broken on anything except amd64 and arm64. How long has the problem you're treating as a crisis been brewing? Far too long, as I said it was swept under the carpet for too long. Regards, Rene
Bug#1028132: now ready
Hi, hunspell-dict-ko was fixed/worked around the issue (0.7.94-1) so we can do this now. As said it's a no-op for anything except r-cran-hunspell which also is prepared in experimental together with hunspell itself. I might add a libhunspell-private-dev package later when I figured out how to best prevent this by adding a strict dependency there instead of hardcoding it... But even without that it's better to not have a copy of private headers in r-cran-hunspell. Can I upload to unstable? Regards, Rene
Bug#1028132: now ready
Hi, hunspell-dict-ko was fixed/worked around the issue (0.7.94-1) so we can do this now. As said it's a no-op for anything except r-cran-hunspell which also is prepared in experimental together with hunspell itself. I might add a libhunspell-private-dev package later when I figured out how to best prevent this by adding a strict dependency there instead of hardcoding it... But even without that it's better to not have a copy of private headers in r-cran-hunspell. Can I upload to unstable? Regards, Rene
Re: Getting hunspell 1.7.2 into unstable
Hi, Am 18.06.23 um 13:49 schrieb Changwoo Ryu: 2023년 6월 18일 (일) 오후 8:00, Rene Engelhard 님이 작성: Should I add a Breaks: hunspell-ko (<< 0.7.94) here? Strictly speaking it's not needed since it's a test failing not the dict being unusable, but we could go the "better safe than sorry" route anyways. No need. The problem still exists in hunspell-ko 0.7.94 but it's just ignored as it's not that important. Hmm.. OK. But thinking about it: Then we still would need to wait for hunspell to be uploaded to sid after hunspell-dict-ko migrated because otherwise the same autopkgtest would block on sid->testing (or just wait until it magically works out itself). Isn't it supposed to run the failed autopkgtest again, when hunspell-dict-ko gets migrated to testing? I'm not sure. Yeah, it's supposed to... Mind if I add it never Regards, -- Chan theless? At least also saves as documentation that there is "something". That's OK. It's your call. OK. Regards, Rene
Re: Getting hunspell 1.7.2 into unstable
Hi, Am 18.06.23 um 13:49 schrieb Changwoo Ryu: 2023년 6월 18일 (일) 오후 8:00, Rene Engelhard 님이 작성: Should I add a Breaks: hunspell-ko (<< 0.7.94) here? Strictly speaking it's not needed since it's a test failing not the dict being unusable, but we could go the "better safe than sorry" route anyways. No need. The problem still exists in hunspell-ko 0.7.94 but it's just ignored as it's not that important. Hmm.. OK. But thinking about it: Then we still would need to wait for hunspell to be uploaded to sid after hunspell-dict-ko migrated because otherwise the same autopkgtest would block on sid->testing (or just wait until it magically works out itself). Isn't it supposed to run the failed autopkgtest again, when hunspell-dict-ko gets migrated to testing? I'm not sure. Yeah, it's supposed to... Mind if I add it never Regards, -- Chan theless? At least also saves as documentation that there is "something". That's OK. It's your call. OK. Regards, Rene
