On Wednesday 2021-07-28 11:34, John Paul Adrian Glaubitz wrote:

On 7/28/21 11:14 AM, Peter Czanik wrote:

...

I'm just preparing an update for syslog-ng, from version 3.30 to 3.33. One of the new features is MQTT destination support. The necessary dependency is available both in Tumbleweed and Leap.

However, if you take a look at https://build.opensuse.org/package/show/home:czanik: branches:Base:System/syslog-ng you will see, that the ppc platform reports:

*unresolvable:* nothing provides libpaho-mqtt-devel

Do I have to handle it in the spec file? Is ppc still actively developed / supported? If yes, how can I disable MQTT for the given architecture?

paho-mqtt-c is one of the affected packages which is disabled on ppc, see [1].

...

[1] https://build.opensuse.org/package/show/openSUSE:Factory:PowerPC/paho-mqtt-c

I don't see any "disabled". Instead: ppc succeeded ppc64 succeeded ppc64le succeeded (Nobody switched the enabled/disabled state in the past hour or so, either, AFAICT.)

On Wed, 2021-07-28 at 12:17 +0200, John Paul Adrian Glaubitz wrote:

On 7/28/21 12:15 PM, Jan Engelhardt wrote:

...

I don't see any "disabled". Instead:

ppc succeeded ppc64 succeeded ppc64le succeeded

(Nobody switched the enabled/disabled state in the past hour or so, either, AFAICT.)

Huh, that's odd. It said "excluded" when I looked at it. I did actually check before posting here.

The ppc arch is a bit special - packages are 'excluded' by default, unless added to a permissive list. Andreas updated the list today: osc rdiff -r 1848:1849 openSUSE:Factory:PowerPC _project +BuildFlags: onlybuild:paho-mqtt-c Cheers, Dominique

On 7/28/21 12:25 PM, Andreas Schwab wrote:

I have just enabled it.

$ osc meta prjconf | grep paho-mqtt-c BuildFlags: onlybuild:paho-mqtt-c

Thank God, I'm not crazy (yet) :). Adrian

On 28/07/2021 12:29, Peter Czanik wrote:

In the meanwhile I ran into yet another architecture question: armv7l. Compilation failed right at the beginning as running Java failed.

First of all: should I still care about armv7l? If yes, what is the proper next step? (disabling Java support on armv7l, finding a larger build machine, etc.)

I saw the problem and I fixed it in the Java:bootstrap and Java:Factory repositories. Basically, I wiped the binaries and forced the javas to rebuild in chain. I am pretty sure that any of those javas work well now on armv7l, since I rebuilt them all using my Raspberry PI and all was just fine. So, if you add Java:Factory to your repositories as source, all will work fine. Now, for the maintainers of openSUSE:Factory:ARM, temporarily aggregate the java-1_8_0-openjdk from Java:Factory and rebuild with it the just submitted package would fix all, since a working binaries would exist in the project. Cheers Fridrich

Sorry: just found `ExcludeArch: ppc ppc64 ppc64le s390 s390x` at libqt5-qtwebengine.spec :( чт, 29 июл. 2021 г. в 09:15, Dmitriy Perlow :

Hi to all!

Could you please also enable libqt5-qtwebengine because of plans to remove QtWebKit from openSUSE?

ср, 28 июл. 2021 г. в 15:51, Fridrich Strba :

...

On 28/07/2021 12:29, Peter Czanik wrote:

...

In the meanwhile I ran into yet another architecture question: armv7l. Compilation failed right at the beginning as running Java failed.

First of all: should I still care about armv7l? If yes, what is the proper next step? (disabling Java support on armv7l, finding a larger build machine, etc.)

I saw the problem and I fixed it in the Java:bootstrap and Java:Factory repositories. Basically, I wiped the binaries and forced the javas to rebuild in chain. I am pretty sure that any of those javas work well now on armv7l, since I rebuilt them all using my Raspberry PI and all was just fine. So, if you add Java:Factory to your repositories as source, all will work fine.

Now, for the maintainers of openSUSE:Factory:ARM, temporarily aggregate the java-1_8_0-openjdk from Java:Factory and rebuild with it the just submitted package would fix all, since a working binaries would exist in the project.

Cheers

Fridrich

-- Best regards, Dmitriy Perlow

-- Best regards, Dmitriy Perlow

Gesendet: Donnerstag, 29. Juli 2021 um 08:43 Uhr Von: "John Paul Adrian Glaubitz" An: "Dmitriy Perlow" , "Fridrich Strba" Cc: "Peter Czanik" , "Jan Engelhardt" , "opensuse-factory" Betreff: Re: ppc?

Hi Dmitriy!

On 7/29/21 8:37 AM, Dmitriy Perlow wrote:

...

Sorry: just found `ExcludeArch: ppc ppc64 ppc64le s390 s390x` at libqt5-qtwebengine.spec :(

QtWebEngine is based on Chromium instead of WebKit and as an effect, it's highly unportable [1].

It's unfortunately rather difficult to convince Google to take patches to add support for non-mainstream targets to any of their projects. There was a developer at Oracle that invested huge efforts to port Golang to sparc64 but Google just dismissed the work due to their own lack of interest.

It's a pity that Qt switched to Chromium instead of sticking with the much more portable WebKit.

Exactly that all makes it difficult to enable it! I tried to receive an approval from IBM for enablement of all the Qt stuff. My first try failed. The next recommendation by Distinguished Engineers was to create a dependency tree (with development environment packages and other things required for servers or development). If there is enough with dependencies to Qt, then we can receive it enabled. My former Manager (during my Bachelor Thesis) has created a team for Linux on Z Enablement. Same exists for Power. We are allowed to forward that all. The requirement is "good reasons" matching IBM internal priorities (development (wish by employees) or server (customer requirements) stuff). Best regards, Sarah

Adrian

...

[1] https://buildd.debian.org/status/package.php?p=qtwebengine-opensource-src&suite=sid

Gesendet: Donnerstag, 29. Juli 2021 um 12:44 Uhr Von: "John Paul Adrian Glaubitz" An: "Sarah Julia Kriesch" Cc: "Dmitriy Perlow" , "Fridrich Strba" , "Peter Czanik" , "Jan Engelhardt" , "opensuse-factory" Betreff: Re: ppc?

On 7/29/21 12:31 PM, Sarah Julia Kriesch wrote:

...

Exactly that all makes it difficult to enable it! I tried to receive an approval from IBM for enablement of all the Qt stuff. My first try failed. The next recommendation by Distinguished Engineers was to create a dependency tree (with development environment packages and other things required for servers or development). If there is enough with dependencies to Qt, then we can receive it enabled.

Well, someone would have to port Chromium to s390x and then convince Google to merge the changes which is probably very unlikely.

Exactly! Chromium on servers... That was a point against porting that all for IBM. Why do you need Chromium on a mainframe or on Power? If there are development environmets using Chromium or anything in this direction, or any development environment needs our Qt packages and that requires Chromium, then we receive support for enablement. Desktop environments and Chromium are no good arguments for IBM (or not good enough). Best regards, Sarah

Support for riscv64 exists, at leats, but I'm not sure whether it got merged yet.

Adrian

Gesendet: Donnerstag, 29. Juli 2021 um 12:58 Uhr Von: "Peter Czanik" An: "Sarah Julia Kriesch" , "John Paul Adrian Glaubitz" Cc: "Dmitriy Perlow" , "Fridrich Strba" , "Jan Engelhardt" , "opensuse-factory" Betreff: Re: ppc?

Hi,

On 7/29/21 12:53 PM, Sarah Julia Kriesch wrote:

...

Exactly! Chromium on servers... That was a point against porting that all for IBM. Why do you need Chromium on a mainframe or on Power?

I have quite a few friends who use Power9 as workstation:

https://www.raptorcs.com/content/base/products.html

They really miss proper browser support...

That is on the way inside of IBM, too. The management is saying: "Power and s390x should be used for server applications." Then we created a survey for development employees and then there was the wish: "We want to develop directly on servers!" -> New top priority inside of IBM! If I would come with Chromium, then I would receive: "Developers should use the browser on the workstation. Why do we need Chromium on Power/s390x?" I have got my reason to recommend "openSUSE Tumbleweed on the mainframe" for development. ;-) Then I can receive additional "new" priorities (perhaps for Chromium, too?) exactly with the same background as you have been referencing in the future, too. It is difficult to argue for Chromium and such things in front of IBM. I take time for research continuously how to find anything, that could be a good argument because of "Unresolvables" to receive the whole stack enabled. Best regards, Sarah

Bye,

CzP

On Thursday 2021-07-29 13:28, Michael Ströder wrote:

On 7/29/21 1:19 PM, Sarah Julia Kriesch wrote:

...

If I would come with Chromium, then I would receive: "Developers should use the browser on the workstation. Why do we need Chromium on Power/s390x?"

For running virtual desktops on big iron? SCNR.

Ah yes, the days of Sun Ray hardware. Also, "Windows 365" was recently pitched.

Gesendet: Donnerstag, 29. Juli 2021 um 13:33 Uhr Von: "John Paul Adrian Glaubitz" An: factory@lists.opensuse.org Betreff: Re: ppc?

On 7/29/21 1:28 PM, Michael Ströder wrote:

...

On 7/29/21 1:19 PM, Sarah Julia Kriesch wrote:

...

If I would come with Chromium, then I would receive: "Developers should use the browser on the workstation. Why do we need Chromium on Power/s390x?"

For running virtual desktops on big iron? SCNR.

Or for rendering web pages on servers and delivering them to mobile clients [1].

That is a good point and argument. Thank you to all for these links. That will come to my list for aguments. Then I will retry it with IBM. ^^

Running webbrowsers on servers isn't actually that pointless.

Adrian

...

[1] https://chromium.googlesource.com/chromium/src/+/lkgr/headless/README.md

Best regards, Sarah

On Jul 29 2021, John Paul Adrian Glaubitz wrote:

Well, someone would have to port Chromium to s390x and then convince Google to merge the changes which is probably very unlikely.

There are two parts to consider wrt. chromium: V8 (the javascript engine) and the renderer. The V8 part has support for powerpc (all three variants) and s390x. The renderer on the other hand has much less architecture support, but it is also easier to port.

Support for riscv64 exists, at leats, but I'm not sure whether it got merged yet.

The RISC-V support in V8 is already upstream for some time, and already found its way into current versions of chromium and node. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."

On 7/29/21 1:35 PM, John Paul Adrian Glaubitz wrote:

Hmm, V8 has support for 32-bit PowerPC these days? I remember that one Debian colleague told me he would be working a 32-bit port for a commercial customer. Has that happened yet?

So, what do we need to get NodeJS to build on 32-bit PowerPC?

https://build.opensuse.org/package/show/openSUSE:Factory:PowerPC/nodejs16 https://buildd.debian.org/status/package.php?p=nodejs&suite=experimental

Adrian

On 7/29/21 1:51 PM, Andreas Schwab wrote:

On Jul 29 2021, John Paul Adrian Glaubitz wrote:

...

Hmm, V8 has support for 32-bit PowerPC these days?

No idea how far it gets, it's just that the toplevel build script tests for both ppc and ppc64.

Guess there is only one way for me to find out :-). Adrian

Andreas, On 7/29/21 2:33 PM, John Paul Adrian Glaubitz wrote:

So, version 14 fails on Debian with: (...)

I can't figure out the correct value for kOptionalPaddingOffset for 32-bit PowerPC: In file included from ../deps/v8/src/execution/isolate.h:18, from ../deps/v8/src/api/api.h:10, from ../deps/v8/src/api/api-arguments.h:8, from ../deps/v8/src/api/api-arguments.cc:5: ../deps/v8/src/objects/code.h:445:52: error: static assertion failed: FIELD_SIZE(kOptionalPaddingOffset) == kHeaderPaddingSize 445 | STATIC_ASSERT(FIELD_SIZE(kOptionalPaddingOffset) == kHeaderPaddingSize); ../deps/v8/src/base/macros.h:200:43: note: in definition of macro 'STATIC_ASSERT' 200 | #define STATIC_ASSERT(test) static_assert(test, #test) | Any idea? Adrian

Hi Danilo! On 7/29/21 2:51 PM, Danilo Spinella wrote:

Do you want to convince the same developers that don't want to add a pkg-config file in their library because they would need to maintain it? Good luck with that :)

I managed to convince LLVM upstream to merge a backend for the 40-year-old Motorola 68000 architecture, so I think I can actually be very convincing :D. Adrian