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
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
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
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
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
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
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
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
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
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
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
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
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
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 qual
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
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
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
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/
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 Debi
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
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
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
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 kfree
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)
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
>
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
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
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
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
[ 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()
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
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:
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
[ -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
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
35 matches
Mail list logo
