
Hi, 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/sys... 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? Peter

Hi Peter! On 7/28/21 11:14 AM, Peter Czanik wrote:
openSUSE doesn't build all available packages for ppc, most likely for saving build resources as far as I know. paho-mqtt-c is one of the affected packages which is disabled on ppc, see [1]. Building it on openSUSE would be possible I guess since the package builds just fine on Debian on 32-bit PowerPC [2]. So we might be able to convince the PowerPC project maintainers to enable the package on ppc. Adrian
[1] https://build.opensuse.org/package/show/openSUSE:Factory:PowerPC/paho-mqtt-c [2] https://buildd.debian.org/status/package.php?p=paho.mqtt.c&suite=sid

On Wed, 2021-07-28 at 12:17 +0200, John Paul Adrian Glaubitz wrote:
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 Jul 28 2021, Jan Engelhardt wrote:
I have just enabled it. $ osc meta prjconf | grep paho-mqtt-c BuildFlags: onlybuild:paho-mqtt-c 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/28/21 12:15 PM, Jan Engelhardt wrote:
Strange. It was showing "excluded" when I last checked it. 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.) Peter

On 28/07/2021 12:29, Peter Czanik wrote:
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

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. Adrian
[1] https://buildd.debian.org/status/package.php?p=qtwebengine-opensource-src&su...

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&su...

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

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... Bye, CzP

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 7/29/21 1:28 PM, Michael Ströder wrote:
Or for rendering web pages on servers and delivering them to mobile clients [1]. Running webbrowsers on servers isn't actually that pointless. Adrian
[1] https://chromium.googlesource.com/chromium/src/+/lkgr/headless/README.md

On 7/29/21 12:53 PM, Sarah Julia Kriesch wrote:
Browsers can be used in headless-mode these days which actually makes sense on servers [1]. Adrian
[1] https://developers.google.com/web/updates/2017/04/headless-chrome

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:32 PM, Andreas Schwab 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? If yes, we could work on getting Firefox to build on ppc again (yay!). As for Chromium, if it's not too difficult, it might be an idea to port it to all architectures which already have V8 support.
Good to know, thanks. Adrian

On 7/29/21 1:35 PM, John Paul Adrian Glaubitz wrote:
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 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. 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 2:14 PM, John Paul Adrian Glaubitz wrote:
So, version 14 fails on Debian with: In file included from ../deps/v8/src/objects/visitors.h:9, from ../deps/v8/src/heap/heap.h:33, from ../deps/v8/src/heap/factory.h:16, from ../deps/v8/src/execution/isolate.h:28, 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:439:2: error: #error Unknown architecture. 439 | #error Unknown architecture. | ^~~~~ 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:441:55: error: 'kHeaderPaddingSize' was not declared in this scope 441 | 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) | ^~~~ 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

yay! ________________________________________ From: John Paul Adrian Glaubitz <adrian.glaubitz@suse.com> Sent: Thursday, July 29, 2021 5:56 AM To: factory@lists.opensuse.org Subject: Re: ppc? Hi Danilo! On 7/29/21 2:51 PM, Danilo Spinella wrote:
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
participants (11)
-
Andreas Schwab
-
Danilo Spinella
-
Dmitriy Perlow
-
Dominique Leuenberger / DimStar
-
Fridrich Strba
-
Jan Engelhardt
-
John Paul Adrian Glaubitz
-
Michael Ströder
-
Peter Czanik
-
Sarah Julia Kriesch
-
Test Mailbox for Import Export