Hi,
Am 28.07.24 um 18:38 schrieb Rene Engelhard:
see
https://buildd.debian.org/status/fetch.php?pkg=libreoffice&arch=armhf&ver=4%3A24.8.0~rc2-1&stamp=1722178361&raw=1:
build CXX] bridges/source/cpp_uno/gcc3_linux_arm/uno2cpp.cxx
S=/<> && I=$S/instdir &&
[ Ccing libreoffice upstream ]
Hi,
see
https://buildd.debian.org/status/fetch.php?pkg=libreoffice&arch=armhf&ver=4%3A24.8.0~rc2-1&stamp=1722178361&raw=1:
build CXX] bridges/source/cpp_uno/gcc3_linux_arm/uno2cpp.cxx
S=/<> && I=$S/instdir && W=$S/workdir && mkdir -p $W/CxxObject/bridges/source/
Hi,
Am 01.11.23 um 20:42 schrieb Rene Engelhard:
(The workaround would be --without-java which I verified to work on my
rpi4, but this opens a can of worms. Not only disabling some (built-in)
features like the Report Builder but especially since there is
Java-based extensions (_all!) which
Hi,
since LibreOffice 7.6 (which added some more tests which were manual
before to the automatic set) the testtools' bridge test fails:
https://buildd.debian.org/status/fetch.php?pkg=libreoffice&arch=armhf&ver=4%3A7.6.2-5&stamp=1698791231&raw=0
only on armhf. armel and arm64 just work.
it sa
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 a
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 o
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 --bu
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 replyi
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 spe
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 quality.
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
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 man
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 genera
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/
Inde
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
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
https://lists.debian.org/debian-devel-announce/2023/
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+
Hi,
On Fri, Nov 08, 2019 at 09:05:12AM +0100, Stephan Bergmann wrote:
> Ah. What I'd meant was something like
>
> > #if ...
> > using AtomicCounter = std::atomic>;
> > static_assert(AtomicCounter::is_always_lock_free);
> > #else
> > using AtomicCounter = volatile std::make_unsigned_t;
> > #endif
Hi,
On Thu, Nov 07, 2019 at 10:18:06AM +0100, Stephan Bergmann wrote:
> On 06/11/2019 18:39, Rene Engelhard wrote:
> > Given the introduced AtomicCounter is used later, too I tried the simplified
> >
> > diff --git a/vcl/inc/opengl/zone.hxx b/vcl/inc/opengl/zone.hxx
&
Hi,
On Wed, Nov 06, 2019 at 09:26:53AM +0100, Stephan Bergmann wrote:
> > +// gnEnterCount and gnLeaveCount are accessed both from multiple
> > threads (cf.
> > +// OpenGLWatchdogThread::execute; so need to be of atomic type) and
> > from signal handlers (cf.
> > +// VCLExceptionSign
Hi,
Am 6. November 2019 09:26:53 MEZ schrieb Stephan Bergmann :
>don't make things worse than they originally were if we fall back to
>that type again on armel. So if the original code happened to work
>well
>enough on armel in practice
It built. No more data ;-)
, you could add an appropriat
Hi,
LibreOffice 6.4.0 alpha1 was just accepted into Debian experimental and failed
on armel
(old arm gnueabi):
In file included from /<>/vcl/source/app/svmain.cxx:90:
/<>/vcl/inc/opengl/zone.hxx:39:34: error: static assertion failed
39 | static_assert(AtomicCounter::is_always_lock_free);
Hi,
On Fri, Sep 05, 2014 at 03:06:03AM +0200, Rene Engelhard wrote:
> Verified to build with gcc 4.8 and workarounds for the above on changsha.
Ignore the gcc 4.8 bit, was needed until it got properly fixed and I forgot
to edit it out when sending. Works also with gcc 4.9 now.
Regards,
R
Hi,
On Sun, Aug 10, 2014 at 02:22:29AM +0100, Wookey wrote:
> Libreoffice needs major porting work (in their equivalent of
> libffi). That will get done, but is not a priority for anyone yet. (It
So, during DebConf RH finished their port and I've been able to backport
it[1]
The archive misses so
Hi,
On Mon, Jul 28, 2014 at 09:15:03AM +0100, Neil Williams wrote:
> > > arm32 (and ABI-specific, calling conventions, etc.) code to also
> > > work with amd64.
> > [...]
> > > See apt-get source libreoffice,
> > > bridges/source/cpp_uno/gcc3_linux_arm.
> >
> > Given arm64 probably won't be in je
On Mon, Jul 28, 2014 at 08:07:57AM +0200, Rene Engelhard wrote:
> And I would actually be surprised it would work without porting the arm32
> (and ABI-specific, calling conventions, etc.) code to also work with amd64.
[...]
> See apt-get source libreoffice, bridges/source/cpp_uno/gcc3_
Hi,
On Sat, Jul 19, 2014 at 07:59:11PM +0100, peter green wrote:
> gnome: in addition to other problems mentioned above blocked by
> missing libreoffice. Debian libreoffice package doesn't even try to
> build on arm64 (not in architecture list afaict). Ubuntu has
> libreoffice on arm64 but their v
Hi,
On Tue, May 28, 2013 at 05:56:55PM +0200, Emilio Pozuelo Monfort wrote:
> Just that it doesn't work on older ARM flavours or sparc:
>
>
> https://buildd.debian.org/status/package.php?p=graphit
Hi,
On Sat, Feb 25, 2012 at 02:16:09PM +, Luke Kenneth Casson Leighton wrote:
> > # file /usr/share/libreoffice/sdk/classes/win/unowinreg.dll
> > /usr/share/libreoffice/sdk/classes/win/unowinreg.dll: PE32 executable (DLL)
> > (console) Intel 80386 (stripped to external PDB), for MS Windows
>
Hi,
On Sat, Feb 25, 2012 at 01:49:02PM +, Luke Kenneth Casson Leighton wrote:
> it's even more hilarious than that: it's actually because java can't
> access windows registry functions, so someone wrote a c-based DLL
> which java *can* bind to. the fact that the end-result of the
Yes, that
On Fri, Feb 03, 2012 at 02:36:17AM +, peter green wrote:
> Libreoffice hasn't yet been built on armhf. I consider libreoffice
https://buildd.debian.org/status/logs.php?pkg=libreoffice&arch=armhf&ver=1%3A3.4.5-3
Thanks Jani Monoses for the porting needed for that.
(http://anonscm.debian.org/gi
Hi,
> Libreoffice hasn't yet been built on armhf. I consider libreoffice to be
> a reasonablly important package and one that we need to get in before we
> can claim we have a reasonablly complete port.
And the segfault described on
https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/90
On Thu, Oct 28, 2010 at 10:39:50AM +0100, Martin Michlmayr wrote:
> * Hai Nguyen Dang [2010-10-28 14:25]:
> > I installed Debian on my SheevaPlug by manual method and it has run for 6
> > months without problem. but I found that the base system is 5.0.4 (Lenny,
> > 2010-06-13). Do I need another b
Package: ftp.debian.org
Severity: normal
Hi,
please remove openoffice.org for armel from experimental and unstable.
There is a long-standing toolchain breakage which prevents it from starting
up.
See
http://lists.debian.org/debian-openoffice/2009/12/msg00172.html + thread
http://www.openoffice.
Hi,
Am Dienstag, 16. November 2004 13:51 schrieben Sie:
> I built and ran them on debussy and the basic stuff I tested worked fine,
> but I was behind a slow X forwarding so I didn't test much...
>
> Happy testing :-)
Hrmpf. Sent it too fast:
http://people.debian.org/~rene/openoffice.org/test/a
Hi,
$SUBJECT seems to be complete for 1.1.x and will probably go into upstream CVS
soon. I built a "normal" installset and debs based on the current Debian CVS
for 1.1.3 (you'll need the binary-indep stuff from experimental).
The next upload to experimental probably will contain _arm binary pac
45 matches
Mail list logo
