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
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
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
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)
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
Fontcon
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 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 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 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 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 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
unbreaking LibreOffices tests on at least release architectures
Hi, I originally wanted to send the mail after all the architectures got result but now even after 6d mips64el didn't try it so I send it now. Prompted by riscv64 supposed to be added to the archive and even as a release arch for trixie - see https://lists.debian.org/debian-devel-announce/2023/06/msg1.html - I looked at the libreoffice tests and thought was quite miserable). Which prompted a discussion in #debian-release, too - see [1]. Since the that upload its tests (expectedly) fail: https://buildd.debian.org/status/package.php?p=libreoffice (which is expected, yee below) 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 :( Can the porters please have a look at libreoffice in their favourite port(s) and fix it? I won't be of much help here unfortunately, except maybe testing patches, but then again there's porterboxes (though to limited space there one needs to apply some space-saving hacks like -g1 or no -g or disable -nogui and whatever). 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... Regards, Rene [1] 17:18 < _rene_> elbrus: uargs, could that riscv64 thingy be announced with a message that porters actually have to care about their port then? 17:18 < elbrus> jmw: I'm amazed at what you're able to comment on today; thanks for your help 17:18 < elbrus> _rene_: please elaborate? 17:19 < _rene_> elbrus: (which is not the case for "let's port, we know the test breaks miserably, but let's fix that later)" 17:19 < _rene_> where later is probably "never" 17:19 < _rene_> (as for libreoffice and riscv64) 17:20 < elbrus> if the test breaks your build, your package doesn't build on the architecture and you might not care until a porter fixes it? 17:20 < _rene_> test results are ignored (for now). 17:20 < elbrus> only on that arch? 17:21 < elbrus> why not let it fail the build? 17:21 < _rene_> if I would do that (which would be correct) I would also loose s390x, mips*, ... 17:21 < elbrus> until the test is fixed? 17:21 < elbrus> yes, and...? 17:21 < _rene_> been there, done that, no porter actions 17:21 < elbrus> you're only trouble is that for those archs you'd need to remove existing binaries 17:22 < elbrus> for a *new* architecture, if you never build in the official archive, there's nothing "broken" 17:22 < elbrus> it's not a bad thing if you package FTBFS always on an architecture 17:22 < elbrus> as long as it never passes to buidl 17:22 < elbrus> build 17:23 < elbrus> arch:all needs to build on amd64 though 17:23 < _rene_> sure 17:23 < _rene_> the other archs where the tests are fatal right now is amd64 and arm64 :) 17:23 < _rene_> s/other/only/ 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 17:25 < smcv> next best thing would be make them fatal everywhere except selected known-bad architectures where the failures are known not to be a big deal 17:25 < smcv> (we do that in gnome sometimes) 17:25 < elbrus> that's close to what I mean 17:26 < _rene_> 17:25 < elbrus> extreme case you only ship on amd64 and arm64 17:26 < _rene_> that's what would be the outcome, yes 17:26 < elbrus> point being, with my Release Team member hat on here, I want porters to be more active in fixing architecture specific issues 17:26 < smcv> so, pseudocode: if ! tests-passed && arch not in (mipsel, s390x, armhf): ftbfs 17:26 < _rene_> even i386 and armhf would be at risk then 17:27 < elbrus> fine with me 17:27 < smcv> if libreoffice doesn't work on those archs then those archs can ship without libreoffice 17:27 <@jmw> looks like we are within striking of image testing; all live stuff is in progress, 2/5
LibreOffice architecture support (was: Fwd: Plan to remove dead C++ UNO bridge implementations (bridges/source/cpp_uno/*))
Hi, I am not giung to fight for this - so if you want to keep - alpha - hppa - ia64 - m68k - powerpc and powerpcspe - sparc and sparc64 (which are for many BD-Uninstallable since ages because it does not have Java (anymore), didn't do a long-ago transition, ...) speak up at upstream or they will be gone. And without those bridges no architecture support for it. Note that riscv64 would already be there if ftpmaster allowed the experimental upload out of NEW (there since November.) Regards. Rene Weitergeleitete Nachricht Betreff: Plan to remove dead C++ UNO bridge implementations (bridges/source/cpp_uno/*) Datum: Tue, 10 Jan 2023 17:31:12 +0100 Von:Stephan Bergmann An: libreoff...@lists.freedesktop.org Kopie (CC): Sakura286 , wjh-la , Rene Engelhard , Tor Lillqvist There are currently 27 different, per-platform C++ UNO bridge implementations at bridges/source/cpp_uno/, some of which are presumably dead by now. And my recent <https://git.libreoffice.org/core/+/ef533553559fe09b4afab651fc692885d1acf4ed%5E!/> "Rudimentary support for dynamic_cast on UNO proxy objects" (which had to touch each of them individually) was the latest example how even presumably dead ones have ongoing maintenance cost. Therefore, I would like to remove (on master, towards LO 7.6) the ones that can clearly be identified as being dead. Below, I sorted those 27 implementations into 5 categories: Ideally, each active implementation would be built regularly by Jenkins; those 9 that are go into category 1. Next, there are 2 additional implementations that I know are built for Fedora releases; they go into category 2. Next, there are 2 additional implementations that I presume are built for Debian releases (Rene, correct me if I'm wrong); they go into category 3. And then there are 3 implementations that are presumably in active use elsewhere (Tor, wjh-la, Sakura286, correct me if I'm wrong); which go into category 4. That leaves 11 implementations that are presumably dead, in category 5. So if you know about any active use of any of those 11 implementations in category 5 below, please report back here. Otherwise, the plan (to be discussed in the ESC) is to eventually remove them in due course. (1) Built regularly by some <https://ci.libreoffice.org/> configuration: * gcc3_linux_aarch64 (also for macOS) <https://ci.libreoffice.org/job/gerrit_android_aarch64/>, <https://ci.libreoffice.org/job/lo_daily_tb_mac_arm64/> * gcc3_linux_arm <https://ci.libreoffice.org/job/gerrit_android_arm/> * gcc3_linux_intel <https://ci.libreoffice.org/job/gerrit_android_x86/> * gcc3_linux_x86-64 <https://ci.libreoffice.org/job/lo_daily_tb_linux/> * gcc3_macosx_x86-64 <https://ci.libreoffice.org/job/lo_daily_tb_mac/> * gcc3_wasm <https://ci.libreoffice.org/job/lo_daily_tb_linux_wasm/> * msvc_win32_arm64 <https://ci.libreoffice.org/job/lo_daily_tb_win_arm64/> * msvc_win32_intel <https://ci.libreoffice.org/job/lo_tb_master_win/> * msvc_win32_x86-64 <https://ci.libreoffice.org/job/lo_daily_tb_win/> (2) Release builds for Fedora (e.g., <https://koji.fedoraproject.org/koji/buildinfo?buildID=2105337>): * gcc3_linux_powerpc64 * gcc3_linux_s390x (3) Presumably release builds for Debian (per architectures at <https://cdimage.debian.org/debian-cd/current/>): * gcc3_linux_mips * gcc3_linux_mips64 (4) Presumably somewhat actively maintained: * gcc3_ios * gcc3_linux_loongarch64 only added recently in 2022 with <https://git.libreoffice.org/core/+/d3625d968901eb93a9680db8d1165f70de3fd64e%5E!/> "Add loongarch64 support." * gcc3_linux_riscv64 only added recently in 2022 with <https://git.libreoffice.org/core/+/bc9487f745befde6534fd46058e119256952323d%5E!/> "Add riscv64 support" (5) Presumably dead: * gcc3_aix_powerpc * gcc3_linux_alpha * gcc3_linux_hppa * gcc3_linux_ia64 * gcc3_linux_m68k * gcc3_linux_powerpc * gcc3_linux_s390 * gcc3_linux_sparc * gcc3_linux_sparc64 * gcc3_solaris_intel * gcc3_solaris_sparc
Re: Bug#801865: libreoffice: FTBFS[kfreebsd-*]; tests hang in sw_macros_test with FreeBSD 10
Hi, On Sat, Oct 17, 2015 at 01:42:49PM +0100, Steven Chamberlain wrote: > Rene Engelhard wrote: > > This is weird btw, given it has exactly the same thing on falla. And also > > even with gcj-5-jre removed. > > In an out-of-date sid chroot, with latest openjdk-7, on kfreebsd-9 kernel; > I can run the sw_macros_test 100 times without reproducing it. > > Then I built in a clean, up-to-date sid chroot on another machine, with > kfreebsd-10 kernel, and reproduced it the first time, during package > build. This is good, from here I can start to eliminate the variables > and try again. Is there any progress here. I get various "complaints" that the ood kfreebsd binaries block (auto-)decruftingof old binaries since kfreebsd-* is "properly" in unstable. Or do I have to hide the problem by just disabling the tests on kfreebsd-*? (They should already be non-fatal, but that doesn't help on hangs and a kill because of timeout.) Regards, Rene
Re: Bug#801865: libreoffice: FTBFS[kfreebsd-*]; still uses gcj?
Hi, On Thu, Oct 15, 2015 at 11:14:48PM +0100, Steven Chamberlain wrote: > I deliberately use an out-of-date chroot as I'm trying to find what > caused a regression, trying to rule out some build-depends first. I am not sure that test failure actually is a regression. on gcj builds (as bafore) those tests are not ran... That it now doesn't build anymore of course is.. Regards, Rene
Re: Bug#801865: libreoffice: FTBFS[kfreebsd-*]; still uses gcj?
Hi, On Thu, Oct 15, 2015 at 11:29:42PM +0100, Steven Chamberlain wrote: > But in the Debian build logs you can see it - it definitely > seems wrong to alter debian/control during a normal build? > > During the initial debian/rules clean: > > | /usr/bin/make -f debian/rules control > https://buildd.debian.org/status/fetch.php?pkg=libreoffice=kfreebsd-amd64=1%3A5.0.3~rc1-1=1444715604 Hmm, indeed... But that shouldn't affect how it's built... It would "just" miss some binary packages/features if it affected it, but nothing affected the Writer macro tests ttbomk. And he buildlog says: checking the installed JDK... checked (JDK 1.7.0_85) checking for JAWT lib... -L/usr/lib/jvm/default-java/jre/lib/amd64 -ljawt so... Regards, Rene
Re: [Openjdk] default-jdk change on kfreebsd
Hi,
On Sat, Aug 17, 2013 at 08:38:09PM +0200, Damien Raude-Morvan wrote:
Le samedi 17 août 2013 16:21:06 Christoph Egger a écrit :
I've been talking with Julien from the release team and Damien, the
openjdk maintainer here at DebConf.
Switching could -- as far as I understand -- work as follows:
* Make openjdk-7 default. No other actions needed and should work for a
start
FTR, I've prepared an update of default-java (from java-common package) to
openjdk-7 on kfreebsd-{i386,amd64}. I'm just waiting for OK from release team
before upload.
Is there a ETA for the switch?
I switched LO 4.1.0-5 already to openjdk-7 on kfreebsd-* to get rid of the
last gcj usage there. (hardcoded openjdk there.)
In the 4.1.1 (4.1.1 to be released next week) branch the current modus
operandi is to use default, so without a new java-common this actually would
a) be BD-Uninstallable (but it's experimental-only for now, so whatever)
b) cause a regression and removes some packages built on kfrfeebsd-* since
said 4.1.0-5 again
(See
http://anonscm.debian.org/gitweb/?p=pkg-openoffice/libreoffice.git;a=commitdiff;h=71f46c63189ce0a2e75161775b1c5f1242d996db;hp=74712d40712e666e888dc7d779603798e018f37e)
Regards,
Rene
--
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130822094156.gi32...@rene-engelhard.de
Re: [Openjdk] default-jdk change on kfreebsd
Hi, On Thu, Aug 22, 2013 at 12:14:21PM +0200, Julien Cristau wrote: I have no idea what the implications of the switch are for us. I didn't realy understand completely either why but I think they want a OK from the RT because stuff assuming gcj on kfreebsd might break if that is changed to openjdk. And I think they eventually want a rebuild after the switch with openjdk. Regards, Rene -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130822110729.gj32...@rene-engelhard.de
Re: Java defaults for kfreebsd-amd64
On Wed, Jun 19, 2013 at 10:41:18AM +0100, Steven Chamberlain wrote: There are some curious mentions of gcj also in the failed build log. Which are totally irrelevant for the thing here. You should trust the person who fought with this crap since 11 years. basename: missing operand Try `basename --help' for more information. dpkg-query: no path found matching pattern /usr/lib/x86_64-kfreebsd-gnu/gcj--*/libgcj_bc.so.1 dpkg-query: error: --listfiles needs at least one package name argument Needed (only and thus failing on non-gcj builds because that package is not installed) to get the path. Nothing to worry here. export PATH=/«PKGBUILDDIR»/debian/usr/bin:/usr/lib/jvm/java-gcj/bin:$PATH; \ This might be fishy but it's there for a reason in gcj builds afair (actually don't remember why, maybe it even can be removed), BUT the build DOES NOT call java but $with_jdk_home/bin/java so this PATH setting is not relevant for this failure either. I'd actually bet that if I removed the PATH setting it would still fail on the kfreebsd-amd64 porterbox as it did on the buildd (yes, I tried actually I saw that failure mode *before* I uploaded and hoped it would be just a local problem - as it was with mips(el) and openjdk-6 ) Can we get on-topic again, please? Regards, Rene -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130619095728.gb16...@rene-engelhard.de
Re: Bug#675834: hsqldb: FTBFS: The import java.sql.SQLFeatureNotSupportedException cannot be resolved
Hi, On Thu, Jul 12, 2012 at 01:31:36PM +0200, Lionel Elie Mamane wrote: It should, but is not, because the way the preprocessing was applied is buggy. See http://cgit.freedesktop.org/libreoffice/core/commit/?id=69273cdd675b205b6f47e9aab2872901c03be578 Ah, OK, thanks, will try to update the patch... Regards, Rene -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120712114727.gf2...@rene-engelhard.de
Re: Bug#675834: hsqldb: FTBFS: The import java.sql.SQLFeatureNotSupportedException cannot be resolved
[ Ccing Moritz and #675495 ]
Hi,
On Sun, Jun 03, 2012 at 05:44:59PM +0200, Christoph Egger wrote:
Your package failed to build on the kfreebsd-* buildds:
More: s/on the kfreebsd-* buildds/with gcj/
Interesting. This should be JAVA7 only:
+//#ifdef JAVA7
+public Logger getParentLogger() throws SQLFeatureNotSupportedException
+{
+throw new SQLFeatureNotSupportedException(Not supported yet.);
+}
+
+//#endif JAVA7
If you have further questions please mail debian-bsd@lists.debian.org
Yes, when is kFreeBSD getting a ported OpenJDK(7)?
I mean this upload just was a upload getting the fix from LibreOffice
over to hsqldb to fix build with JDK7 as the security team apparently
thinks getting rid of OpenJDK6 two weeks before the freeze/inside the freeze
is a good idea.
(This also means that LO 3.6+ and LO 3.5.4-1+ - which got the patch, too -
won't also build on kfreebsd-* if using the embedded hsqldb...)
But maybe we should just stop the native compilation, which makes this a pure
_all package and then it can build everywjere (and we can then ignore that this
is not building on gcj archs as noone seriously will build there for _all
packages)
Regards,
Rene
--
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120603160733.gl25...@rene-engelhard.de
Re: Bug#675834: hsqldb: FTBFS: The import java.sql.SQLFeatureNotSupportedException cannot be resolved
Hi, On Sun, Jun 03, 2012 at 06:46:00PM +0200, Christoph Egger wrote: But maybe we should just stop the native compilation, which makes this a pure _all package and then it can build everywjere (and we can then ignore that this is not building on gcj archs as noone seriously will build there for _all packages) If that will work for you I'm fine with it. Well, it works, but I don't like it. As it slows down the Java stuff on kfreebsd-* much. (I originally also wanted to reenable libreoffice-gcj when gcc-defaults get sorted out for the same reson) :( Regards, Rene -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120603210501.ga4...@rene-engelhard.de
Re: sys/mount.h not C++ clean on kfreebsd
Hi, On Sat, Feb 25, 2012 at 12:21:33PM +, peter green wrote: Compiling: sal/osl/unx/file_volume.cxx In file included from /build/buildd-libreoffice_3.4.5-3-kfreebsd-amd64-ukEv52/libreoffice-3.4.5/libreoffice-build/build/libreoffice-3.4.5.2/sal/osl/unx/file_volume.cxx:77:0: /usr/include/x86_64-kfreebsd-gnu/sys/mount.h: In function 'int getvfsbyname(const char*, xvfsconf*)': /usr/include/x86_64-kfreebsd-gnu/sys/mount.h:398:23: error: invalid conversion from 'void*' to 'xvfsconf*' [-fpermissive] Already pointed out on http://lists.debian.org/debian-bsd/2012/02/msg00061.html see also http://lists.debian.org/debian-bsd/2012/02/msg00080.html And aurel32 promised that upload for this weekend :) I would file a bug report but packages.debian.org doesn't seem to want to tell me what package sys/mount.h is in. libc0.1-dev Regards, Rene -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120225125603.gf17...@rene-engelhard.de
ant and environment variables broken on kFreeBSD?
Hi,
libreoffice 3.3.3-1 fails to build on kfreebsd-* with the following
(see
https://buildd.debian.org/status/fetch.php?pkg=libreofficearch=kfreebsd-amd64ver=1%3A3.3.3-1stamp=1308240320
and
https://buildd.debian.org/status/fetch.php?pkg=libreofficearch=kfreebsd-i386ver=1%3A3.3.3-1stamp=1308246204,
searc
for swing-ex:
--- snip ---
get-swing-ex:
BUILD FAILED
/build/buildd-libreoffice_3.3.3-1-kfreebsd-amd64-091elA/libreoffice-3.3.3/libreoffice-build/build/libreoffice-3.3.3.1/rhino/unxkfgx6.pro/misc/build/rhino1_5R5/build.xml:51:
The following error occurred while executing this line:
/build/buildd-libreoffice_3.3.3-1-kfreebsd-amd64-091elA/libreoffice-3.3.3/libreoffice-build/build/libreoffice-3.3.3.1/rhino/unxkfgx6.pro/misc/build/rhino1_5R5/toolsrc/build.xml:43:
src
'/build/buildd-libreoffice_3.3.3-1-kfreebsd-amd64-091elA/libreoffice-3.3.3/libreoffice-build/build/libreoffice-3.3.3.1/rhino/unxkfgx6.pro/misc/build/rhino1_5R5/toolsrc/${solenv.TARFILE_LOCATION}/35c94d2df8893241173de1d16b6034c0-swingExSrc.zip'
doesn't exist.
Total time: 5 seconds
dmake: Error code 1, while making
'./unxkfgx6.pro/misc/build/so_built_ooo_rhino'
--- snip ---
somehow it looks for /35c94d2df8893241173de1d16b6034c0-swingExSrc.zip in a
weird location. Compare this with Linux:
--- snip ---
get-swing-ex:
[unzip] Expanding:
/build/buildd-libreoffice_3.3.3-1-i386-DUALGN/libreoffice-3.3.3/ext-sources/35c94d2df8893241173de1d16b6034c0-swingExSrc.zip
into
/build/buildd-libreoffice_3.3.3-1-i386-DUALGN/libreoffice-3.3.3/libreoffice-build/build/libreoffice-3.3.3.1/rhino/unxlngi6.pro/misc/build/rhino1_5R5/toolsrc/org/mozilla/javascript/tools/debugger
--- snip ---
which is expected. $TARFILE_LOCATION is exported to source dir/ext-sources/
in debian/rules, and the build.xml is supposed to pick it up - which it doesn't
on kFreeBSD. Other (non-Java, non-inside ant) stuff fetch stuff from
$TARFILE_LOCATION just fine, so it seems to me that ant 1.8.2-2 doesn't
pass the envvar properly.
The last build before this uploaded worked fine:
https://buildd.debian.org/status/fetch.php?pkg=libreofficearch=kfreebsd-i386ver=1%3A3.3.2-4stamp=1304680853,
with ant 1.8.1-2...
Grüße/Regards,
René
--
.''`. René Engelhard -- Debian GNU/Linux Developer
: :' : http://www.debian.org | http://people.debian.org/~rene/
`. `' r...@debian.org | GnuPG-Key ID: D03E3E70
`- Fingerprint: E12D EA46 7506 70CF A960 801D 0AA0 4571 D03E 3E70
--
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110616191519.gc11...@rene-engelhard.de
ant and environment variables apparently broken with gcj (was: ant and environment variables broken on kFreeBSD?)
[ -bsd can be dropped I guess, but CC'ing now again to clean
thi sup, ad it's not BSD-specific ]
Hi,
On Thu, Jun 16, 2011 at 09:15:19PM +0200, Rene Engelhard wrote:
libreoffice 3.3.3-1 fails to build on kfreebsd-* with the following
(see
https://buildd.debian.org/status/fetch.php?pkg=libreofficearch=kfreebsd-amd64ver=1%3A3.3.3-1stamp=1308240320
and
https://buildd.debian.org/status/fetch.php?pkg=libreofficearch=kfreebsd-i386ver=1%3A3.3.3-1stamp=1308246204,
searc
for swing-ex:
--- snip ---
get-swing-ex:
BUILD FAILED
/build/buildd-libreoffice_3.3.3-1-kfreebsd-amd64-091elA/libreoffice-3.3.3/libreoffice-build/build/libreoffice-3.3.3.1/rhino/unxkfgx6.pro/misc/build/rhino1_5R5/build.xml:51:
The following error occurred while executing this line:
/build/buildd-libreoffice_3.3.3-1-kfreebsd-amd64-091elA/libreoffice-3.3.3/libreoffice-build/build/libreoffice-3.3.3.1/rhino/unxkfgx6.pro/misc/build/rhino1_5R5/toolsrc/build.xml:43:
src
'/build/buildd-libreoffice_3.3.3-1-kfreebsd-amd64-091elA/libreoffice-3.3.3/libreoffice-build/build/libreoffice-3.3.3.1/rhino/unxkfgx6.pro/misc/build/rhino1_5R5/toolsrc/${solenv.TARFILE_LOCATION}/35c94d2df8893241173de1d16b6034c0-swingExSrc.zip'
doesn't exist.
Total time: 5 seconds
dmake: Error code 1, while making
'./unxkfgx6.pro/misc/build/so_built_ooo_rhino'
--- snip ---
Which now happened also on ia64.
somehow it looks for /35c94d2df8893241173de1d16b6034c0-swingExSrc.zip in a
weird location. Compare this with Linux:
--- snip ---
get-swing-ex:
[unzip] Expanding:
/build/buildd-libreoffice_3.3.3-1-i386-DUALGN/libreoffice-3.3.3/ext-sources/35c94d2df8893241173de1d16b6034c0-swingExSrc.zip
into
/build/buildd-libreoffice_3.3.3-1-i386-DUALGN/libreoffice-3.3.3/libreoffice-build/build/libreoffice-3.3.3.1/rhino/unxlngi6.pro/misc/build/rhino1_5R5/toolsrc/org/mozilla/javascript/tools/debugger
--- snip ---
which is expected. $TARFILE_LOCATION is exported to source
dir/ext-sources/
in debian/rules, and the build.xml is supposed to pick it up - which it
doesn't
on kFreeBSD. Other (non-Java, non-inside ant) stuff fetch stuff from
s/on kfreeBSD/with gcj/
$TARFILE_LOCATION just fine, so it seems to me that ant 1.8.2-2 doesn't
pass the envvar properly.
The last build before this uploaded worked fine:
https://buildd.debian.org/status/fetch.php?pkg=libreofficearch=kfreebsd-i386ver=1%3A3.3.2-4stamp=1304680853,
with ant 1.8.1-2...
Seems it happens on all the archs where gcj is used for the build, this
should then affect those archs:
OOO_GCJ_JDK_ARCHS := hppa ia64 kfreebsd-i386 kfreebsd-amd64 mips mipsel
Grüße/Regards,
René
--
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110616193655.gd11...@rene-engelhard.de
Re: Bug#578023: openoffice.org on GNU/kFreeBSD
Hi, On Fri, Apr 16, 2010 at 11:16:47AM +0200, Petr Salinger wrote: The built packages are available at http://io.debian.net/~salinger/openoffice.org/ Please test them. [...] I added some more stuff you couldn't have known or seen which make it a bit better and upstreamable (I already created a hg branch upstream) Built a current version on io, it's at http://io.debian.net/~rene/openoffice.org/. Note that those packages (build-)depend on libc0.1 (= 2.10.2-7) in preparation for an upload with kFreeBSD enabled, so if you wanted to test it you either need a dummy package or use --force-depends for now. If you don't want that, maybe you want to try the upstream-like built packages at http://io.debian.net/~rene/kfreebsdport01v2/en-US/DEBS/ - BEWARE! 3.3 SNAPSHOT-based) (and then you need to set LD_LIBRARY_PATH accordingly, a export LD_LIBRARY_PATH=/usr/lib/ure/lib:/usr/lib/openoffice/basis3.2/program shoul do. I am not able to test the packages on io itself) Grüße/Regards, René -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' r...@debian.org | GnuPG-Key ID: D03E3E70 `- Fingerprint: E12D EA46 7506 70CF A960 801D 0AA0 4571 D03E 3E70 -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100420143225.gd25...@rene-engelhard.de
