Comments

278 Comments
karma

Thank you.

BZ#2049038 Branch and build glew for EPEL 9
karma

Thank you.

BZ#2049037 Branch and build gl2ps for EPEL 9
BZ#2053637 Unable to install nodejs due to /usr/bin/pwsh dependency
karma

This update is not installable.

  • conflicting requests
  • nothing provides /usr/bin/pwsh needed by nodejs-1:14.19.0-2.fc34.x86_64
karma

Since the nodejs update with a ppc64le build is being pushed to stable, this should be pushed too.

BZ#2049039 Branch and build qt5-qtwebengine for EPEL 9
User Icon ellert commented & provided feedback on R-4.1.2-1.el9 5 months ago
karma

Works together with the R-rpm-macros update: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-af65119c48

BZ#2037933 Please branch and build R in epel9
karma
BZ#2039606 Please build R-rpm-macros for epel9

Regarding ppc64le

In EPEL 7 the nodejs_arches macro expands to:

<mock-chroot> sh-4.2# rpm -E %nodejs_arches i386 i486 i586 i686 pentium3 pentium4 athlon geode x86_64 armv3l armv4b armv4l armv4tl armv5tel armv5tejl armv6l armv7l armv7hl armv7hnl aarch64

This come fron epel-rpm-macros, In the file /etc/rpm/macros.zzz-epel-override

Override %nodejs_arches.

EPEL is providing nodejs on 64-bit ARM now, so the existing Red Hat provided

macro needs to be extended to include aarch64.

Requested by pbrobinson and sgallagh on IRC, 2016-09-16.

%nodejs_arches %{ix86} x86_64 %{arm} aarch64

So it is a bit of a chicken and egg problem if you want to change it. The macro is defined to the arches for which nodejs is built, and nodejs is built for the arches the macro defines.

If the new nodejs package would be working on ppc64le if it was built there, then the epel-rpm-macros must de changed to include %{power64}, then with this update in the build root rebuild nodejs.

In Fedora 35 the macro is defined in /lib/rpm/macros.d/macros.nodejs as

%nodejs_arches %{ix86} x86_64 %{arm} aarch64 %{power64} s390x

karma

Thanks. Restores buildability of davix in EPEL 9.

BZ#2034297 Please build rapidjson for EPEL-9
karma

This improves the situation, so I give karma. But why is there no ppc64le build?

BZ#2041022 Provide nodejs for EPEL 7
karma

With this package in the EPEL 9 buildroot uglify-js is buildable again.

https://koschei.fedoraproject.org/package/uglify-js?collection=epel9

BZ#2036086 Branch and build web-assets-devel for epel9
User Icon ellert commented & provided feedback on R-4.1.2-1.el9 5 months ago
karma

R-devel not installable due to missing R-rpm-macros.

karma

This update breaks the build of nordugrid-arc on ppc64le, due to failing tests.

The descrition for this update is "improve previous patch to cover more cases".

The previouss patch was:

diff -ur db-5.3.28/src/os/os_map.c db-patched/src/os/os_map.c
--- db-5.3.28/src/os/os_map.c   2013-09-09 17:35:09.000000000 +0200
+++ db-patched/src/os/os_map.c  2021-09-06 14:32:28.792139908 +0200
@@ -213,6 +213,10 @@
    if (rp->max < rp->size)
        rp->max = rp->size;
    if (ret == 0 && F_ISSET(infop, REGION_CREATE)) {
+#ifdef HAVE_MLOCK
+       if (F_ISSET(env, ENV_LOCKDOWN))
+           rp->size = rp->max;
+#endif
        if (F_ISSET(dbenv, DB_ENV_REGION_INIT))
            ret = __db_file_write(env, infop->fhp,
                rp->size / MEGABYTE, rp->size % MEGABYTE, 0x00);

The new patch is (after cleaning up unintentional indentation mistakes that makes it longer than necessary):

diff -ur db-5.3.28/src/os/os_map.c db_patch/src/os/os_map.c
--- db-5.3.28/src/os/os_map.c   2013-09-09 17:35:09.000000000 +0200
+++ db_patch/src/os/os_map.c    2021-09-09 07:33:12.027328265 +0200
@@ -213,6 +213,9 @@
    if (rp->max < rp->size)
        rp->max = rp->size;
    if (ret == 0 && F_ISSET(infop, REGION_CREATE)) {
+
+       rp->max = rp->size;
+
        if (F_ISSET(dbenv, DB_ENV_REGION_INIT))
            ret = __db_file_write(env, infop->fhp,
                rp->size / MEGABYTE, rp->size % MEGABYTE, 0x00);

This removes the condition, which is consistent with "to cover more cases". However, it also swaps the assignment from rp->size = rp->max; to rp->max = rp->size;, which was probably unintentional.

Was the patch intended to be:

diff -ur db-5.3.28/src/os/os_map.c db_patch/src/os/os_map.c
--- db-5.3.28/src/os/os_map.c   2013-09-09 17:35:09.000000000 +0200
+++ db_patch/src/os/os_map.c    2021-09-09 07:33:12.027328265 +0200
@@ -213,6 +213,9 @@
    if (rp->max < rp->size)
        rp->max = rp->size;
    if (ret == 0 && F_ISSET(infop, REGION_CREATE)) {
+
+       rp->size = rp->max;
+
        if (F_ISSET(dbenv, DB_ENV_REGION_INIT))
            ret = __db_file_write(env, infop->fhp,
                rp->size / MEGABYTE, rp->size % MEGABYTE, 0x00);
BZ#1983391 fetch-crl systemd timer unit broken
karma

Thanks for creating the update.

BZ#1950780 The uglify-js version in Fedora does not understand newer javascript versions.

Despite the error message, the transfer seems to succeed. The downloaded file has the correct checksum. I have forwarded the issue upstream: https://github.com/xrootd/xrootd/issues/1478

User Icon ellert commented & provided feedback on glibc-2.32-8.fc33 a year ago
karma

Tested HepMC3 build in Fedora 33 aarch64 mock buildroot on aarch64-test01.fedorainfracloud.org with this glibc version.

BZ#1965374 glibc: valgrind suppressions no longer active after debuginfo removal