- 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, ...)

Can you clarify this?
According to https://buildd.debian.org/status/package.php?p=openjdk-20 ,
there _is_ a JDK/JRE built for sparc64 (and other architectures).

Looking at https://buildd.debian.org/status/package.php?p=libreoffice#problem-17 ,
it seems like the "BD-Uninstallable" issue has nothing to do with Java.
Also, the reported libtiff5 issue seems to be sorted out as well: https://buildd.debian.org/status/package.php?p=tiff&suite=sid

I suppose this build will be "Installed" again after a rebuild of the
affected packages?

speak up at upstream or  they will be gone. And without those bridges no architecture support for it.

Can you clarify what the consequence of this will be? Will it mean that LibreOffice will become unbuildable for these architectures? Is there
any need for fixing these UNO bridges or bring them up to date?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello!

On 1/11/23 18:30, Rene Engelhard wrote:

But I was more aiming at (and sparc* has the same issue) is

libreoffice build-depends on:
- libkf5config-dev:m68k
libkf5config-dev depends on:
- libkf5configqml5:m68k (= 5.101.0-1)
libkf5configqml5 depends on:
- libqt5qml5:m68k (>= 5.15.2~)
libqt5qml5 depends on missing:
- qtbase-abi-5-15-6:m68k

And that transition happened already. And it was even BD-Uninstallable on Qt before that one.

Indeed. But those transitions have been done already. KDE uninstallable is a bug of those ports.

It's actually an inherent bug in the JavaScript engine of Qt that makes assumptions about the
hardware that it shouldn't make. For example, that it can use the upper bits of a pointer to
encode type information of a JavaScript object (tagged pointers) [1].

You may argue that it's okay because it works on x86_64. However, it only works because Intel
didn't make use of the upper 16 bits of a 64-bit pointer in the past although these were always
reserved. But that has changed now with the advent of 5-level paging [2] where the bits 48-56 are
used as well.

Luckily, the Qt developers have understood that their code is broken on systems with large
virtual address spaces, so they have reworked it and if you look at the corresponding Qt6
packages, you will see that these all build fine on sparc64.

Adrian

[1] https://bugreports.qt.io/browse/QTBUG-56264
[2] https://en.wikipedia.org/wiki/Intel_5-level_paging

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

Am 11.01.23 um 12:41 schrieb Gregor Riepl:

- 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, ...)

[...]
Looking at https://buildd.debian.org/status/package.php?p=libreoffice#problem-17
, it seems like the "BD-Uninstallable" issue has nothing to do with Java.

I haven't said that it is.

Also, the reported libtiff5 issue seems to be sorted out as well: https://buildd.debian.org/status/package.php?p=tiff&suite=sid

Did I say anything about libtiff? This might just be currently the problem.

I suppose this build will be "Installed" again after a rebuild of the affected packages?

Yes.


But I was more aiming at (and sparc* has the same issue) is

libreoffice build-depends on:
- libkf5config-dev:m68k
libkf5config-dev depends on:
- libkf5configqml5:m68k (= 5.101.0-1)
libkf5configqml5 depends on:
- libqt5qml5:m68k (>= 5.15.2~)
libqt5qml5 depends on missing:
- qtbase-abi-5-15-6:m68k

And that transition happened already. And it was even BD-Uninstallable
on Qt before that one.


Indeed. But those transitions have been done already. KDE uninstallable
is a bug of those ports.

speak up at upstream or  they will be gone. And without those bridges
no architecture support for it.

Can you clarify what the consequence of this will be? Will it mean
that LibreOffice will become unbuildable for these architectures?

Yes.


Regards,

Rene

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

Am 11.01.23 um 19:08 schrieb John Paul Adrian Glaubitz:

You may argue that it's okay because it works on x86_64. However, it
only works because Intel
didn't make use of the upper 16 bits of a 64-bit pointer in the past
although these were always
reserved. But that has changed now with the advent of 5-level paging
[2] where the bits 48-56 are
used as well.

I am not arguing anything, just stating that it's BD-Uninstallable
because of KDE (which is using Qt5).

Luckily, the Qt developers have understood that their code is broken
on systems with large
virtual address spaces, so they have reworked it and if you look at
the corresponding Qt6
packages, you will see that these all build fine on sparc64.

Another reason for libreoffice-qt6 which is in New since November. (But
as long as KDE is using Qt5... Or we disable KDE there.)


Regards,


Rene

Adrian

[1] https://bugreports.qt.io/browse/QTBUG-56264
[2] https://en.wikipedia.org/wiki/Intel_5-level_paging

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

speak up at upstream or  they will be gone. And without those bridges
no architecture support for it.

Can you clarify what the consequence of this will be? Will it mean
that LibreOffice will become unbuildable for these architectures?

Yes.

Thanks for informing us, then!

I'm 100% in favor of keeping sparc64 support in Libreoffice. I don't
have any stakes in the other ports, but I also think keeping them would
be preferable.

If upstream has difficulties supporting certain obscure architectures,
I'd be willing to help if I can. But it's hard to see these things
happening, unless one is directly involved with a project (which I'm not
in this case).

What exactly would be required to bring the long-broken LibreOffice
builds back into Debian? Doesn't the buildd output indicate most of the dependency issues have already been resolved in sid?

On the KDE question - does LO really depend on KDE?
Isn't there also Gnome support?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

Am 11.01.23 um 19:54 schrieb Gregor Riepl:

On the KDE question - does LO really depend on KDE?
Isn't there also Gnome support?

Yes. *also*.

Which means that it builds both and thus build-depends on both (and it
ends up in libreoffice-gtk3, libreoffice-qt5, libreoffice-kf5 of what
the user can install)


Regards,


Rene

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)