[Bug 1913388] Re: clucene-core: please pull in patch to stabilize API on s390x during upgrade to glibc 2.33
fyi, fixed patch for clucene to keep the ABI constant on s390x is attached to https://sourceforge.net/p/clucene/bugs/233/. The patch requires that clucene uses a separate type clucene_float_t in its API, with multiple yet trivial changes all across the code base. None of the packages that depend on clucene required modifications to cope with that API change; sword, bibletime, dovecot, and libreoffice just build in a current hirose with a modified clucene. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1913388 Title: clucene-core: please pull in patch to stabilize API on s390x during upgrade to glibc 2.33 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1913388/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1913388] Re: clucene-core: please pull in patch to stabilize API on s390x during upgrade to glibc 2.33
Indeed, my patch is just broken. I have not received any upstream feedback about the patch or the proposed alternatives -- unfortunately, clucene's community appears rather inactive, with 0 emails on the developer list in the last three months. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1913388 Title: clucene-core: please pull in patch to stabilize API on s390x during upgrade to glibc 2.33 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1913388/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1904899] Re: pixel color access delivers wrong data on s390x (e.g., tests/color_test.py)
version 0.6.4 has been released, including the fix -- https://docs.wand- py.org/en/0.6.4/changes.html#version-0-6-4 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1904899 Title: pixel color access delivers wrong data on s390x (e.g., tests/color_test.py) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/wand/+bug/1904899/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1904899] [NEW] pixel color access delivers wrong data on s390x (e.g., tests/color_test.py)
Public bug reported: When using an Imagemagick compiled with HDRI=1 (e.g., ,libmagickwand-6.q16hdri-6) many color-related test cases in wand fail. The root cause is that python-wand assumes that ImageMagick's QuantumType would be float for 16-bit HDRI. However, in that config QuantumType is derive from float_t, which on s390x today is defined as double. The upstream issue https://github.com/emcconville/wand/issues/504 has already been resolved. The fix will be included in the upcoming release 0.6.4. Please consider upgrading to the new release, once available. Upstream fix in PR https://github.com/emcconville/wand/pull/505 The issue can be reproduced by running the testsuite (pytest / pytest-3). ** Affects: wand (Ubuntu) Importance: Undecided Status: New ** Description changed: When using an Imagemagick compiled with HDRI=1 (e.g., ,libmagickwand-6.q16hdri-6) many color-related test cases in wand fail. The root cause is that python-wand assumes that ImageMagick's QuantumType would be float for 16-bit HDRI. However, in that config QuantumType is derive from float_t, which on s390x today is defined as double. The upstream issue https://github.com/emcconville/wand/issues/504 has already been resolved. The fix will be included in the upcoming release 0.6.4. Please consider upgrading to the new release, once available. + + The issue can be reproduced by running the testsuite (pytest / + pytest-3). ** Description changed: When using an Imagemagick compiled with HDRI=1 (e.g., ,libmagickwand-6.q16hdri-6) many color-related test cases in wand fail. The root cause is that python-wand assumes that ImageMagick's QuantumType would be float for 16-bit HDRI. However, in that config QuantumType is derive from float_t, which on s390x today is defined as double. The upstream issue https://github.com/emcconville/wand/issues/504 has already been resolved. The fix will be included in the upcoming release 0.6.4. Please consider upgrading to the new release, once available. + Upstream fix in PR https://github.com/emcconville/wand/pull/505 The issue can be reproduced by running the testsuite (pytest / pytest-3). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1904899 Title: pixel color access delivers wrong data on s390x (e.g., tests/color_test.py) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/wand/+bug/1904899/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1893653] Re: [20.10 FEAT] Algebra lib optimizations - OpenBlas (0.3.10) + enable DYNAMIC_ARCH=1
** Patch added: "update package description to reflect dynamic arch support on s390x" https://bugs.launchpad.net/ubuntu/+source/openblas/+bug/1893653/+attachment/5424642/+files/fix-description-dynamic-s390x.diff -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1893653 Title: [20.10 FEAT] Algebra lib optimizations - OpenBlas (0.3.10) + enable DYNAMIC_ARCH=1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1893653/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1883520] Re: easystroke fails to build on s390x (with fix)
** Patch added: "proposed patch for the Ubuntu package (including DEP3 metadata)" https://bugs.launchpad.net/ubuntu/+source/easystroke/+bug/1883520/+attachment/5384012/+files/move-gesture-stroke-template.patch -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1883520 Title: easystroke fails to build on s390x (with fix) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/easystroke/+bug/1883520/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1883520] Re: easystroke fails to build on s390x (with fix)
Note that my patch in https://github.com/markdstjohn/easystroke/commit/686b7778767f1f94cf9f6d5c2acd401d76bb3d4a applies cleanly on top of 0.6.0-0ubuntu14. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1883520 Title: easystroke fails to build on s390x (with fix) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/easystroke/+bug/1883520/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1883520] [NEW] easystroke fails to build on s390x (with fix)
Public bug reported: easystroke fails to build on s390x with -march=z13 and newer (as introduced in Ubuntu 20.04) because of an unexpected interaction of C++ template and compiler optimizations. tl;dr: The code relies on compiler- and optimization-level dependent behavior and the relatively aggressive inlining parameters on s390x with -march=z13 expose these. Note that I can reproduce the build failures on x86_64 with equivalent gcc parameters --param max-inline-insns-auto=80 --param inline-min-speedup=2 (I did not try any other arch). The build can be fixed by moving the definition of template member functions Stroke::save() and Stroke::load() into gesture.h. As a side- effect, that change unifies code style, since all other classes have their ::save() and ::load() definitions in header files, too. I have prepared a patch to that avail and submitted a PR upstream (https://github.com/thjaeger/easystroke/pull/14). While the upstream repo appears inactive, "markdstjohn" has included the patch in his fork https://github.com/markdstjohn/easystroke What is going wrong in detail: In gesture.h, the template member functions Stroke::save and Stroke::load get called via the serialize() function generated by boost's macro BOOST_SERIALIZATION_SPLIT_MEMBER(). Since the definitions of save()/load() are only available in gesture.cc, the compiler may produce two versions of Stroke::serialize(): one with save()/load() inlined in gesture.o and one with calls to save()/load() in all other translation units that #include gesture.h but lack the definitions from gesture.cc. Since the compiler inlined Stroke::save() and Stroke::load(), it will not export them in gesture.o (which is legitimate, to my analysis, since the code only requests an export of Stroke::serialize). As a result, linking can fail, depending on the link order (i.e., when the linker picks a version of Stroke::serialize() that would call save()/load() instead of the version with these functions inlined). ** Affects: easystroke (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1883520 Title: easystroke fails to build on s390x (with fix) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/easystroke/+bug/1883520/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
