Re: Plan to remove dead C++ UNO bridge implementations (bridges/source/cpp_uno/*)

[John Paul Adrian Glaubitz]

Hi Stephan!

On 1/24/23 14:33, Stephan Bergmann wrote:

diff --git a/bridges/Library_cpp_uno.mk b/bridges/Library_cpp_uno.mk
index 5dc92c23cdbb..44130ad69732 100644
--- a/bridges/Library_cpp_uno.mk
+++ b/bridges/Library_cpp_uno.mk
@@ -188,7 +188,7 @@ bridge_exception_objects := except

 else ifeq ($(CPUNAME),X86_64)

-ifneq ($(filter ANDROID DRAGONFLY FREEBSD LINUX NETBSD OPENBSD HAIKU,$(OS)),)
+ifneq ($(filter ANDROID DRAGONFLY FREEBSD LINUX NETBSD OPENBSD HAIKU 
SOLARIS,$(OS)),)
 bridges_SELECTED_BRIDGE := gcc3_linux_x86-64
 bridge_asm_objects := call
 bridge_noncallexception_noopt_objects := callvirtualmethod


but I haven't actually heard anything about how that build is done.


They're using gcc3_solaris_x86-65, see:


https://github.com/OpenIndiana/oi-userland/blob/9763ae68f01c86848eecd13714f7c66522d47d51/components/desktop/libreoffice/patches/59-bridge-library.patch


which they are maintaining locally, it seems:


https://github.com/OpenIndiana/oi-userland/tree/9763ae68f01c86848eecd13714f7c66522d47d51/components/desktop/libreoffice/files/gcc3_solaris_x86-64


Full package build folder, including Makefile, can be found here:


https://github.com/OpenIndiana/oi-userland/tree/9763ae68f01c86848eecd13714f7c66522d47d51/components/desktop/libreoffice


Maybe it could make sense to upstream the their Solaris x86_64 bridge?

Andreas Wacknitz seems to be the most active maintainer of this code.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Plan to remove dead C++ UNO bridge implementations (bridges/source/cpp_uno/*)

[John Paul Adrian Glaubitz]

Hello Stephan!

> On Jan 24, 2023, at 1:43 PM, Stephan Bergmann  wrote:
> 
> On 10/01/2023 17:31, Stephan Bergmann wrote:
>> 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 
>> 
>>  "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.
> [...]
>> (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
> 
> With the various responses to this mailing list thread, that list of 
> presumably dead bridge implementations is down to four now: gcc3_aix_powerpc, 
> gcc3_linux_s390, gcc3_solaris_intel, and gcc3_solaris_sparc.
> 
> I have prepared three sets of Gerrit changes (see below) to remove those four 
> bridge implementations and, in some cases, complete platform support, and 
> plan to submit those on LO master towards LO 7.6 after a final round of 
> discussions in Thursday's ESC meeting.
> 
> *  and 
>  "Remove support for AIX":
> 
>> As discussed in the mailing list thread starting at
>> 
>> "Plan to remove dead C++ UNO bridge implementations 
>> (bridges/source/cpp_uno/*)",
>> the bridge implementation at bridges/source/cpp_uno/gcc3_aix_powerpc is
>> apparently dead and should thus be removed.  However, that was the only 
>> bridge
>> implementation for AIX, which implies that support for the AIX platform as a
>> whole is dead and should thus be removed.
> 
> *  "Remove support for 32-bit 
> S390":
> 
>> As discussed in the mailing list thread starting at
>> 
>> "Plan to remove dead C++ UNO bridge implementations 
>> (bridges/source/cpp_uno/*)",
>> the bridge implementation at bridges/source/cpp_uno/gcc3_linux_s390 is
>> apparently dead and should thus be removed.  However, that was the only 
>> bridge
>> implementation for 32-bit S390, which implies that support for the 32-bit 
>> S390
>> architecture as a whole is dead and should thus be removed.
> 
> *  "Remove Solaris 32-bit 
> SPARC and x86 C++ UNO bridge implementations":
> 
>> Those were the only bridge implementations for Solaris, but the
>> referenced thread mentions that there are recent builds for OpenIndiana 
>> x86-64
>> (however they are done; presumably using
>> bridges/source/cpp_uno/gcc3_linux_x86-64), so keep general support for 
>> Solaris
>> intact for now.

Huh? You can use Linux Uno support to build LibreOffice for Solaris x86_64?

Did any of the Illumos developers chime in to confirm that?

Adrian

Re: LibreOffice architecture support (was: Fwd: Plan to remove dead C++ UNO bridge implementations (bridges/source/cpp_uno/*))

[John Paul Adrian Glaubitz]

Hi Stephan!

On 1/12/23 10:48, Stephan Bergmann wrote:

On 10/01/2023 19:57, John Paul Adrian Glaubitz wrote:

Hi Stephan!


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.



(5) Presumably dead:

[...]

* gcc3_solaris_intel
* gcc3_solaris_sparc


Oracle is still maintaining Solaris until at least 2035 and OpenIndiana is 
still maintained, too.

According to this article, LibreOffice 7.2.7 was shipped with OpenIndiana 
2022.10:


https://www.theregister.com/2022/12/07/new_version_of_openindiana/


So, I'm not sure dropping Solaris support is a good idea either.


Thanks for that link.

 From <https://en.wikipedia.org/wiki/OpenIndiana> it looks like at least OpenIndiana only supports 
x86-64, so neither gcc3_solar_intel (32-bit x86) nor gcc3_solaris_sparc (32-bit SPARC) should be relevant 
for it. I'm adding Andreas Wacknitz (who's the author of recent OpenIndiana announcements like 
<https://www.openindiana.org/2022/12/04/openindiana-hipster-2022-10-is-here/>) in CC, maybe he can 
shed some light on this.  (Andreas, my full original email starting this thread is at 
<https://lists.freedesktop.org/archives/libreoffice/2023-January/089808.html> "Plan to remove 
dead C++ UNO bridge implementations (bridges/source/cpp_uno/*)").

I don't know if there are any other Solaris-based offerings for which current 
LO master gcc3_solaris_intel and/or gcc3_solar_sparc would still be relevant.  
If somebody knows of any, please report back here.


I'm adding two of the Solaris maintainers at Oracle that I know to ask them 
whether
the SPARC port for LibreOffice is still relevant for them.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: LibreOffice architecture support (was: Fwd: Plan to remove dead C++ UNO bridge implementations (bridges/source/cpp_uno/*))

[John Paul Adrian Glaubitz]

Hi Stephan!

On 1/11/23 08:21, Stephan Bergmann wrote:

On 10/01/2023 19:57, John Paul Adrian Glaubitz wrote:

(5) Presumably dead:
* gcc3_linux_alpha


=> https://buildd.debian.org/status/logs.php?pkg=libreoffice=alpha


Thanks for those pointers.  Just to make sure, the latest line there being


1:6.4.5-1 (sid) Buildd exposure stats alpha Maybe-Failed 2020-07-03 
06:39:28 phys 18h 37m 9.48 GB


means that that's a build of LO 6.4.5, right?  Are all those Debian Ports 
builds consistently lagging behind current LO master by N years?


No, that's not a consistent state but rather was due to various resource 
problems in the past.

I have actually started working these issues out now and as a first result, the 
latest version
of the libreoffice package was already built successfully on 32-bit PowerPC:


https://buildd.debian.org/status/package.php?p=libreoffice=sid


More architectures will follow within the next weeks. I will make use of the 
freed up time to work
on these issues to get LibreOffice building.

If it helps, please add myself as a code owner for the Debian Ports 
architectures. I am willing to
keep the stuff working together with the other maintainers in Debian Ports (and 
probably Gentoo).

Thanks,
Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: LibreOffice architecture support (was: Fwd: Plan to remove dead C++ UNO bridge implementations (bridges/source/cpp_uno/*))

[John Paul Adrian Glaubitz]

Hi Stephan!


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.



(5) Presumably dead:
* gcc3_linux_alpha


=> https://buildd.debian.org/status/logs.php?pkg=libreoffice=alpha


* gcc3_linux_hppa


=> https://buildd.debian.org/status/logs.php?pkg=libreoffice=hppa


* gcc3_linux_ia64


=> https://buildd.debian.org/status/logs.php?pkg=libreoffice=ia64


* gcc3_linux_m68k


=> https://buildd.debian.org/status/logs.php?pkg=libreoffice=m68k


* gcc3_linux_powerpc


=> https://buildd.debian.org/status/logs.php?pkg=libreoffice=powerpc


* gcc3_linux_sparc64


=> https://buildd.debian.org/status/logs.php?pkg=libreoffice=sparc64

We're still maintaining these in Debian Ports. I have added the build logs for 
the latest builds above.

New builds will be triggered soonish when I have worked through the queue of 
package
dependencies that need to be fixed.


* gcc3_solaris_intel
* gcc3_solaris_sparc


Oracle is still maintaining Solaris until at least 2035 and OpenIndiana is 
still maintained, too.

According to this article, LibreOffice 7.2.7 was shipped with OpenIndiana 
2022.10:


https://www.theregister.com/2022/12/07/new_version_of_openindiana/


So, I'm not sure dropping Solaris support is a good idea either.


* gcc3_linux_sparc


32-bit SPARC is still supported by Gentoo, see:


https://www.gentoo.org/downloads/


Let me know if I can be of any help.

PS: I'm subscribed to this list, but I don't receive any mail.

Thanks,
Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: m68k UnoApiTarget/udkapi.rdb build fails ("Bad input")

[John Paul Adrian Glaubitz]

Hi!

On 02/06/2018 10:29 PM, Rene Engelhard wrote:
> Don't have (and yes, I saw the build failure and your bug report).
> 
> Quickly looked at the file, but tbh don't see why it should fail only on
> m68k (no idea about arch-specifics which can cause that, though).
> 
> The latest round of m68k fixes (-mmlong-jump-table-offsets..) was done by
> John Paul Adrian Glaubitz, though, maybe he has an idea.

Yes, I will have a look at it at some point.

Please bear with me as I am very busy with many projects I am hacking on
to fix such bugs. We are still actively maintaining m68k in Debian and
these issues are being looked at.

It sometimes takes a bit time, so please do not put any pressure on us
in the sense that you are going to remove the m68k code altogether.

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice-commits] core.git: cppu/source

[John Paul Adrian Glaubitz]

 cppu/source/uno/check.cxx |   36 +++-
 1 file changed, 31 insertions(+), 5 deletions(-)

New commits:
commit d5d6ee3b3e7cf3d93f892a452244051e4294fe6d
Author: John Paul Adrian Glaubitz <glaub...@physik.fu-berlin.de>
Date:   Mon Dec 12 00:45:24 2016 +0100

uno: Add support for targets with 16-bit alignment

Despite being a 32-bit architecture, m68k has a basic
alignment of 16-bit for historic reasons. On m68k,
SAL_TYPES_ALIGNMENT8 is therefore equal to 2 and we
need to cover this case in the static asserts as well.

Change-Id: I4c756af25d57e5d49209697f6e678ef71a5845aa
Reviewed-on: https://gerrit.libreoffice.org/31878
Tested-by: Jenkins <c...@libreoffice.org>
Reviewed-by: Caolán McNamara <caol...@redhat.com>
Tested-by: Caolán McNamara <caol...@redhat.com>

diff --git a/cppu/source/uno/check.cxx b/cppu/source/uno/check.cxx
index 620a970..9a734a7 100644
--- a/cppu/source/uno/check.cxx
+++ b/cppu/source/uno/check.cxx
@@ -151,7 +151,10 @@ static_assert( static_cast(true) == sal_True,
"must be binary compatible" );
 static_assert( static_cast(false) == sal_False,
"must be binary compatible" );
-#if SAL_TYPES_ALIGNMENT8 == 4
+#if SAL_TYPES_ALIGNMENT8 == 2
+static_assert(offsetof(AlignSize_Impl, dDouble) == 2, 
"offsetof(AlignSize_Impl, dDouble) != 2");
+static_assert(sizeof(AlignSize_Impl) == 12, "sizeof(AlignSize_Impl) != 12");
+#elif SAL_TYPES_ALIGNMENT8 == 4
 static_assert(offsetof(AlignSize_Impl, dDouble) == 4, 
"offsetof(AlignSize_Impl, dDouble) != 4");
 static_assert(sizeof(AlignSize_Impl) == 12, "sizeof(AlignSize_Impl) != 12");
 #elif SAL_TYPES_ALIGNMENT8 == 8
@@ -181,7 +184,9 @@ static_assert(sizeof(N) == 12, "sizeof(N) != 12");
 static_assert(sizeof(N2) == 12, "sizeof(N2) != 12");
 
 static_assert(offsetof(N2, p) == 8, "offsetof(N2, p) != 8");
-#if SAL_TYPES_ALIGNMENT8 == 4
+#if SAL_TYPES_ALIGNMENT8 == 2
+static_assert(sizeof(O) == 16, "sizeof(O) != 16");
+#elif SAL_TYPES_ALIGNMENT8 == 4
 static_assert(sizeof(O) == 20, "sizeof(O) != 20");
 #elif SAL_TYPES_ALIGNMENT8 == 8
 static_assert(sizeof(O) == 24, "sizeof(O) != 24");
@@ -196,7 +201,14 @@ static_assert(offsetof(E, e) == 8, "offsetof(E, e) != 8");
 static_assert(sizeof(C1) == 2, "sizeof(C1) != 2");
 static_assert(sizeof(C2) == 8, "sizeof(C2) != 8");
 
-#if SAL_TYPES_ALIGNMENT8 == 4
+#if SAL_TYPES_ALIGNMENT8 == 2
+static_assert(sizeof(C3) == 18, "sizeof(C3) != 18");
+static_assert(sizeof(C4) == 30, "sizeof(C4) != 30");
+static_assert(sizeof(C5) == 40, "sizeof(C5) != 40");
+static_assert(sizeof(C6) == 44, "sizeof(C6) != 44");
+
+static_assert(sizeof(O2) == 18, "sizeof(O2) != 18");
+#elif SAL_TYPES_ALIGNMENT8 == 4
 static_assert(sizeof(C3) == 20, "sizeof(C3) != 20");
 static_assert(sizeof(C4) == 32, "sizeof(C4) != 32");
 static_assert(sizeof(C5) == 44, "sizeof(C5) != 44");
@@ -216,7 +228,10 @@ static_assert(sizeof(O2) == 32, "sizeof(O2) != 32");
 
 static_assert(sizeof(Char3) == 3, "sizeof(Char3) != 3");
 
-#if SAL_TYPES_ALIGNMENT8 == 4
+#if SAL_TYPES_ALIGNMENT8 == 2
+// max alignment is 2
+static_assert(sizeof(P) == 16, "sizeof(P) != 16");
+#elif SAL_TYPES_ALIGNMENT8 == 4
 // max alignment is 4
 static_assert(sizeof(P) == 20, "sizeof(P) != 20");
 #elif SAL_TYPES_ALIGNMENT8 == 8
@@ -242,7 +257,18 @@ BinaryCompatible_Impl::BinaryCompatible_Impl()
 
 assert(OFFSET_OF(C2, n2) == 4);
 
-#if SAL_TYPES_ALIGNMENT8 == 4
+#if SAL_TYPES_ALIGNMENT8 == 2
+assert(OFFSET_OF(C3, d3) == 6);
+assert(OFFSET_OF(C3, n3) == 14);
+assert(OFFSET_OF(C4, n4) == 18);
+assert(OFFSET_OF(C4, d4) == 22);
+assert(OFFSET_OF(C5, n5) == 30);
+assert(OFFSET_OF(C5, b5) == 38);
+assert(OFFSET_OF(C6, c6) == 2);
+assert(OFFSET_OF(C6, b6) == 42);
+
+assert(OFFSET_OF(O2, p2) == 16);
+#elif SAL_TYPES_ALIGNMENT8 == 4
 assert(OFFSET_OF(C3, d3) == 8);
 assert(OFFSET_OF(C3, n3) == 16);
 assert(OFFSET_OF(C4, n4) == 20);
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

[PATCH] Fix typo in configure.ac (mk68 -> m68k)

[John Paul Adrian Glaubitz]

Hi!

I maintain several unofficial architectures within Debian (Debian Ports),
one of them Debian m68k. Recently, enough progress was made in the m68k
port so that the buildds actually picked up the libreoffice source package
for building.

Unfortunately, the build bailed out with the following error:

> /usr/bin/ld: cannot find -ljawt

Looking at the compiler command line above, it's obvious why libjawt.so
was not found:

> S=/<> && I=$S/instdir && W=$S/workdir &&  m68k-linux-gnu-gcc 
> -shared -Wl,-z,noexecstack   -Wl,-z,origin '-Wl,-rpath,$ORIGIN' 
> -Wl,-rpath-link,$I/program -Wl,-z,defs -Wl,-rpath-link,/lib:/usr/lib 
> -Wl,-z,combreloc  -Wl,--hash-style=gnu  -Wl,--dynamic-list-cpp-new 
> -Wl,--dynamic-list-cpp-typeinfo -Wl,-Bsymbolic-functions  
> -L$W/LinkTarget/StaticLibrary -L$I/sdk/lib  -L$I/program  -L$I/program 
> -specs=/usr/share/dpkg/pie-link.specs -Wl,-z,relro   
> $W/CObject/bean/native/unix/com_sun_star_comp_beans_LocalOfficeWindow.o  
> -Wl,--start-group-L/usr/lib/jvm/default-java/jre/lib/mk68 -ljawt  
> -Wl,--end-group -Wl,--no-as-needed  -o $I/program/libofficebean.so
> 
  This should be "m68k".

Looking at the configure.ac script, it's very obvious where this typo comes 
from:

> my_java_arch=mk68

This should be, of course:

> my_java_arch=m68k

The attached patch fixes the typo. This contribution is licensed under LGPL3+/
GPL3+/MPL1.1+, in case that even applies for such a trivial patch.

I will follow up with more patches if these should be necessary for m68k. I will
also have Gerrit properly set up for that in the future.

Thanks,
Adrian

--
 .''`.  John Paul Adrian Glaubitz
 : :' :  Debian Developer - glaub...@debian.org
 `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
   `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice-commits] core.git: Branch 'libreoffice-5-3' - configure.ac

[John Paul Adrian Glaubitz]

 configure.ac |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

New commits:
commit 5ca0acb3c2757c00115b9879c4a6f044f4be1605
Author: John Paul Adrian Glaubitz <glaub...@physik.fu-berlin.de>
Date:   Sun Nov 27 19:22:59 2016 +0100

Fix typo in configure.ac (mk68 -> m68k)

Change-Id: Ibbedf9444e2c43b3dff886d9513be7e3d2a99095
Reviewed-on: https://gerrit.libreoffice.org/31276
Reviewed-by: Rene Engelhard <r...@debian.org>
Tested-by: Rene Engelhard <r...@debian.org>

diff --git a/configure.ac b/configure.ac
index 6e3a992..2dadc7c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -7127,7 +7127,7 @@ then
 my_java_arch=i386
 ;;
 m68k)
-my_java_arch=mk68
+my_java_arch=m68k
 ;;
 powerpc)
 my_java_arch=ppc
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

John Paul Adrian Glaubitz license statement

[John Paul Adrian Glaubitz]

All of my past & future contributions to LibreOffice may be
licensed under the MPLv2/LGPLv3+ dual license as well as
the GPLv2+.

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913



signature.asc
Description: OpenPGP digital signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice-commits] core.git: configure.ac

[John Paul Adrian Glaubitz]

 configure.ac |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

New commits:
commit f35d29c8388744be1f95ec4acfca12eec706911a
Author: John Paul Adrian Glaubitz <glaub...@physik.fu-berlin.de>
Date:   Sun Nov 27 19:22:59 2016 +0100

Fix typo in configure.ac (mk68 -> m68k)

Change-Id: Ibbedf9444e2c43b3dff886d9513be7e3d2a99095

diff --git a/configure.ac b/configure.ac
index 731e903..4480ed0 100644
--- a/configure.ac
+++ b/configure.ac
@@ -7121,7 +7121,7 @@ then
 my_java_arch=i386
 ;;
 m68k)
-my_java_arch=mk68
+my_java_arch=m68k
 ;;
 powerpc)
 my_java_arch=ppc
___
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

[PATCH] Fix typo in configure.ac (mk68 -> m68k)

[John Paul Adrian Glaubitz]

Signed-off-by: John Paul Adrian Glaubitz <glaub...@physik.fu-berlin.de>
---
 configure.ac | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index 731e903..4480ed0 100644
--- a/configure.ac
+++ b/configure.ac
@@ -7121,7 +7121,7 @@ then
 my_java_arch=i386
 ;;
 m68k)
-my_java_arch=mk68
+my_java_arch=m68k
 ;;
 powerpc)
 my_java_arch=ppc
-- 
2.1.4

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice