Re: unbreaking LibreOffices tests on at least release architectures
On Jul 22 2023, Rene Engelhard wrote: > Hi, > > Am 22.07.23 um 16:09 schrieb Andreas Schwab: >> On Jul 22 2023, Rene Engelhard wrote: >> >>> Am 22.07.23 um 15:53 schrieb Andreas Schwab: On Jul 22 2023, Rene Engelhard wrote: > Does opensuse have some public git/$VCS? https://build.opensuse.org/package/live_build_log/openSUSE:Factory:RISCV/libreoffice/standard/riscv64 >>> Thanks... >>> >>> But maybe I am too blind. >>> >>> I don't see the actual spec + related files anywhere? >> See Overview: >> >> https://build.opensuse.org/package/show/openSUSE:Factory:RISCV/libreoffice > > Thanks. > > > I don't see anyone obvious there (except not running *any* test) there > offhand, though. I tried to enable the smoketest, but it fails even on x86-64: https://build.opensuse.org/project/show/home:Andreas_Schwab:riscv:libreoffice Since I don't know much about the libreoffice sources, I have just copied the %check section from an old revision of our libreoffice package. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: unbreaking LibreOffices tests on at least release architectures
On Sat, Jul 22, 2023 at 8:10 AM Rene Engelhard wrote: > > Am 22.07.23 um 14:02 schrieb Andreas Schwab: > > On Jun 18 2023, Rene Engelhard wrote: > > > >> For riscv64 I already pointed that out in the thread starting at > >> https://lists.debian.org/debian-riscv/2023/06/msg0.html, but for the > >> other architectures there is the mail now. riscv64 is different because > >> the failures are even more big than any other down below and it's actually > >> a new architecture anyway. > > Libreoffice is actually basically working on riscv64. > > Yes. _basically_. (Only with -O0 or maybe -Os as upstreams makefile > says, though) Be careful of -Os. I test one of my C++ libraries with it in the library's test suite. Based on unexplained crashes with -Os, I believe GCC produces bad code with -Os on occasion. I do not recommend using -Os in production based on my experience. Jeff
Re: unbreaking LibreOffices tests on at least release architectures
Hi, Am 22.07.23 um 16:09 schrieb Andreas Schwab: On Jul 22 2023, Rene Engelhard wrote: Am 22.07.23 um 15:53 schrieb Andreas Schwab: On Jul 22 2023, Rene Engelhard wrote: Does opensuse have some public git/$VCS? https://build.opensuse.org/package/live_build_log/openSUSE:Factory:RISCV/libreoffice/standard/riscv64 Thanks... But maybe I am too blind. I don't see the actual spec + related files anywhere? See Overview: https://build.opensuse.org/package/show/openSUSE:Factory:RISCV/libreoffice Thanks. I don't see anyone obvious there (except not running *any* test) there offhand, though. Even many system-libraries - as I do. Except maybe gcc 12 vs. gcc 13 which might affect the optimization breakage... Will have look some more, though. (And retry with gcc 13 which is default in Debian now, too) Regards, Rene
Re: unbreaking LibreOffices tests on at least release architectures
On Jul 22 2023, Rene Engelhard wrote: > Am 22.07.23 um 15:53 schrieb Andreas Schwab: >> On Jul 22 2023, Rene Engelhard wrote: >> >>> Does opensuse have some public git/$VCS? >> https://build.opensuse.org/package/live_build_log/openSUSE:Factory:RISCV/libreoffice/standard/riscv64 > > Thanks... > > But maybe I am too blind. > > I don't see the actual spec + related files anywhere? See Overview: https://build.opensuse.org/package/show/openSUSE:Factory:RISCV/libreoffice -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: unbreaking LibreOffices tests on at least release architectures
On Jul 22 2023, Rene Engelhard wrote: > Does opensuse have some public git/$VCS? https://build.opensuse.org/package/live_build_log/openSUSE:Factory:RISCV/libreoffice/standard/riscv64 > (Though I would more bet of some system evironment thingy) Perhaps it is a matter of using a good java. Have you tried java 19 or 20? -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: unbreaking LibreOffices tests on at least release architectures
Am 22.07.23 um 15:53 schrieb Andreas Schwab: On Jul 22 2023, Rene Engelhard wrote: Does opensuse have some public git/$VCS? https://build.opensuse.org/package/live_build_log/openSUSE:Factory:RISCV/libreoffice/standard/riscv64 Thanks... But maybe I am too blind. I don't see the actual spec + related files anywhere? Repositories isn't it either, it just gives me (src)rpms. I could look there, but... (Though I would more bet of some system evironment thingy) Perhaps it is a matter of using a good java. Have you tried java 19 or 20? No, 17 only. The test extension in the smoketest indeed is Java, but given this also affects python extensions (lightproof) I'd bet it 's a general, non-Java issue. Even if Java was broken lightproof should have worked. Regards, Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi, Am 22.07.23 um 15:07 schrieb Andreas Schwab: Which gives the smoketest test failure here I pointed out (again) in my other mail. $ find /usr/lib64/libreoffice/ -name "*smoke*" /usr/lib64/libreoffice/program/classes/smoketest.jar How can I run that? You can't from that, ttbomk. You miss other files needed which are not ending up in the installation. You build it and run make subsequentcheck in smoketest (or a general make check). But you might need to build prereqs first, see https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/-/blob/master/rules#L2340 ff. Regards, Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi,
Am 22.07.23 um 15:02 schrieb Andreas Schwab:
On Jul 22 2023, Rene Engelhard wrote:
https://lists.debian.org/debian-riscv/2023/07/msg00014.html is for manual
thing. And the IRC log shows that even libreoffice-lightproof-en etc don't
appear as bundled extensions.
$ unopkg list --bundled
All deployed bundled extensions:
Identifier: org.openoffice.en.hunspell.dictionaries
Version: 2022.05.01
URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/lightproof-en
is registered: yes
Media-Type: application/vnd.sun.star.package-bundle
Description:
bundled Packages: {
URL:
vnd.sun.star.expand:$BUNDLED_EXTENSIONS/lightproof-en/Lightproof.components
is registered: yes
Media-Type: application/vnd.sun.star.uno-components
Description:
URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/lightproof-en/Linguistic.xcu
is registered: yes
Media-Type: application/vnd.sun.star.configuration-data
Description:
}
Interesting.
Now the question is what is different between openSUSEs libreoffice
package and Debians...
Does opensuse have some public git/$VCS?
(Though I would more bet of some system evironment thingy)
Regards,
Rene
Re: unbreaking LibreOffices tests on at least release architectures
On Jul 22 2023, Rene Engelhard wrote: > Hi, > > Am 22.07.23 um 14:28 schrieb Andreas Schwab: >> On Jul 22 2023, Rene Engelhard wrote: >> >>> Yes. _basically_. (Only with -O0 or maybe -Os as upstreams makefile says, >>> though) >> On openSUSE Factory, libreoffice is built with the usual compiler flags, >> wich includes full optimisation and hardening. > > Which gives the smoketest test failure here I pointed out (again) in my > other mail. $ find /usr/lib64/libreoffice/ -name "*smoke*" /usr/lib64/libreoffice/program/classes/smoketest.jar How can I run that? -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: unbreaking LibreOffices tests on at least release architectures
On Jul 22 2023, Rene Engelhard wrote:
> https://lists.debian.org/debian-riscv/2023/07/msg00014.html is for manual
> thing. And the IRC log shows that even libreoffice-lightproof-en etc don't
> appear as bundled extensions.
$ unopkg list --bundled
All deployed bundled extensions:
Identifier: org.openoffice.en.hunspell.dictionaries
Version: 2022.05.01
URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/lightproof-en
is registered: yes
Media-Type: application/vnd.sun.star.package-bundle
Description:
bundled Packages: {
URL:
vnd.sun.star.expand:$BUNDLED_EXTENSIONS/lightproof-en/Lightproof.components
is registered: yes
Media-Type: application/vnd.sun.star.uno-components
Description:
URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/lightproof-en/Linguistic.xcu
is registered: yes
Media-Type: application/vnd.sun.star.configuration-data
Description:
}
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Re: unbreaking LibreOffices tests on at least release architectures
On Jul 22 2023, Rene Engelhard wrote: > And that includes LibreOffice-bundled extensions like the > english,hungarian,russian grammar checker for example. Ot external finnish > spellchecking, hyphenation and grammer checking. Or turkish spellchecing. > > And those are extensions written in python which neither register when > registering manually nor when being installed as bundled extensions (see > the discussion in this thread, not going to reiterate) How can I test that? I have never used libreoffice before, so I don't know what to look for. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: unbreaking LibreOffices tests on at least release architectures
On Jul 22 2023, Rene Engelhard wrote: > Yes. _basically_. (Only with -O0 or maybe -Os as upstreams makefile says, > though) On openSUSE Factory, libreoffice is built with the usual compiler flags, wich includes full optimisation and hardening. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: unbreaking LibreOffices tests on at least release architectures
On Jul 22 2023, Rene Engelhard wrote: > Just not registering or unregistering *any* extension. What does that mean? I haven't seen any errors about extensions. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: unbreaking LibreOffices tests on at least release architectures
Hi, Am 22.07.23 um 14:34 schrieb Andreas Schwab: On Jul 22 2023, Rene Engelhard wrote: And that includes LibreOffice-bundled extensions like the english,hungarian,russian grammar checker for example. Ot external finnish spellchecking, hyphenation and grammer checking. Or turkish spellchecing. And those are extensions written in python which neither register when registering manually nor when being installed as bundled extensions (see the discussion in this thread, not going to reiterate) How can I test that? I have never used libreoffice before, so I don't know what to look for. https://lists.debian.org/debian-riscv/2023/07/msg00010.html https://lists.debian.org/debian-riscv/2023/07/msg00014.html (some of them says mips64el, but as said in my other replies, the smoketest failure is the same symptom there, just on riscv64 actual unopkg add does nothing effectively.) Regards, Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi, Am 22.07.23 um 14:28 schrieb Andreas Schwab: On Jul 22 2023, Rene Engelhard wrote: Yes. _basically_. (Only with -O0 or maybe -Os as upstreams makefile says, though) On openSUSE Factory, libreoffice is built with the usual compiler flags, wich includes full optimisation and hardening. Which gives the smoketest test failure here I pointed out (again) in my other mail. Regards. Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi, Am 22.07.23 um 14:25 schrieb Andreas Schwab: On Jul 22 2023, Rene Engelhard wrote: Just not registering or unregistering *any* extension. What does that mean? I haven't seen any errors about extensions. Do you run the testsuite? Especially the smoketest? And you are replying to exactly a thread which (later) talks about extensions being broken. So I wonder why you didn' t take the previous mails into account? https://lists.debian.org/debian-riscv/2023/07/msg00014.html is for manual thing. And the IRC log shows that even libreoffice-lightproof-en etc don't appear as bundled extensions. https://lists.debian.org/debian-riscv/2023/07/msg1.html is for the smoketest (that one's mips64el, but same symptom on riscv64) Regards, Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi, Am 22.07.23 um 14:09 schrieb Rene Engelhard: And that included packaged extensions so if they install but don't work that's a grave bug. And that includes LibreOffice-bundled extensions like the english,hungarian,russian grammar checker for example. Ot external finnish spellchecking, hyphenation and grammer checking. Or turkish spellchecing. And those are extensions written in python which neither register when registering manually nor when being installed as bundled extensions (see the discussion in this thread, not going to reiterate) (Whether one needs the NLPSolver or Wiki Publisher or so can definitely be discussed, though) Regards, Rene
Re: unbreaking LibreOffices tests on at least release architectures
On Jun 18 2023, Rene Engelhard wrote: > For riscv64 I already pointed that out in the thread starting at > https://lists.debian.org/debian-riscv/2023/06/msg0.html, but for the > other architectures there is the mail now. riscv64 is different because > the failures are even more big than any other down below and it's actually > a new architecture anyway. Libreoffice is actually basically working on riscv64. I have tested it with openSUSE Tumbleweed on BeagleV Beta and Hifive Unmatched (with an AMD graphics card). -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: unbreaking LibreOffices tests on at least release architectures
Hi, Am 22.07.23 um 14:02 schrieb Andreas Schwab: On Jun 18 2023, Rene Engelhard wrote: For riscv64 I already pointed that out in the thread starting at https://lists.debian.org/debian-riscv/2023/06/msg0.html, but for the other architectures there is the mail now. riscv64 is different because the failures are even more big than any other down below and it's actually a new architecture anyway. Libreoffice is actually basically working on riscv64. Yes. _basically_. (Only with -O0 or maybe -Os as upstreams makefile says, though) Which can be enough, but also can be not. I have tested it with openSUSE Tumbleweed on BeagleV Beta and Hifive Unmatched (with an AMD graphics card). Just not registering or unregistering *any* extension. Neither manually nor if installing any bundled extension. At least here. And that included packaged extensions so if they install but don't work that's a grave bug. Regards, Rene
Re: LibreOffice bridges/smoketest on mips(64)el (was: Re: unbreaking LibreOffices tests on at least release architectures)
On Mon, Jul 03, 2023 at 09:31:29PM +0200, Rene Engelhard wrote: > Hi, > > Am 25.06.23 um 13:37 schrieb Rene Engelhard: > > > 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) > > That was implemented (+ two more important tests) in experimental. See > https://buildd.debian.org/status/package.php?p=libreoffice > > It does > - bridgetest > - smoketest > - pyuno > > What fails for release archs astonishingly is only mips(64)el. It also failed on riscv64 (and powerpc), so that seems to be a criteria that catches the known-broken builds. >... > This test extension to be installed is a Java extension. > So I am running a nojava build on eller now... I don't really like disabling > Java since this opens Pandoras box but for mips64el we probably could do > that. It would also hint at a MIPS problem in LibreOffice, which might or might not be specific to Java. AFAIK OpenJDK on MIPS does not have any known major issues. The Zero build of OpenJDK on MIPS is of course slow, but that's also true on armel where the build succeeded. > Regards, > > Rene cu Adrian BTW: The MIPS-specific discussion should continue on debian-mips instead of debian-ports.
Re: LibreOffice bridges/smoketest on mips(64)el (was: Re: unbreaking LibreOffices tests on at least release architectures)
Hi, Am 03.07.23 um 21:31 schrieb Rene Engelhard: Am 25.06.23 um 13:37 schrieb Rene Engelhard: 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) That was implemented (+ two more important tests) in experimental. See https://buildd.debian.org/status/package.php?p=libreoffice https://buildd.debian.org/status/package.php?p=libreoffice=experimental of course. Regards, Rene
LibreOffice bridges/smoketest on mips(64)el (was: Re: unbreaking LibreOffices tests on at least release architectures)
Hi,
Am 25.06.23 um 13:37 schrieb Rene Engelhard:
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)
That was implemented (+ two more important tests) in experimental. See
https://buildd.debian.org/status/package.php?p=libreoffice
It does
- bridgetest
- smoketest
- pyuno
What fails for release archs astonishingly is only mips(64)el. Let's
continue on -mips...
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):
That said even the most important test fails. The bridgetest:
[build BIN] testtools
S=/PKGBUILDDIR I=$S/instdir
W=$S/workdir mkdir -p $W/Module/nonl10n/ touch
$W/Module/nonl10n/testtools
S=/PKGBUILDDIR I=$S/instdir
W=$S/workdir
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}$I/program:$I/program
$I/program/uno.bin -s com.sun.star.test.bridge.BridgeTest --
com.sun.star.test.bridge.CppTestObject
-env:LO_BUILD_LIB_DIR=file://$W/LinkTarget/Library
-env:URE_MORE_SERVICES=file://$W/Rdb/uno_services.rdb
-env:URE_MORE_TYPES=file://$W/UnoApiTarget/bridgetest.rdb
[build MOD] testtools
S=/PKGBUILDDIR I=$S/instdir
W=$S/workdir mkdir -p $W/Module/
touch $W/Module/testtools
### bool does not match! failed
### char does not match! failed
### byte does not match! failed
### short does not match! failed
### unsigned short does not match! failed
### long does not match! failed
### unsigned long does not match! failed
### hyper does not match! failed
### unsigned hyper does not match! failed
### enum does not match! failed
### byte2 does not match! failed
### short2 does not match! failed
struct comparison test failed
ppc-style alignment test failed
ppc64-style alignment test failed
### bool does not match! failed
### char does not match! failed
### byte does not match! failed
### short does not match! failed
### unsigned short does not match! failed
### long does not match! failed
### unsigned long does not match! failed
### hyper does not match! failed
### unsigned hyper does not match! failed
### enum does not match! failed
### byte2 does not match! failed
### short2 does not match! failed
recursive test results failed
remote multi failed: 11 != -1715038976
local multi failed: 11 != -1715038976
standard test failed
exception occurred: error: test failed! at
./testtools/source/bridgetest/bridgetest.cxx:1271
error: error: test failed! at
./testtools/source/bridgetest/bridgetest.cxx:1271
dying...make[3]: ***
[/PKGBUILDDIR/testtools/CustomTarget_uno_test.mk:25:
/PKGBUILDDIR/workdir/CustomTarget/testtools/uno_test.done]
Error 1
So the smoketest isn't even ran.
-> mipsel is fundamentally broken and libreoffice probably be removed
from it.
For mips64el I do have some hope as the failure is
[build CUT] smoketest
S=/PKGBUILDDIR 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_SYNCHRONOU
S_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/un
obootstrapprotector.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 )
21
[_RUN_] (anonymous namespace)::Test::test
(process:2108170): dconf-CRITICAL **: 05:13:49.716: unable to create
directory '/run/user/2952/dconf': Permission denied. dconf will not
work properly.
Fontconfig error: No writable cache directories
Fontconfig error: No writable cache directories
(process:2108244): dconf-CRITICAL **: 05:13:50.371: unable to create
directory '/run/user/2952/dconf': Permission denied. dconf will not
work properly.
Fontconfig error: No writable cache directories
Fontconfig
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(+0xb4534)[0x767b4534]
/home/rene/libreoffice-7.5.4/instdir/program/libsblo.so(+0xb5378)[0x767b5378]
Re: unbreaking LibreOffices tests on at least release architectures
On Tue, 2023-06-20 at 22:46 +0200, Kurt Roeckx wrote: > Can I suggest that if you file a few bugs and add some information in > it so that maybe someone can look at it? If it only affects one > architecture, send a mail to that list asking for help. PS: when filing architecture-specific bugs, please also set the BTS usertags and XCC the ports lists for the architectures effected. https://wiki.debian.org/Teams/Debbugs/ArchitectureTags -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: unbreaking LibreOffices tests on at least release architectures
Can I suggest that if you file a few bugs and add some information in it so that maybe someone can look at it? If it only affects one architecture, send a mail to that list asking for help. Kurt
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
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. > (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? > Fatal exception: Signal 11 It's a segfault, 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. > 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? > ./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? > 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? 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. Kurt
Re: unbreaking LibreOffices tests on at least release architectures
Stop sending these emails please! Sent from my iPhone > On 20 Jun 2023, at 09:42, Adrian Bunk wrote: > > 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, 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) > >> Regards, >> >> Rene > > cu > Adrian >
Re: unbreaking LibreOffices tests on at least release architectures
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, 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) > Regards, > > Rene cu Adrian
Re: unbreaking LibreOffices tests on at least release architectures
On Mon, Jun 19, 2023 at 11:50 PM Rene Engelhard wrote: > > 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... Yeah, there's a caveat: you have to have complete self tests. If the project lacks complete self tests, then you may not uncover the bug. You can run the program in production with a sanitizer build. It may uncover cases that were lacking in the test cases. And it's unfortunate some arches lack Asan and UBsan support. They are such powerful tools. Sometimes you can tease-out the UB on a different arch. Sometimes you can't. Jeff
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
On Mon, Jun 19, 2023 at 11:29:34PM +0200, Rene Engelhard wrote: >... > Am 19.06.23 um 23:19 schrieb Adrian Bunk: >... > > 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. Let's be realistic regarding the available options, because the one you want is not available. You want every !a*64 architecture to have a porter spending time on fixing libreoffice. And thinking this through, since regressions in new upstream versions are expected to be frequent you want new upstream versions of libreoffice blocked from testing migration by any regression on one architecture until a porter for this architecture has fixed the regression. A new architecture like riscv64 might have enough porters for fixing issues once or for some limited duration. That's it. For each architecture you have the options: 1. declare libreoffice good enough on this architecture, or 2. don't build libreoffice on this architecture There is no third option that architectures will provide porters fixing your package all the time. There are several other packages of comparable complexity, size and testsuite (e.g. mozjs* or rustc). For a successful build they are using either just a smoketest, or a maximum number of tolerable testsuite failures. > Regards, > > Rene cu Adrian
Re: unbreaking LibreOffices tests on at least release architectures
On Mon, Jun 19, 2023 at 5:30 PM Rene Engelhard wrote: > > 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. Related, bus errors are usually due to unaligned data accesses. Programmers casting from one type to another when when they shouldn't, like: typedef unsigned char byte; ... byte buffer[32]; readBuffer(buffer); double d = *(double *)buffer; That is undefined behavior because a byte buffer is a byte buffer, and it is not a double. That can result in a bus error on some platforms. You may get lucky and the byte buffer may be aligned for double. Or it may not be. In contrast, this would be Ok because the byte buffer is really a double object: typedef unsigned char byte; ... double d; byte* buffer = (bytes*) readBuffer(buffer); double dd = *(double *)buffer; 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. You don't need to be a porter to build and run with sanitizers. However, you do need an arch-specific machine. Or possibly a Debian chroot. Jeff
Re: unbreaking LibreOffices tests on at least release architectures
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. There are likely also build or debug tricks you know that a porter would not know. 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. On Mon, Jun 19, 2023 at 12:04:45AM +0200, Kurt Roeckx wrote: >... > Do you think Debian doesn't have any developers/porters anymore? >... For porters that's actually close to being true. There were times when porter numbers for a release architecture were numbers like 6 or 9. No release architecture in bookworm had more than 2 porters. No porters were required on amd64, the number of distinct people who are listed as porter for one or more of the 8 other bookworm release architecture is 5 DDs and 2 non-DDs. On Sun, Jun 18, 2023 at 09:31:05AM +0200, Rene Engelhard wrote: >... > For riscv64 I already pointed that out in the thread starting at > https://lists.debian.org/debian-riscv/2023/06/msg0.html, but for the > other architectures there is the mail now. riscv64 is different because > the failures are even more big than any other down below and it's actually a > new architecture anyway. > > Also note I am not talking about the debian-ports architectures. Those I > forgot and I have no problems making them stay into "testsuite ran but > results ignored" set. > > Right now, the only architectures where the test actually work (ignoring the > occassional breakage on arm64 which is fixed upstream since they do > aarch64 flatpak builds) is amd64 and arm64. > > With various different 32-bit, endian and whatever else breakage > ppopping up the other architectures constantly were moved in the set > where the testsuite was run but the results were ignored. For s390x, > where the macros tests hangs it even was in the set where the tests even > were not ran, since a hang then also ends up in > "E: Build killed with signal TERM after 150 minutes of inactivity". > > This was sweeping under the carpet for sure, but this was needed due to > it being a release architecture :( >... For such a complex package I would expect 32bit breakage in every release if upstream no longer tests on 32bit. The pragmatic option would be to run only a smoketest for build success on architectures not tested by upstream. cu Adrian
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
On Sunday 2023-06-18 23:37, Rob Landley wrote: >On 6/18/23 14:58, Rene Engelhard wrote: >>> 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. > >The issue is the number of developers engaging with this package have declined >to the point problems have gone unnoticed and unfixed for a long time. That may be a general problem not specific to Libreoffice, or any one particular project. As software grows to accomodate more features, it reaches a size where it is "good enough" for users that they no longer feel a need to invest time anymore as their needs are already satisfied, while at the same time, it has become so large for others to not want to touch it anymore. Chromium sucks to touch. On the other hand, the Linux kernel has evermore developers each round, and Linux distros have more packages than ever before. So not all seems to be bad? Modularization seems key, and that may just be what separates projects.
Re: unbreaking LibreOffices tests on at least release architectures
On 6/18/23 15:19, Rene Engelhard wrote: > Besides that it would also have been clear from actually reading the IRC > log which incidentially also says Good to know what the expectations for participation are. >> 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. I paid close attention to the project's launch back in the day. Back when LibreOffice forked away Oratroll's acquisition of Sun in 2010, they used (L)GPLv3 to prevent OpenOffice from merging their changes. Then OpenOffice got unloaded on apache.org after the fact, and it all got weirdly political. Then Google bought Writely and did google docs which could edit and save a word file which scooped up most of the userbase, and LibreOffice decided it should also run in a web browser... https://lwn.net/Articles/637830/ I know they regretted their GPLv3 stance early on, and were talking about NEW code being in a different license: https://lwn.net/Articles/498898/ But last I'd heard, while Apache's version had audited to relicense LibreOffice had not yet done a full audit: https://lwn.net/Articles/927096/ *shrug* I acknowledge I'm out of date here. If you say they're not v3 anymore, good for them. Seems I'm not the only one who hadn't heard about it, though. The last couple cubicle farms I consulted at still had LibreOffice on their "not allowed" lists, but the most recent of those was 2021 so that's old news. I only spoke up on the perception you were advocating for the removal of architectures I care about. Glad to hear that's not the case. Back to lurking... Rob
Re: unbreaking LibreOffices tests on at least release architectures
On June 18, 2023 11:37:55 PM GMT+02:00, Rob Landley wrote: >On 6/18/23 14:58, Rene Engelhard wrote: >>> 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. > >The issue is the number of developers engaging with this package have declined >to the point problems have gone unnoticed and unfixed for a long time. > >>> How long has the problem you're treating as a crisis been brewing? >> >> Far too long, as I said it was swept under I have a hard time understanding what you're trying to say. Do you think Debian doesn't have any developers/porters anymore? Or maybe that they're not actually using it for a desktop, and so the package isn't actually useful to anybody? Kurt
Re: unbreaking LibreOffices tests on at least release architectures
On 6/18/23 14:58, Rene Engelhard wrote: >> 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. The issue is the number of developers engaging with this package have declined to the point problems have gone unnoticed and unfixed for a long time. >> 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. Because the developers went away. Rob
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
On 6/18/23 03:45, Rene Engelhard wrote:> Am 18.06.23 um 10:32 schrieb Rene Engelhard: I don't really like sweeping it under the carpet again and would actually pursue the "getting those architectures removed from unstable" way pointed out and (implicitely) approved/suggested by the release team... >>> You want Debian to drop support for all architectures except amd64 and >>> arm64 >>> because a single package doesn't pass its testsuite on the other >>> architectures? >> >> If the "porters" of those architectures don't care about the tests, yes, >> this would be the ultimate result. >> >> And as the release team agrees with me... > > Well, actually I was too tired still. But the tone from my initial mail > was quite clear. I know you WANT to misread that and I fell into that trap No, that's how I read it too. You said getting the _architectures_ removed, not getting libreoffice removed from those architectures. > 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? https://lwn.net/Articles/933525/ 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 How long has the problem you're treating as a crisis been brewing? Rob
Re: unbreaking LibreOffices tests on at least release architectures
> Le 18 juin 2023 à 13:37, Steve McIntyre a écrit : > > On Sun, Jun 18, 2023 at 10:32:55AM +0200, Rene Engelhard wrote: >> Hi, >> >>> Am 18.06.23 um 10:19 schrieb John Paul Adrian Glaubitz: >>> On Sun, 2023-06-18 at 09:31 +0200, Rene Engelhard wrote: Also note I am not talking about the debian-ports architectures. Those I forgot and I have no problems making them stay into "testsuite ran but results ignored" set. >>> Why did you send this mail exclusively to debian-ports then? >> >> I (obviously) wrongly assumed that this was the magic address which >> duplicates to every port. >> >> Must have misremembered. > > It still does - I got this copy via the debian-arm list... > > -- > Steve McIntyre, Cambridge, UK.st...@einval.com > "This dress doesn't reverse." -- Alden Spiess > Same for me, I received it through the Debian-ppc list -someone
Re: unbreaking LibreOffices tests on at least release architectures
On Sun, Jun 18, 2023 at 10:32:55AM +0200, Rene Engelhard wrote: >Hi, > >Am 18.06.23 um 10:19 schrieb John Paul Adrian Glaubitz: >> On Sun, 2023-06-18 at 09:31 +0200, Rene Engelhard wrote: >> > Also note I am not talking about the debian-ports architectures. Those I >> > forgot and I have no problems making them stay into "testsuite ran but >> > results ignored" set. >> Why did you send this mail exclusively to debian-ports then? > >I (obviously) wrongly assumed that this was the magic address which >duplicates to every port. > >Must have misremembered. It still does - I got this copy via the debian-arm list... -- Steve McIntyre, Cambridge, UK.st...@einval.com "This dress doesn't reverse." -- Alden Spiess
Re: unbreaking LibreOffices tests on at least release architectures
Hi again. Am 18.06.23 um 10:32 schrieb Rene Engelhard: I don't really like sweeping it under the carpet again and would actually pursue the "getting those architectures removed from unstable" way pointed out and (implicitely) approved/suggested by the release team... You want Debian to drop support for all architectures except amd64 and arm64 because a single package doesn't pass its testsuite on the other architectures? If the "porters" of those architectures don't care about the tests, yes, this would be the ultimate result. And as the release team agrees with me... Well, actually I was too tired still. But the tone from my initial mail was quite clear. I know you WANT to misread that and I fell into that trap Of course I mean "getting those architectures removed from unstable" *for libreoffice*. (which again should be obvious), not removing those architectures from unstable alltogether. Regards, Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hi, Am 18.06.23 um 10:19 schrieb John Paul Adrian Glaubitz: On Sun, 2023-06-18 at 09:31 +0200, Rene Engelhard wrote: Also note I am not talking about the debian-ports architectures. Those I forgot and I have no problems making them stay into "testsuite ran but results ignored" set. Why did you send this mail exclusively to debian-ports then? I (obviously) wrongly assumed that this was the magic address which duplicates to every port. Must have misremembered. Right now, the only architectures where the test actually work (ignoring the occassional breakage on arm64 which is fixed upstream since they do aarch64 flatpak builds) is amd64 and arm64. (...) I don't really like sweeping it under the carpet again and would actually pursue the "getting those architectures removed from unstable" way pointed out and (implicitely) approved/suggested by the release team... You want Debian to drop support for all architectures except amd64 and arm64 because a single package doesn't pass its testsuite on the other architectures? If the "porters" of those architectures don't care about the tests, yes, this would be the ultimate result. And as the release team agrees with me... Regards, Rene
Re: unbreaking LibreOffices tests on at least release architectures
Hello! On Sun, 2023-06-18 at 09:31 +0200, Rene Engelhard wrote: > Also note I am not talking about the debian-ports architectures. Those I > forgot and I have no problems making them stay into "testsuite ran but > results ignored" set. Why did you send this mail exclusively to debian-ports then? > Right now, the only architectures where the test actually work (ignoring > the occassional breakage on arm64 which is fixed upstream since they do > aarch64 flatpak builds) is amd64 and arm64. > (...) > I don't really like sweeping it under the carpet again and would > actually pursue the "getting those architectures removed from unstable" > way pointed out and (implicitely) approved/suggested by the release team... You want Debian to drop support for all architectures except amd64 and arm64 because a single package doesn't pass its testsuite on the other architectures? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
