heads up: doxygen 1.11.0 is breaking lots of builds
See https://bugzilla.redhat.com/show_bug.cgi?id=2283362 -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Need help with likely template instantiation errors
We're trying to update vxl but running into some errors: /usr/bin/ld: ../../../../../../lib/libbbas_pro.so.3.5.0.0: undefined reference to `brdb_value_t > >::assign(brdb_value const&)' /usr/bin/ld: ../../../../../../lib/libbbas_pro.so.3.5.0.0: undefined reference to `brdb_value_t > >::eq(brdb_value const&) const' /usr/bin/ld: ../../../../../../lib/libbbas_pro.so.3.5.0.0: undefined reference to `brdb_value_t > >::b_read_value(vsl_b_istream&)' /usr/bin/ld: ../../../../../../lib/libbbas_pro.so.3.5.0.0: undefined reference to `brdb_value_t > >::get_type_string[abi:cxx11]()' /usr/bin/ld: ../../../../../../lib/libbbas_pro.so.3.5.0.0: undefined reference to `brdb_value_t > >::b_write_value(vsl_b_ostream&) const' /usr/bin/ld: ../../../../../../lib/libbbas_pro.so.3.5.0.0: undefined reference to `brdb_value_t > >::lt(brdb_value const&) const' This is outside of my C++ comfort level. Any help would be greatly appreciated. PR is here: https://src.fedoraproject.org/rpms/vxl/pull-request/2 -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: oneapi-level-zero requires cloned spdlog-populate
On 5/22/24 18:02, Luya Tshimbalanga wrote: Hello team, Upstream made a change that requires cloning a sub-directory spdlog-populate leading to a failure to build. What will be an alternative to address that issue? Scratch build result on http://koji.fedoraproject.org/koji/taskinfo?taskID=118027071 Thanks in advance References: [1] https://src.fedoraproject.org/rpms/oneapi-level-zero [2] https://github.com/oneapi-src/level-zero/blob/master/CMakeLists.txt -- Luya Tshimbalanga Fedora Design Team Fedora Design Suite maintainer I've pushed a quick hack here: https://src.fedoraproject.org/rpms/oneapi-level-zero/pull-request/1 But upstream really should be urged to make this configurable. -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Obsolete pygobject3-devel usage
On 4/15/24 19:03, Yaakov Selkowitz wrote: On Fri, 2024-04-12 at 17:35 -0400, Yaakov Selkowitz wrote: The pygobject3-devel compat provides was recently removed from python3-gobject-devel: https://src.fedoraproject.org/rpms/pygobject3/c/0eda657eab55405bdbebc6eb3112fcf7dcb517ba?branch=rawhide However, a number of packages still use it, and now FTBFS as a result: accerciser.spec:BuildRequires: pygobject3-devel bolt.spec:BuildRequires: pygobject3-devel gnome-abrt.spec:BuildRequires: pygobject3-devel gnumeric.spec:BuildRequires: pygobject3-devel gom.spec:BuildRequires: pygobject3-devel gst-editing-services.spec:BuildRequires: pygobject3-devel mozo.spec:BuildRequires: pygobject3-devel nautilus-python.spec:BuildRequires: pygobject3-devel nfoview.spec:BuildRequires: pygobject3-devel piper.spec:BuildRequires: pygobject3-devel pluma.spec:BuildRequires: pygobject3-devel python-caja.spec:BuildRequires: pygobject3-devel python-gstreamer1.spec:BuildRequires: pygobject3-devel sugar-toolkit-gtk3.spec:BuildRequires: pygobject3-devel xpra.spec:BuildRequires: pygobject3-devel zbar.spec:BuildRequires: pygobject3-devel This is blocking the F40 rebuild of a number of flatpaks, so I'll provenpackager them soon if not fixed by then. These are now all fixed in rawhide, and in f40 as needed. Thank you to all those who helped. I'll note that at least acceciser was never built for rawhide, I've just done that. Not sure about others. -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [HEADS-UP] openexr so name bump heading Rawhide and f40
On 4/23/24 06:01, Josef Řídký wrote: So far only those two packages were built https://koji.fedoraproject.org/koji/builds?inherited=0=88169=-build_id=1 <https://koji.fedoraproject.org/koji/builds?inherited=0=88169=-build_id=1> E.g. for opencv there has to be libjxl rebuild first. Similarly for others. I've started a jpegxl (libjxl) build here: https://koji.fedoraproject.org/koji/taskinfo?taskID=116776214 On Tue, Apr 23, 2024 at 1:13 PM Tomas Smetana <mailto:tsmet...@redhat.com>> wrote: Dne Mon, 22 Apr 2024 19:02:07 + Gwyn Ciesla via devel mailto:devel@lists.fedoraproject.org>> napsal(a): > I tried to so synfig and gstreamer1-plugins-bad-free, and they need some of > the others rebuilt first: > > https://kojipkgs.fedoraproject.org//work/tasks/2955/116742955/root.log <https://kojipkgs.fedoraproject.org//work/tasks/2955/116742955/root.log> > https://kojipkgs.fedoraproject.org//work/tasks/3027/116743027/root.log <https://kojipkgs.fedoraproject.org//work/tasks/3027/116743027/root.log> > Similar for pfstools: I have not tried to rebuild the packages yet, but they depend on ImageMagick, so unless that one is finished, the build would fail. Is there a way to find out what's been already rebuilt? Thanks and regards, -- Tomáš Smetana -- ___ devel mailing list -- devel@lists.fedoraproject.org <mailto:devel@lists.fedoraproject.org> To unsubscribe send an email to devel-le...@lists.fedoraproject.org <mailto:devel-le...@lists.fedoraproject.org> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ <https://docs.fedoraproject.org/en-US/project/code-of-conduct/> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines <https://fedoraproject.org/wiki/Mailing_list_guidelines> List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org <https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue <https://pagure.io/fedora-infrastructure/new_issue> -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
ld: error: triggering the generation of an executable stack
With a recent update, plplot is failing to build with: cd /builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/examples/fortran && /usr/bin/cmake -E cmake_link_script CMakeFiles/x16af.dir/link.txt --verbose=1 /usr/bin/gfortran -Wl,-z,relro -Wl,--as-needed -Wl,-z,pack-relative-relocs -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld-errors -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1 -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Wno-complain-wrong-lang -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -mtls-dialect=gnu2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -frecursive CMakeFiles/x16af.dir/x16af.f90.o -o x16af -Wl,-rpath,/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/bindings/fortran:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/src:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/lib/csa:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/lib/nn:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/lib/qsastime ../libplfortrandemolib.a ../../bindings/fortran/libplplotfortran.so.0.2.0 -Wl,-rpath-link,/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/src:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/lib/csa:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/lib/nn:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/lib/qsastime /usr/bin/ld: error: /tmp/cchkMGCX.ltrans0.ltrans.o: is triggering the generation of an executable stack (because it has an executable .note.GNU-stack section) /usr/bin/ld: failed to set dynamic section sizes: No such file or directory I have no idea what is up here. Seems to have started with: gcc 14.0.1-0.7.fc41 glibc 2.39.9000-3.fc41 util-linux 2.40-0.9.rc1.fc41 binutils 2.42.50-4.fc41 and lots of others, but that seems the most likely. -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
perl segfault in F40
I'm starting to see this building perl-Alien-CFITSIO in F40 (not rawhide): + cd Alien-CFITSIO-v4.4.0.1 + perl Makefile.PL INSTALLDIRS=vendor NO_PACKLIST=1 NO_PERLLOCAL=1 Alien::Build::Plugin::PkgConfig::Negotiate> Using PkgConfig plugin: PkgConfig::LibPkgConf RPM build errors: I can't reproduce it locally except in mock. Even in mock though if I enter the chroot with a shell and run rpmbuid it works, so I'm guessing its tty related. Is anyone else seeing this? -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Kickstart install of Rawhide fails
On 2/22/24 17:28, Adam Williamson wrote: On Thu, 2024-02-22 at 15:32 -0700, Orion Poplawski wrote: I've seeing: INFO:anaconda.modules.payloads.payload.dnf.transaction_progress:Installed: glibc-common-2.39.9000- 1.fc41.x86_64 1708040026 e4113ddcb7a4bf591492c0bf4644932b0dad7691ff19c65111751675336cb0c8 INFO:anaconda.modules.payloads.payload.dnf.transaction_progress:Installed: bash-5.2.26-3.fc40.x86_64 1707490454 3d71ab445ce95481fcd0b367a2541260323b11cff351df8dc8f88df4a5d928df INFO:anaconda.modules.payloads.payload.dnf.transaction_progress:Configuring (running scriptlet for): bash-5.2.26-3.fc40.x86_64 1707490454 3d71ab445ce95481fcd0b367a2541260323b11cff351df8dc8f88df4a5d928df INFO:anaconda.modules.payloads.payload.dnf.transaction_progress:Installed: dbus-common-1:1.14.10-3.fc40.noarch 1706087027 4501dd43017c1bef93ca8edaae3cbaa501aef60b53e9f7edbe0b5f326d6d471d INFO:anaconda.modules.payloads.payload.dnf.transaction_progress:Configuring (running scriptlet for): dbus-common-1:1.14.10-3.fc40.noarch 1706087027 4501dd43017c1bef93ca8edaae3cbaa501aef60b53e9f7edbe0b5f326d6d471d INFO:dnf.rpm:error: failed to exec scriptlet interpreter /bin/sh: No such file or directory warning: %post(dbus-common-1:1.14.10-3.fc40.noarch) scriptlet failed, exit status 127 ERROR:dnf.rpm:Error in POSTIN scriptlet in rpm package dbus-common ERROR:anaconda.modules.payloads.payload.dnf.transaction_progress:Error in POSTIN scriptlet in rpm package dbus-common But /bin/sh is present and runnable when I try in /mnt/sysroot (the log shows that bash was just installed as well). Anyone else hitting this? Yes, someone else is, when installing in VirtualBox: https://bugzilla.redhat.com/show_bug.cgi?id=2244744 It's confusing, isn't it? Are you using VirtualBox? I think the problem is that bash is getting installed before glibc, presumably due to some kind of circular dep chain that rpm has to break arbitrarily. I don't know how best to determine that though. -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Kickstart install of Rawhide fails
On 2/22/24 17:28, Adam Williamson wrote: On Thu, 2024-02-22 at 15:32 -0700, Orion Poplawski wrote: I've seeing: INFO:anaconda.modules.payloads.payload.dnf.transaction_progress:Installed: glibc-common-2.39.9000- 1.fc41.x86_64 1708040026 e4113ddcb7a4bf591492c0bf4644932b0dad7691ff19c65111751675336cb0c8 INFO:anaconda.modules.payloads.payload.dnf.transaction_progress:Installed: bash-5.2.26-3.fc40.x86_64 1707490454 3d71ab445ce95481fcd0b367a2541260323b11cff351df8dc8f88df4a5d928df INFO:anaconda.modules.payloads.payload.dnf.transaction_progress:Configuring (running scriptlet for): bash-5.2.26-3.fc40.x86_64 1707490454 3d71ab445ce95481fcd0b367a2541260323b11cff351df8dc8f88df4a5d928df INFO:anaconda.modules.payloads.payload.dnf.transaction_progress:Installed: dbus-common-1:1.14.10-3.fc40.noarch 1706087027 4501dd43017c1bef93ca8edaae3cbaa501aef60b53e9f7edbe0b5f326d6d471d INFO:anaconda.modules.payloads.payload.dnf.transaction_progress:Configuring (running scriptlet for): dbus-common-1:1.14.10-3.fc40.noarch 1706087027 4501dd43017c1bef93ca8edaae3cbaa501aef60b53e9f7edbe0b5f326d6d471d INFO:dnf.rpm:error: failed to exec scriptlet interpreter /bin/sh: No such file or directory warning: %post(dbus-common-1:1.14.10-3.fc40.noarch) scriptlet failed, exit status 127 ERROR:dnf.rpm:Error in POSTIN scriptlet in rpm package dbus-common ERROR:anaconda.modules.payloads.payload.dnf.transaction_progress:Error in POSTIN scriptlet in rpm package dbus-common But /bin/sh is present and runnable when I try in /mnt/sysroot (the log shows that bash was just installed as well). Anyone else hitting this? Yes, someone else is, when installing in VirtualBox: https://bugzilla.redhat.com/show_bug.cgi?id=2244744 It's confusing, isn't it? Are you using VirtualBox? No - libvirt kvm on EL7 host. Thanks for the bug link, I've chimed in there. -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Kickstart install of Rawhide fails
I've seeing: INFO:anaconda.modules.payloads.payload.dnf.transaction_progress:Installed: glibc-common-2.39.9000- 1.fc41.x86_64 1708040026 e4113ddcb7a4bf591492c0bf4644932b0dad7691ff19c65111751675336cb0c8 INFO:anaconda.modules.payloads.payload.dnf.transaction_progress:Installed: bash-5.2.26-3.fc40.x86_64 1707490454 3d71ab445ce95481fcd0b367a2541260323b11cff351df8dc8f88df4a5d928df INFO:anaconda.modules.payloads.payload.dnf.transaction_progress:Configuring (running scriptlet for): bash-5.2.26-3.fc40.x86_64 1707490454 3d71ab445ce95481fcd0b367a2541260323b11cff351df8dc8f88df4a5d928df INFO:anaconda.modules.payloads.payload.dnf.transaction_progress:Installed: dbus-common-1:1.14.10-3.fc40.noarch 1706087027 4501dd43017c1bef93ca8edaae3cbaa501aef60b53e9f7edbe0b5f326d6d471d INFO:anaconda.modules.payloads.payload.dnf.transaction_progress:Configuring (running scriptlet for): dbus-common-1:1.14.10-3.fc40.noarch 1706087027 4501dd43017c1bef93ca8edaae3cbaa501aef60b53e9f7edbe0b5f326d6d471d INFO:dnf.rpm:error: failed to exec scriptlet interpreter /bin/sh: No such file or directory warning: %post(dbus-common-1:1.14.10-3.fc40.noarch) scriptlet failed, exit status 127 ERROR:dnf.rpm:Error in POSTIN scriptlet in rpm package dbus-common ERROR:anaconda.modules.payloads.payload.dnf.transaction_progress:Error in POSTIN scriptlet in rpm package dbus-common But /bin/sh is present and runnable when I try in /mnt/sysroot (the log shows that bash was just installed as well). Anyone else hitting this? -- Orion Poplawski he/him/his - surely the least important thing about me Manager of IT Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Need help with incompatible pointer types on i686
On 2/16/24 16:58, Orion Poplawski wrote:
On 2/16/24 01:29, Michael J Gruber wrote:
Am Fr., 16. Feb. 2024 um 07:15 Uhr schrieb Elliott Sales de Andrade
:
On Thu, Feb 15, 2024 at 11:39 PM Orion Poplawski wrote:
We're hitting this with h5py on i686:
/builddir/build/BUILD/h5py-3.10.0/serial/h5py/defs.c: In function
‘__pyx_f_4h5py_4defs_H5Dread_chunk’:
/builddir/build/BUILD/h5py-3.10.0/serial/h5py/defs.c:14922:85: error:
passing argument 4 of ‘H5Dread_chunk’ from incompatible pointer type
[-Wincompatible-pointer-types]
14922 | __pyx_v_r = H5Dread_chunk(__pyx_v_dset_id,
__pyx_v_dxpl_id, __pyx_v_offset, __pyx_v_filters, __pyx_v_buf);
|
^~~
|
|
|
__pyx_t_5numpy_uint32_t * {aka long unsigned
int *}
In file included from /usr/include/hdf5.h:25,
from
/builddir/build/BUILD/h5py-3.10.0/serial/h5py/api_compat.h:27,
from
/builddir/build/BUILD/h5py-3.10.0/serial/h5py/defs.c:1246:
/usr/include/H5Dpublic.h:1003:92: note: expected ‘uint32_t *’ {aka
‘unsigned int *’} but argument is of type ‘__pyx_t_5numpy_uint32_t *’
{aka ‘long unsigned int *’}
1003 | H5_DLL herr_t H5Dread_chunk(hid_t dset_id, hid_t dxpl_id,
const
hsize_t *offset, uint32_t *filters,
|
~~^~~
/builddir/build/BUILD/h5py-3.10.0/serial/h5py/defs.c: In function
‘__pyx_f_4h5py_4defs_H5Pget_driver_info’:
/builddir/build/BUILD/h5py-3.10.0/serial/h5py/defs.c:31935:13: warning:
assignment discards ‘const’ qualifier from pointer target type
[-Wdiscarded-qualifiers]
31935 | __pyx_v_r = H5Pget_driver_info(__pyx_v_plist_id);
| ^
It seems that numpy is defining a uint32_t type as long unsigned int on
i686, while glibc(?) is defining it as unsigned int.
Yes, looking at NumPy's header [1], it appears to check `long` first,
then `long long`, then `int`, then `short`, and assigns the first one
that matches to the matching bit-length. So it should pick unsigned
long for npy_uint32 before unsigned int if they are both 4 bytes wide.
Now what puzzles
me a little is that on i686 aren't these both 4-byte integers and no
not
incompatible at all?
Yes, I think they are the same size, as demonstrated on a 32-bit mock:
They are the same (bit size, signedness, general type) but not equal
(long int vs int), and with gcc14 this became an error. I"m sure it
always warned about that before.
What should be done here?
I guess that depends on how glibc sets things up, but perhaps it would
work better if NumPy checked from smallest to largest as defined in C
(short -> int -> long -> long long)?
[1]
https://github.com/numpy/numpy/blob/308273e94bcf49980be9d5ded2b0ff5b4dd3a897/numpy/_core/include/numpy/npy_common.h#L488
numpy definitely needs to fix this. You cannot just go by bitsize and
signedness. You never could and now you can't ;)
I'm surprised this didn't come up during our "gcc 14 ride".
Michael
Could you or someone else knowledgeable here file a bug with numpy? I'm
sick at the moment and not sure I can articulate what needs to get done.
Thank you!
I have filed https://github.com/numpy/numpy/issues/25869
I'm also exploring just using libc.stdint for the types in h5py.
--
Orion Poplawski
he/him/his - surely the least important thing about me
IT Systems Manager 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/
smime.p7s
Description: S/MIME Cryptographic Signature
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Question about error: inlining failed in call to ‘always_inline’
simdjson is failing to build with GCC 14 on x86_64:
/usr/bin/cmake -S/home/tkloczko/rpmbuild/BUILD/simdjson-3.6.4
-B/home/tkloczko/rpmbuild/BUILD/simdjson-3.6.4/x86_64-redhat-linux-gnu
--check-build-system CMakeFiles/Makefile.cmake 0
/usr/bin/cmake -E cmake_progress_start
/home/tkloczko/rpmbuild/BUILD/simdjson-3.6.4/x86_64-redhat-linux-gnu/CMakeFiles
/home/tkloczko/rpmbuild/BUILD/simdjson-3.6.4/x86_64-redhat-linux-gnu//CMakeFiles/progress.marks
make -f CMakeFiles/Makefile2 all
make[1]: Entering directory
'/home/tkloczko/rpmbuild/BUILD/simdjson-3.6.4/x86_64-redhat-linux-gnu'
make -f CMakeFiles/simdjson.dir/build.make CMakeFiles/simdjson.dir/depend
make[2]: Entering directory
'/home/tkloczko/rpmbuild/BUILD/simdjson-3.6.4/x86_64-redhat-linux-gnu'
cd /home/tkloczko/rpmbuild/BUILD/simdjson-3.6.4/x86_64-redhat-linux-gnu
&& /usr/bin/cmake -E cmake_depends "Unix Makefiles"
/home/tkloczko/rpmbuild/BUILD/simdjson-3.6.4
/home/tkloczko/rpmbuild/BUILD/simdjson-3.6.4
/home/tkloczko/rpmbuild/BUILD/simdjson-3.6.4/x86_64-redhat-linux-gnu
/home/tkloczko/rpmbuild/BUILD/simdjson-3.6.4/x86_64-redhat-linux-gnu
/home/tkloczko/rpmbuild/BUILD/simdjson-3.6.4/x86_64-redhat-linux-gnu/CMakeFiles/simdjson.dir/DependInfo.cmake
"--color="
make[2]: Leaving directory
'/home/tkloczko/rpmbuild/BUILD/simdjson-3.6.4/x86_64-redhat-linux-gnu'
make -f CMakeFiles/simdjson.dir/build.make CMakeFiles/simdjson.dir/build
make[2]: Entering directory
'/home/tkloczko/rpmbuild/BUILD/simdjson-3.6.4/x86_64-redhat-linux-gnu'
[ 50%] Building CXX object CMakeFiles/simdjson.dir/src/simdjson.cpp.o
/usr/bin/g++ -DSIMDJSON_AVX512_ALLOWED=1 -DSIMDJSON_THREADS_ENABLED=1
-DSIMDJSON_UTF8VALIDATION=1 -Dsimdjson_EXPORTS
-I/home/tkloczko/rpmbuild/BUILD/simdjson-3.6.4/include
-I/home/tkloczko/rpmbuild/BUILD/simdjson-3.6.4/src -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
-O2 -g -grecord-gcc-switches -pipe
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -fno-omit-frame-pointer
-mno-omit-leaf-frame-pointer -fdata-sections -ffunction-sections
-fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-flto=auto -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3
-Wp,-D_GLIBCXX_ASSERTIONS -Wall -Werror=format-security -DNDEBUG
-std=c++17 -fPIC -mno-avx256-split-unaligned-load
-mno-avx256-split-unaligned-store -MD -MT
CMakeFiles/simdjson.dir/src/simdjson.cpp.o -MF
CMakeFiles/simdjson.dir/src/simdjson.cpp.o.d -o
CMakeFiles/simdjson.dir/src/simdjson.cpp.o -c
/home/tkloczko/rpmbuild/BUILD/simdjson-3.6.4/src/simdjson.cpp
In file included from
/home/tkloczko/rpmbuild/BUILD/simdjson-3.6.4/src/fallback.cpp:15,
from
/home/tkloczko/rpmbuild/BUILD/simdjson-3.6.4/src/simdjson.cpp:27:
/home/tkloczko/rpmbuild/BUILD/simdjson-3.6.4/src/generic/stage2/json_iterator.h:
In function ‘simdjson::fallback::(anonymous
namespace)::stage2::tape_builder::parse_document(simdjson::fallback::dom_parser_implementation&,
simdjson::dom::document&)simdjson::error_code’:
/home/tkloczko/rpmbuild/BUILD/simdjson-3.6.4/src/generic/stage2/json_iterator.h:119:49:
error: inlining failed in call to ‘always_inline’
‘simdjson::fallback::(anonymous
namespace)::stage2::json_iterator::walk_documentsimdjson::fallback::(anonymous
namespace)::stage2::tape_builder>(simdjson::fallback::(anonymous
namespace)::stage2::tape_builder&)simdjson::error_code’: target specific
option mismatch
119 | simdjson_warn_unused simdjson_inline error_code
json_iterator::walk_document(V ) noexcept {
| ^
In file included from
/home/tkloczko/rpmbuild/BUILD/simdjson-3.6.4/src/fallback.cpp:17:
/home/tkloczko/rpmbuild/BUILD/simdjson-3.6.4/src/generic/stage2/tape_builder.h:105:39:
note: called from here
105 | return iter.walk_document(builder);
| ~^
/home/tkloczko/rpmbuild/BUILD/simdjson-3.6.4/src/generic/stage2/json_iterator.h:119:49:
error: inlining failed in call to ‘always_inline’
‘simdjson::fallback::(anonymous
namespace)::stage2::json_iterator::walk_documentsimdjson::fallback::(anonymous
namespace)::stage2::tape_builder>(simdjson::fallback::(anonymous
namespace)::stage2::tape_builder&)simdjson::error_code’: target specific
option mismatch
119 | simdjson_warn_unused simdjson_inline error_code
json_iterator::walk_document(V ) noexcept {
| ^
/home/tkloczko/rpmbuild/BUILD/simdjson-3.6.4/src/generic/stage2/tape_builder.h:105:39:
note: called from here
105 | return iter.walk_document(builder);
| ~^
make[2]: *** [CMakeFiles/simdjson.dir/build.make:79:
CMakeFiles/simdjson.dir/src/simdjson.cpp.o] Error 1
make[2]: Target 'CMakeFiles/simdjson.dir/build' not remade because of
errors.
I really have no idea how to resolve this.
--
Orion
Re: Need help with incompatible pointer types on i686
On 2/16/24 01:29, Michael J Gruber wrote:
Am Fr., 16. Feb. 2024 um 07:15 Uhr schrieb Elliott Sales de Andrade
:
On Thu, Feb 15, 2024 at 11:39 PM Orion Poplawski wrote:
We're hitting this with h5py on i686:
/builddir/build/BUILD/h5py-3.10.0/serial/h5py/defs.c: In function
‘__pyx_f_4h5py_4defs_H5Dread_chunk’:
/builddir/build/BUILD/h5py-3.10.0/serial/h5py/defs.c:14922:85: error:
passing argument 4 of ‘H5Dread_chunk’ from incompatible pointer type
[-Wincompatible-pointer-types]
14922 | __pyx_v_r = H5Dread_chunk(__pyx_v_dset_id,
__pyx_v_dxpl_id, __pyx_v_offset, __pyx_v_filters, __pyx_v_buf);
|
^~~
|
|
|
__pyx_t_5numpy_uint32_t * {aka long unsigned int *}
In file included from /usr/include/hdf5.h:25,
from
/builddir/build/BUILD/h5py-3.10.0/serial/h5py/api_compat.h:27,
from
/builddir/build/BUILD/h5py-3.10.0/serial/h5py/defs.c:1246:
/usr/include/H5Dpublic.h:1003:92: note: expected ‘uint32_t *’ {aka
‘unsigned int *’} but argument is of type ‘__pyx_t_5numpy_uint32_t *’
{aka ‘long unsigned int *’}
1003 | H5_DLL herr_t H5Dread_chunk(hid_t dset_id, hid_t dxpl_id, const
hsize_t *offset, uint32_t *filters,
|
~~^~~
/builddir/build/BUILD/h5py-3.10.0/serial/h5py/defs.c: In function
‘__pyx_f_4h5py_4defs_H5Pget_driver_info’:
/builddir/build/BUILD/h5py-3.10.0/serial/h5py/defs.c:31935:13: warning:
assignment discards ‘const’ qualifier from pointer target type
[-Wdiscarded-qualifiers]
31935 | __pyx_v_r = H5Pget_driver_info(__pyx_v_plist_id);
| ^
It seems that numpy is defining a uint32_t type as long unsigned int on
i686, while glibc(?) is defining it as unsigned int.
Yes, looking at NumPy's header [1], it appears to check `long` first,
then `long long`, then `int`, then `short`, and assigns the first one
that matches to the matching bit-length. So it should pick unsigned
long for npy_uint32 before unsigned int if they are both 4 bytes wide.
Now what puzzles
me a little is that on i686 aren't these both 4-byte integers and no not
incompatible at all?
Yes, I think they are the same size, as demonstrated on a 32-bit mock:
They are the same (bit size, signedness, general type) but not equal
(long int vs int), and with gcc14 this became an error. I"m sure it
always warned about that before.
What should be done here?
I guess that depends on how glibc sets things up, but perhaps it would
work better if NumPy checked from smallest to largest as defined in C
(short -> int -> long -> long long)?
[1]
https://github.com/numpy/numpy/blob/308273e94bcf49980be9d5ded2b0ff5b4dd3a897/numpy/_core/include/numpy/npy_common.h#L488
numpy definitely needs to fix this. You cannot just go by bitsize and
signedness. You never could and now you can't ;)
I'm surprised this didn't come up during our "gcc 14 ride".
Michael
Could you or someone else knowledgeable here file a bug with numpy? I'm
sick at the moment and not sure I can articulate what needs to get done.
Thank you!
--
Orion Poplawski
he/him/his - surely the least important thing about me
IT Systems Manager 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/
smime.p7s
Description: S/MIME Cryptographic Signature
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Need help with incompatible pointer types on i686
We're hitting this with h5py on i686:
/builddir/build/BUILD/h5py-3.10.0/serial/h5py/defs.c: In function
‘__pyx_f_4h5py_4defs_H5Dread_chunk’:
/builddir/build/BUILD/h5py-3.10.0/serial/h5py/defs.c:14922:85: error:
passing argument 4 of ‘H5Dread_chunk’ from incompatible pointer type
[-Wincompatible-pointer-types]
14922 | __pyx_v_r = H5Dread_chunk(__pyx_v_dset_id,
__pyx_v_dxpl_id, __pyx_v_offset, __pyx_v_filters, __pyx_v_buf);
|
^~~
|
|
|
__pyx_t_5numpy_uint32_t * {aka long unsigned int *}
In file included from /usr/include/hdf5.h:25,
from
/builddir/build/BUILD/h5py-3.10.0/serial/h5py/api_compat.h:27,
from
/builddir/build/BUILD/h5py-3.10.0/serial/h5py/defs.c:1246:
/usr/include/H5Dpublic.h:1003:92: note: expected ‘uint32_t *’ {aka
‘unsigned int *’} but argument is of type ‘__pyx_t_5numpy_uint32_t *’
{aka ‘long unsigned int *’}
1003 | H5_DLL herr_t H5Dread_chunk(hid_t dset_id, hid_t dxpl_id, const
hsize_t *offset, uint32_t *filters,
|
~~^~~
/builddir/build/BUILD/h5py-3.10.0/serial/h5py/defs.c: In function
‘__pyx_f_4h5py_4defs_H5Pget_driver_info’:
/builddir/build/BUILD/h5py-3.10.0/serial/h5py/defs.c:31935:13: warning:
assignment discards ‘const’ qualifier from pointer target type
[-Wdiscarded-qualifiers]
31935 | __pyx_v_r = H5Pget_driver_info(__pyx_v_plist_id);
| ^
It seems that numpy is defining a uint32_t type as long unsigned int on
i686, while glibc(?) is defining it as unsigned int. Now what puzzles
me a little is that on i686 aren't these both 4-byte integers and no not
incompatible at all?
What should be done here?
--
Orion Poplawski
he/him/his - surely the least important thing about me
IT Systems Manager 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/
smime.p7s
Description: S/MIME Cryptographic Signature
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Is Yatin Karel still around?
See https://bugzilla.redhat.com/show_bug.cgi?id=2048204 no activity for over two years. -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: suitesparse update/soname bump coming this weekend
Update has been submitted: https://bodhi.fedoraproject.org/updates/FEDORA-2024-a8ac931a22 Everything has been rebuilt except for julia which seems to be FTBFS due to tests never completing. On 2/1/24 17:48, Orion Poplawski wrote: I will be updating suitesparse to 7.6.0 with a new cmake build system. This is also a soname bump and I'll be rebuilding the deps in a side-tag. $ fedrq whatrequires suitesparse -F source ceres-solver coin-or-Clp freefem++ gegl04 glpk libpano13 naev octave psblas3 python-cvxopt qrmumps suitesparse sundials superlu_dist -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
suitesparse update/soname bump coming this weekend
I will be updating suitesparse to 7.6.0 with a new cmake build system. This is also a soname bump and I'll be rebuilding the deps in a side-tag. $ fedrq whatrequires suitesparse -F source ceres-solver coin-or-Clp freefem++ gegl04 glpk libpano13 naev octave psblas3 python-cvxopt qrmumps suitesparse sundials superlu_dist -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Orphaning bes
I've orphaned bes. I never really used it, and I don't think anything depends on it in Fedora. -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: List of long term FTBFS packages to be retired in February
On 1/24/24 13:05, Miro Hrončok wrote: On 24. 01. 24 19:00, Ralf Corsépius wrote: Am 24.01.24 um 17:38 schrieb Miro Hrončok: Package (co)maintainers freefem++ (maintained by: cicku, corsepiu) freefem++-openmpi-4.14-3.fc40.x86_64 requires libmpi.so.40()(64bit)(openmpi-x86_64) WTH is this? Your script seems broken. This is a 2-level deep dependency on a package that fails to build. Thanks for your feedback. Occasionally, "my" script is broken, but what you reported is not actually incorrect. See further. nor did it fail to build. It did not. It depends on openmpi which depends on infinipath-psm which fails to build. The openmpi dependency on infinipath-psm was vestigial and has been removed with openmpi-5.0.1-3.fc40. -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Review swaps for deps needed for conda update
On 12/2/23 19:32, Orion Poplawski wrote: I have a number of packages needing review that are required for the latest round of updates to the conda package manager: https://bugzilla.redhat.com/buglist.cgi?bug_id=2025802_id_type=anddependson=tvp_id=13378412# I'm particularly excited by libmamba and its micromamba package/executable as a faster/leaner replacement for conda itself. Just for the record - Jerry James picked up the reviews. Big shout out for that! -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Review swaps for deps needed for conda update
I have a number of packages needing review that are required for the latest round of updates to the conda package manager: https://bugzilla.redhat.com/buglist.cgi?bug_id=2025802_id_type=anddependson=tvp_id=13378412# I'm particularly excited by libmamba and its micromamba package/executable as a faster/leaner replacement for conda itself. I think I have some bandwidth now to do some reviews in exchange. Thanks. -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [HEADS UP] Jasper update with .so name update
On 11/27/23 13:31, Adam Williamson wrote: On Tue, 2023-11-21 at 10:55 +0100, Josef Řídký wrote: Hi, there is a new jasper version (4.1.0) that will be available in Fedora 40+. As this version is bumping it's .so name, the rebuild of the dependent package will be necessary. There is a side tag created for safe rebuild of those packages (f40-build-side-77302) with a new jasper version available. I would like to ask maintainers of affected packages to rebuild their packages using this tag, so I will be able to push the update to f40 once all is done. List of affected packages is: - eccodes-devel - g2clib-devel - grib_api-devel Somehow your list is far too short: [adamw@xps13a tmp]$ sudo dnf repoquery --whatrequires "libjasper.so.6()(64bit)" DevIL-0:1.7.8-42.fc39.x86_64 DevIL-ILUT-0:1.7.8-42.fc39.x86_64 GraphicsMagick-0:1.3.40-3.fc39.x86_64 LibRaw-0:0.21.1-6.fc40.x86_64 OpenSceneGraph-libs-0:3.6.5-19.fc40.x86_64 dcraw-0:9.28.0-20.fc39.x86_64 digikam-libs-0:8.1.0-3.fc39.x86_64 eccodes-0:2.32.1-1.fc40.x86_64 gegl04-0:0.4.46-1.fc40.x86_64 grib_api-0:1.27.0-19.fc39.x86_64 jasper-0:3.0.6-4.fc39.x86_64 jasper-devel-0:3.0.6-4.fc39.x86_64 jasper-utils-0:3.0.6-4.fc39.x86_64 kdelibs-6:4.14.38-40.fc40.x86_64 kdelibs3-0:3.5.10-123.fc40.x86_64 libicns-0:0.8.1-27.fc39.x86_64 ncl-0:6.6.2-38.fc40.x86_64 netpbm-progs-0:11.02.00-2.fc39.x86_64 qt5-qtimageformats-0:5.15.11-1.fc40.x86_64 qt6-qtimageformats-0:6.6.0-1.fc40.x86_64 wgrib2-0:3.1.3-1.fc40.x86_64 the update failed gating because of qt5-qtimageformats, but all the others also ought to be rebuilt onto the side tag before this is pushed. I've built most of these and working on the rest - but I think we're bumping into a qt6 update at the same time. Pinging maintainers here. Other issues: kdelibs/kdelibs3 are FTBFS -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
/usr/bin/pterm conflicts
prrte 3.0 introduces /usr/bin/pterm which conflicts with putty. Issues: https://github.com/openpmix/prrte/issues/1836 https://bugzilla.redhat.com/show_bug.cgi?id=2247407 If anyone has any constructive comments, it would be appreciated. Orion -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Basic pyproject-rpm-macros now in EPEL8
EPEL8 now has a stripped down version of pyproject-rpm-macros. Notably, it does NOT support/provide %pyproject_generate_buildrequires, but it does support the basic build/install related macros. Also note that this only supports building with python 3.8+. -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Forester project - Anaconda kickstart with Redfish
On 10/30/23 06:30, Lukas Zapletal wrote: Hello, I would love to introduce you the Forester project: unattended bare-metal image-based Anaconda installation service. Forester provides unattended bare-metal installation network boot workflow for Fedora, Red Hat or compatible OS images created by Image Builder. It utilizes modern technologies like UEFI HTTP Boot, Redfish, Anaconda, SecureBoot and X509 for fast and secure image-based OS installations. Forester is a simple service with REST/RPC API and CLI. The project is currently in early development and I am looking for feedback of any form. For more info, demo recording and documentation, head over to: https://foresterorg.github.io/ I would also like to create a mailing list and since the project is related to both Fedora and Anaconda, I was thinking to apply for project membership under the Fedora family. Can someone help me with that? I was trying to find some more info about the formal process on Fedora wiki pages without much success. Thanks! Later. -- lzap Could you do some compare and contrast with cobbler? https://github.com/cobbler/cobbler Because what I would really like to see is more people helping out with cobbler development. -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [Scitech] Re: openmpi 5.0.0 update coming - drops i686 and C++ API
Nothing beyond the normal. openmpi 5.0 was just released so we're probably a bit out in front (although there have been RCs for almost a year). On 10/30/23 08:01, Morgan Hough wrote: Hi Orion, Is there any particular testing you would like to see done with this? Are there projects that are using 5.0 at this point? Thanks so much for your time. Cheers, -Morgan On Mon, Oct 30, 2023 at 6:49 AM Orion Poplawski wrote: On 10/28/23 13:36, Orion Poplawski wrote: I'm going to start building openmpi 5.0.0 and its requirements (pmix 4.2.7, prrte 3.0.2) and dependencies in a side-tag starting tomorrow. Notable changes are: * Dropping support for 32-bit * Dropping support for C++ API * Change in the environment variable to allow oversubscription (running with more processes than available cores) I will be making changes to dependent packages to address these changes. I've been rebuilding deps in COPR (https://copr.fedorainfracloud.org/coprs/orion/pmix-4.2/builds/) and most rebuild fine. One exception is MUSIC which depends on the C++ API. There is a longstanding upstream issue to address this. Hopefully this will finally get dealt with. There are no soname bumps, but pmix has proved problematic in the past but its deps will be rebuilt. The side tag has been merged. I rebuilt all packages that depended on libmpi_cxx.so - except MUSIC which needs upstream to drop it's requirement on the C++ API. Other OpenMPI deps may now be FTBFS/FTI due to the lack of openmpi on i686 but packagers can deal with that on their own schedule. koschei will not detect this but perhaps the FTI check will. Finally, the new method for allowing over-subscription is: PRTE_MCA_rmaps_default_mapping_policy=:oversubscribe Orion -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ ___ scitech mailing list -- scit...@lists.fedoraproject.org To unsubscribe send an email to scitech-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/scit...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue ___ scitech mailing list -- scit...@lists.fedoraproject.org To unsubscribe send an email to scitech-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/scit...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: openmpi 5.0.0 update coming - drops i686 and C++ API
On 10/28/23 13:36, Orion Poplawski wrote: I'm going to start building openmpi 5.0.0 and its requirements (pmix 4.2.7, prrte 3.0.2) and dependencies in a side-tag starting tomorrow. Notable changes are: * Dropping support for 32-bit * Dropping support for C++ API * Change in the environment variable to allow oversubscription (running with more processes than available cores) I will be making changes to dependent packages to address these changes. I've been rebuilding deps in COPR (https://copr.fedorainfracloud.org/coprs/orion/pmix-4.2/builds/) and most rebuild fine. One exception is MUSIC which depends on the C++ API. There is a longstanding upstream issue to address this. Hopefully this will finally get dealt with. There are no soname bumps, but pmix has proved problematic in the past but its deps will be rebuilt. The side tag has been merged. I rebuilt all packages that depended on libmpi_cxx.so - except MUSIC which needs upstream to drop it's requirement on the C++ API. Other OpenMPI deps may now be FTBFS/FTI due to the lack of openmpi on i686 but packagers can deal with that on their own schedule. koschei will not detect this but perhaps the FTI check will. Finally, the new method for allowing over-subscription is: PRTE_MCA_rmaps_default_mapping_policy=:oversubscribe Orion -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
openmpi 5.0.0 update coming - drops i686 and C++ API
I'm going to start building openmpi 5.0.0 and its requirements (pmix 4.2.7, prrte 3.0.2) and dependencies in a side-tag starting tomorrow. Notable changes are: * Dropping support for 32-bit * Dropping support for C++ API * Change in the environment variable to allow oversubscription (running with more processes than available cores) I will be making changes to dependent packages to address these changes. I've been rebuilding deps in COPR (https://copr.fedorainfracloud.org/coprs/orion/pmix-4.2/builds/) and most rebuild fine. One exception is MUSIC which depends on the C++ API. There is a longstanding upstream issue to address this. Hopefully this will finally get dealt with. There are no soname bumps, but pmix has proved problematic in the past but its deps will be rebuilt. -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: OpenSlide soname bump in Rawhide
vtk build submitted:
https://koji.fedoraproject.org/koji/taskinfo?taskID=107377295
Orion
On 10/11/23 16:17, Benjamin Gilbert
wrote:
Hi,
OpenSlide 4.0.0 includes a soname bump to
libopenslide.so.1. The API changes [1] are unlikely to cause
issues: they remove functions deprecated since 2014 and change
the behavior of some obscure corner cases.
These packages are affected:
vips
vtk
Please submit rebuilds in the side tag
"f40-build-side-75382".
Thanks!
--Benjamin Gilbert
[1]: https://github.com/openslide/openslide/blob/v4.0.0/CHANGELOG.md#breaking-changes
--
Orion Poplawski
IT Systems Manager 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/
smime.p7s
Description: S/MIME Cryptographic Signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Need help with conda package - launcher script
On 10/8/23 16:06, Elliott Sales de Andrade wrote: On Sun, Oct 8, 2023 at 10:20 AM Orion Poplawski wrote: With the update to conda 23.5.2 and using the pyproject macros, the conda package is no longer producing the /usr/bin/conda-env launcher script which is causing problems. What problems specifically? I don't know how I can get that back with the current build system. Any help would be greatly appreciated. Upstream appears to have changed to hatch, and there's no entry for a conda-env script [1], so it's up to them, and is either intentional or an oversight. And given [2], it doesn't appear that `conda-env` has much life left, so it seems intentional. But in any case, it seems like something you should confirm with upstream. Thanks. -- Orion Poplawski [1] https://github.com/conda/conda/commit/0a255799567ba28f421a1fe7309c5336cbcdbf0a#diff-50c86b7ed8ac2cf95bd48334961bf0530cdc77b5a56f852c5c61b89d735fd711R50-R51 [2] https://github.com/conda/conda/commit/da31c933fec50e7242f3ecb4b90e586bd3861a2b Thanks. Figured out that the new location in pyproject.toml is in [project.scripts] and re-added conda-env to that and reset conda to the regular conda main. Upstream expects one to install a separate conda-env package into the environment. Upstream doesn't really support the mode we are using with Fedora, so we have to do some tweaking. -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Need help with conda package - launcher script
With the update to conda 23.5.2 and using the pyproject macros, the conda package is no longer producing the /usr/bin/conda-env launcher script which is causing problems. I don't know how I can get that back with the current build system. Any help would be greatly appreciated. Thanks. -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Review plea - x2gokdrive
Could someone (perhaps someone interested in X2Go) please review: https://bugzilla.redhat.com/show_bug.cgi?id=2215420 https://bugzilla.redhat.com/show_bug.cgi?id=2215421 I'd love to be able to offer a review swap, but I'm completely underwater. If anyone wants to help out on any of my packages, that would be great. I'm led to believe by https://pagure.io/pagure/blob/master/f/doc/usage/tips_tricks.rst that this[1] should show the packages that I am the primary maintainer on, but it doesn't seem to be working. 1 - https://src.fedoraproject.org/user/orion?acl=main%20admin Thanks. -- Orion Poplawski IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Exclude i686 builders for noarch packages
I'm running into an issue where python-rpds-py excludes i686:
# https://fedoraproject.org/wiki/Changes/EncourageI686LeafRemoval
# Also rust-rpds is not available on i686
ExcludeArch:%{ix86}
but then my python-nbformat build gets sent to an i686 builder and fails
because python3-rpds-py is not available:
https://koji.fedoraproject.org/koji/taskinfo?taskID=105847966
It seems annoying to have to propagate the ExcludeArch up the stack for
this.
Thoughts?
--
Orion Poplawski
he/him/his - surely the least important thing about me
IT Systems Manager 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/
smime.p7s
Description: S/MIME Cryptographic Signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Should we provide current/previous release links in URLs?
As part of the cobbler project testing, we need to test accessing Fedora releases with various URLs: "http://download.fedoraproject.org/pub/fedora/linux/releases/35/Everything/x86_64/os;, "https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-35=x86_64; "https://mirrors.fedoraproject.org/metalink?repo=fedora-35=x86_64;, These need to get updated continuously as Fedora progresses. Could we perhaps have a "current" and "previous" (or similar) that tracks the most recent and previous release? -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Releasing package updates in multiple Fedora releases
On 6/18/23 04:28, Adam Williamson wrote:
On Sun, 2023-06-18 at 09:16 +, Mattia Verga via devel wrote:
For the 99% of packages I maintain I usually perform the same workflow
when updating them:
1. Update spec and source in Rawhide
2. commit and push
3. fedpkg build
4. fedpkg switch-branch f*
5. git merge rawhide
6. push and fedpkg build
And repeat 4-5-6 for every f*/epel* branches where I want to push the
update.
This is quite boring and time wasting... is there a more efficient way
to use my packaging time? Do you think fedpkg can be enhanced to have a
single command which makes 4-5-6 to all specified branches?
I have this in my command history:
for i in f37 f38 rawhide; do fedpkg switch-branch $i; git pull; git merge
rawhide; fedpkg push; fedpkg build --nowait; done
Similar:
In my .bashrc:
fpbr() { for rel in $*; do fedpkg switch-branch $rel; git merge rawhide
&& git push && fedpkg build --nowait; done; }
You're addition of git pull is a good thing.
--
Orion Poplawski
he/him/his - surely the least important thing about me
IT Systems Manager 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/
smime.p7s
Description: S/MIME Cryptographic Signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: [HEADS UP] Fedora 39 Python 3.12 rebuilds to start in a side tag this week
On 6/17/23 03:50, Miro Hrončok wrote: On 13. 06. 23 14:02, Tomas Hrnciar wrote: Hello, in order to deliver Python 3.12, we are running a coordinated rebuild in a side tag. https://fedoraproject.org/wiki/Changes/Python3.12 <https://fedoraproject.org/wiki/Changes/Python3.12> We anticipate starting this rebuildsometimethis week. If you see a "Rebuilt for Python 3.12" (or similar) commit in your package, please don't rebuild it in regular rawhideor another rawhide side tag. If you need to, please let us know, so we can coordinate. If you'd like to build apackageafter we already rebuilt it, you should be able to build it in the side tag via: on branch rawhide: $ fedpkg build --target=f39-python $ koji wait-repo f39-python --build Note that it will take a while before all the essential packages are rebuilt, so don't expect all your dependencies to be available right away. Please, don't attempt to build your package in the side tag before we do. When in trouble, ask here or on IRC (#fedora-python on Libera.Chat). Ping me (thrnciar) or Miro (mhroncok) if you need to talk to us. Builds: https://koji.fedoraproject.org/koji/builds?latest=0=f39-python=-build_id=0 <https://koji.fedoraproject.org/koji/builds?latest=0=f39-python=-build_id=0> Please avoid any potentially disturbing or major changes in Python packages until the rebuild is over. Thanks. Let us know if you have any questions. Hey folks, apologies if you have missed our announcement, but I'd like to ask you not to build packages in rawhide if they have received a "Rebuilt for Python 3.12" commit. For details, see the announcement quoted above. The following packages have been rebuilt in rawhide after we have rebuilt them in the f39-python side tag and I will now bump them again and build them again in f39-python: python-google-api-core python-radexreader Please avoid further rawhide builds of them until the side tag is merged. Thanks and sorry for the trouble. Do we have an ETA on the merge? Just wondering. Thanks. -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Trying to strip a library automatically
On 6/1/23 23:00, Paul Grosu wrote:
Hi Orion,
There are two ways to remove the debugging symbols:
1) strip --strip-debug your_library.so
2) objcopy --strip-debug your_library.so
Below is an example of both approaches:
1) Method using strip:
paul$ objdump --syms libfoo.so | grep debug
l d .debug_aranges
.debug_aranges
l d .debug_info
.debug_info
l d .debug_abbrev
.debug_abbrev
l d .debug_line
.debug_line
l d .debug_str
.debug_str
paul$ strip --strip-debug libfoo.so
paul$ objdump --syms libfoo.so | grep debug
paul$
2) Method using objdump:
paul$ objdump --syms libfoo.so | grep debug
l d .debug_aranges
.debug_aranges
l d .debug_info
.debug_info
l d .debug_abbrev
.debug_abbrev
l d .debug_line
.debug_line
l d .debug_str
.debug_str
paul$ objcopy --strip-debug libfoo.so
paul$ objdump --syms libfoo.so | grep debug
paul$
Are there other symbols you are looking to strip?
Hope it helps,
Paul
So I'm afraid my subject isn't the best - I'm really wondering why the
library isn't being stripped automatically and debug info collected by
RPM as I would expect.
But your answer pointed me towards using objdump --syms to verify that
the debug info has been removed, not the output of "file". Thanks!
On Fri, Jun 2, 2023 at 12:11 AM Orion Poplawski <mailto:or...@nwra.com>> wrote:
I'm trying to resolve this packaging issue with Lmod:
https://artifacts.dev.testing-farm.io/4d7bee41-8d21-42fb-8c57-e5ffbf58119f/
<https://artifacts.dev.testing-farm.io/4d7bee41-8d21-42fb-8c57-e5ffbf58119f/>
debuginfo
BAD /usr/share/lmod/8.7.25/lib/tcl2lua.so in Lmod-8.7.25-2.fc38 on i686
contains debugging symbols
I've dealt with a couple of issues here:
https://src.fedoraproject.org/rpms/Lmod/pull-request/2
<https://src.fedoraproject.org/rpms/Lmod/pull-request/2>
but despite all of my attempts the library does not appear to get
stripped.
In fact:
]$ strip -g
/home/orion/BUILDROOT/Lmod-8.7.25-3.fc39.x86_64/usr/lib64/lmod/tcl2lua.so.1.0.1
$ file
/home/orion/BUILDROOT/Lmod-8.7.25-3.fc39.x86_64/usr/lib64/lmod/tcl2lua.so.1.0.1
/home/orion/BUILDROOT/Lmod-8.7.25-3.fc39.x86_64/usr/lib64/lmod/tcl2lua.so.1.0.1:
ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically
linked, BuildID[sha1]=aa1ea44979190d0cf530d350f8151ffafeab0f36, not
stripped
?
--
Orion Poplawski
he/him/his - surely the least important thing about me
IT Systems Manager 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane or...@nwra.com <mailto:or...@nwra.com>
Boulder, CO 80301 https://www.nwra.com/ <https://www.nwra.com/>
___
devel mailing list -- devel@lists.fedoraproject.org
<mailto:devel@lists.fedoraproject.org>
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
<mailto:devel-le...@lists.fedoraproject.org>
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
<https://docs.fedoraproject.org/en-US/project/code-of-conduct/>
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
<https://fedoraproject.org/wiki/Mailing_list_guidelines>
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
<https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org>
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
<https://pagure.io/fedora-infrastructure/new_issue>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
--
Orion Poplawski
he/him/his - surely the least important thing about me
IT Systems Manager 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane or...@nwra.com
Boulder,
Trying to strip a library
I'm trying to resolve this packaging issue with Lmod: https://artifacts.dev.testing-farm.io/4d7bee41-8d21-42fb-8c57-e5ffbf58119f/ debuginfo BAD /usr/share/lmod/8.7.25/lib/tcl2lua.so in Lmod-8.7.25-2.fc38 on i686 contains debugging symbols I've dealt with a couple of issues here: https://src.fedoraproject.org/rpms/Lmod/pull-request/2 but despite all of my attempts the library does not appear to get stripped. In fact: ]$ strip -g /home/orion/BUILDROOT/Lmod-8.7.25-3.fc39.x86_64/usr/lib64/lmod/tcl2lua.so.1.0.1 $ file /home/orion/BUILDROOT/Lmod-8.7.25-3.fc39.x86_64/usr/lib64/lmod/tcl2lua.so.1.0.1 /home/orion/BUILDROOT/Lmod-8.7.25-3.fc39.x86_64/usr/lib64/lmod/tcl2lua.so.1.0.1: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=aa1ea44979190d0cf530d350f8151ffafeab0f36, not stripped ? -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Bypassing setuptools_scm
Is there a canonical way to bypass setuptools_scm? Sometimes one would like to build from a github tarball (e.g. for test data) but then setuptool_scm fails to detect a version. -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: dnf5 and file level provides
On 5/25/23 21:28, Chris Adams wrote: Once upon a time, Orion Poplawski said: I can't find any discussion of this - but is it expected that dnf5 does not handle file level provides outside of specific directories? Packages are not supposed to depend on files/directories outside /usr/bin, /usr/sbin, and /etc (or paths in explicit Provides:), although that restriction is a SHOULD, not MUST. So unless that's changing, dnf5 needs to still be able to download the filelists repodata. Thanks. This seems to have been reported here: https://github.com/rpm-software-management/dnf5/issues/520 -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
dnf5 and file level provides
I can't find any discussion of this - but is it expected that dnf5 does not handle file level provides outside of specific directories? $ dnf5 repoquery --whatprovides /usr/share/dict/words Updating and loading repositories: Repositories loaded. $ dnf repoquery --whatprovides /usr/share/dict/words Last metadata expiration check: 0:04:26 ago on Thu 25 May 2023 09:02:26 PM MDT. words-0:3.0-43.fc39.noarch $ dnf5 upgrade ... Problem 15: cannot install both words-3.0-41.fc38.noarch and words-3.0-43.fc39.noarch - package krb5-server-1.20.1-9.fc39.x86_64 requires /usr/share/dict/words, but none of the providers can be installed - cannot install the best update candidate for package words-3.0-41.fc38.noarch - cannot install the best update candidate for package krb5-server-1.20.1-9.fc39.x86_64 -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
How to set SCM date in %autorelease
I've got the following:
%global goipath github.com/dustin/gomemcached
%global commit a2284a01c143e355985d192edf3b62a053747c70
%global shortcommit %(c=%{commit}; echo ${c:0:7})
%gometa -f
%global common_description %{expand:
A memcached binary protocol toolkit for go.}
%global golicenses LICENSE
%global godocs README.markdown example
Name: %{goname}
Version:0
Release:%autorelease -p
Summary:A memcached binary protocol toolkit for go
Which gives me:
Release:0.1.20230224gita2284a0.fc39
Looks like 20230224 is coming from the date of the tarball. I want to
set the date to the date of the last upstream commit - 20160816.
https://docs.pagure.org/Fedora-Infra.rpmautospec/autorelease.html#traditional-versioning-with-part-of-the-upstream-version-information-in-the-release-field
indicates that I should be able to use -s to set the part of
the release tag, so I do:
Release:%autorelease -p -s 20160816git%{shortcommit}
but that gives me:
Release:0.1.20160816gita2284a0.20230224gita2284a0.fc39
So, how do I override the SCM date?
--
Orion Poplawski
he/him/his - surely the least important thing about me
IT Systems Manager 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/
smime.p7s
Description: S/MIME Cryptographic Signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: HEADS UP: gdal-3.7.0 coming to rawhide
On 5/12/23 04:38, Sandro Mani wrote: On 11.05.23 05:42, Sandro Mani wrote: Hi I'm preparing the gdal-3.7.0 update which carries a soname bump. Il build it in the f39-build-side-67536 side-tag, and rebuild the following dependencies: GMT mapserver liblas python-fiona postgis merkaartor R-rgdal bes saga qmapshack PDAL ncl vfrnav python-rasterio vtk paraview kealib OpenSceneGraph cloudcompare grass mapnik opencv mingw-opencv osgearth qgis gazebo This is now done, all completed except for: vfrnav: preexisting FTBFS mingw-opencv: mingw related issue, need to investigate Sandro Well, not completely - my paraview build in the side tag has not yet completed: https://koji.fedoraproject.org/koji/taskinfo?taskID=101035225 Do I submit a separate update for that once it is done? -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: mingw pkgconfig reqs/provides
On 5/5/23 10:20, Neal Gompa wrote: On Fri, May 5, 2023 at 11:14 AM Orion Poplawski wrote: I've submitted a test version of autogenerating mingw pkgconfig provides and reqs here: https://github.com/rpm-software-management/rpm/pull/2504 This generates provides like: Provides: mingw32(libtiff-5.dll) mingw32(libtiffxx-5.dll) mingw32-libtiff = 4.4.0-2.fc39 mingw32-pkgconfig(libtiff-4) = 4.4.0 Provides: mingw64(libtiff-5.dll) mingw64(libtiffxx-5.dll) mingw64-libtiff = 4.4.0-2.fc39 mingw64-pkgconfig(libtiff-4) = 4.4.0 I think it would probably make sense to have that as part of the mingw-filesystem package for each mingw type (w32, ucrt, w64, etc.) rather than in the rpm pkgconfigdeps generator upstream. Otherwise it's a great idea! Thanks for the info. Filed https://src.fedoraproject.org/rpms/mingw-filesystem/pull-request/11 I think we'll need to run for a release before adding the corresponding requires (if desired). -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Questions about qmake static libraries
On 5/5/23 22:30, Orion Poplawski wrote:
On 5/5/23 21:31, Orion Poplawski wrote:
I'm just starting to look into the mingw packages and building mingw
executables with them - and in particular static building. I'm hoping
someone can clarify some things for me.
For "regular" libs we seem to have:
%{mingw32_bindir}/libexample-0.dll
%{mingw32_libdir}/libexample.dll.a
and for static libs:
%{mingw32_libdir}/libexample.a
so for example:
-rw-r--r--. 1 root root 7539008 Apr 11 18:00
/usr/i686-w64-mingw32/sys-root/mingw/bin/Qt5Gui.dll
-rw-r--r--. 1 root root 13373318 Apr 11 18:00
/usr/i686-w64-mingw32/sys-root/mingw/lib/libQt5Gui.a
-rw-r--r--. 1 root root 6699310 Apr 11 18:00
/usr/i686-w64-mingw32/sys-root/mingw/lib/libQt5Gui.dll.a
/usr/i686-w64-mingw32/sys-root/mingw/bin/Qt5Gui.dll: PE32
executable (DLL) (GUI) Intel 80386, for MS Windows, 12 sections
/usr/i686-w64-mingw32/sys-root/mingw/lib/libQt5Gui.dll.a: current ar
archive
/usr/i686-w64-mingw32/sys-root/mingw/lib/libQt5Gui.a: current ar
archive
From what I've gleaned from some web searches is that the .dll.a file
is an "import" library which seems to encode a dependency on the .dll
library at runtime, while the plain .a file is a more "normal" static
library.
So to link a static executable it looks like I want to be using
libQt5Gui.a. However, when attempting to build the x2goclient
executable I'm ending up with the following link line:
i686-w64-mingw32-g++ -g -fstack-protector -static -static-libstdc++
-static-libgcc -Wl,-subsystem,windows -mthreads -o
release/x2goclient.exe @object_script.x2goclient.Release -lssh.dll
-lwinspool /usr/i686-w64-mingw32/sys-root/mingw/lib/libQt5Svg.dll.a
/usr/i686-w64-mingw32/sys-root/mingw/lib/libQt5Widgets.dll.a
/usr/i686-w64-mingw32/sys-root/mingw/lib/libQt5Gui.dll.a -lgdi32
-lcomdlg32 -loleaut32 -limm32 -luxtheme -ljpeg -lpng -lharfbuzz
/usr/i686-w64-mingw32/sys-root/mingw/lib/libQt5Network.dll.a -lcrypt32
-ldnsapi -liphlpapi
/usr/i686-w64-mingw32/sys-root/mingw/lib/libQt5Core.dll.a -lz
-lpcre2-16 -lversion -lole32 -luuid -lwinmm -lws2_32 -ladvapi32
-lshell32 -luser32 -lkernel32 -lnetapi32 -luserenv -liconv
release/x2goclient_res.o -lmingw32
/usr/i686-w64-mingw32/sys-root/mingw/lib/libqt5main.a -lshell32
with lots of references to the .dll.a files. And from what I can
tell, the x2goclient.exe executable does appear to have runtime
dependencies on the various Qt dlls (e.g. Qt5Gui.dll, etc.).
I’m specifying a static config to qmake and QT is specified in the
x2goclient.pro simply with:
QT += svg network
So I really have no idea where the .dll.a references are coming from.
Some possibilities:
/usr/i686-w64-mingw32/sys-root/mingw/lib/Qt5Widgets.prl:
QMAKE_PRL_TARGET = libQt5Widgets.dll.a
$ rpm -qf /usr/i686-w64-mingw32/sys-root/mingw/lib/Qt5Widgets.prl
mingw32-qt5-qtbase-static-5.15.9-1.fc39.noarch
so that file is coming in as part of the -static package, but
referring to the dll import file not the static file. But I'm not
finding similar files for the other libraries.
I'm starting to think that the issue is that both the static and
shared builds of the libraries produce .prl files - but generally the
static build is installed first and then the shared build, so the .prl
files that are in the Fedora packages are for the shared libraries
since they have the same path.
So - is there a way for the static .prl files to be installed in a
different location for for qmake find them there?
Discovered a bit more information, and it's a bit more of a mess than
initially thought:
qmake appears to look for the presence of "staticlib" in the
module_config line of the .pri file to see if a static library is
present. e.g.:
/usr/i686-w64-mingw32/sys-root/mingw/share/qt5/mkspecs/modules/qt_lib_svg.pri:
QT.svg.module_config = v2 staticlib
Now at least for QtSvg, the only difference between the static and
shared version of the pri file is the presence of "staticlib". So we
might be able to get away with simply installing the static build after
the shared build.
Also, it appears that the .prl files are really only necessary for
static libraries, so we could just not build them for shared libraries
with the "no_install_prl" CONFIG option:
MINGW_BUILDDIR_SUFFIX=_static %mingw_qmake_qt5 ../%{qt_module}.pro
CONFIG+="static create_prl"
MINGW_BUILDDIR_SUFFIX=_static %mingw_make_build
MINGW_BUILDDIR_SUFFIX=_shared %mingw_qmake_qt5 ../%{qt_module}.pro
CONFIG+="no_install_prl"
MINGW_BUILDDIR_SUFFIX=_shared %mingw_make_build
Next comes the pkgconfig files. Again the only difference seems to be
the addition of Libs.private:
diff -ru
./qtsvg-everywhere-src-5.15.9/build_win32_shared/lib/pkgconfig/Qt5Svgd.pc ./qtsvg-everywhere-src-5.15.9/build_win32_static/lib/pkgconfig/Qt5Svgd.pc
---
./qtsvg-everywhere-src-5.15.9/build_win32_shared/lib/pkgconfig/Qt5
Re: Questions about mingw static libraries
On 5/5/23 21:31, Orion Poplawski wrote:
I'm just starting to look into the mingw packages and building mingw
executables with them - and in particular static building. I'm hoping
someone can clarify some things for me.
For "regular" libs we seem to have:
%{mingw32_bindir}/libexample-0.dll
%{mingw32_libdir}/libexample.dll.a
and for static libs:
%{mingw32_libdir}/libexample.a
so for example:
-rw-r--r--. 1 root root 7539008 Apr 11 18:00
/usr/i686-w64-mingw32/sys-root/mingw/bin/Qt5Gui.dll
-rw-r--r--. 1 root root 13373318 Apr 11 18:00
/usr/i686-w64-mingw32/sys-root/mingw/lib/libQt5Gui.a
-rw-r--r--. 1 root root 6699310 Apr 11 18:00
/usr/i686-w64-mingw32/sys-root/mingw/lib/libQt5Gui.dll.a
/usr/i686-w64-mingw32/sys-root/mingw/bin/Qt5Gui.dll: PE32
executable (DLL) (GUI) Intel 80386, for MS Windows, 12 sections
/usr/i686-w64-mingw32/sys-root/mingw/lib/libQt5Gui.dll.a: current ar
archive
/usr/i686-w64-mingw32/sys-root/mingw/lib/libQt5Gui.a: current ar
archive
From what I've gleaned from some web searches is that the .dll.a file
is an "import" library which seems to encode a dependency on the .dll
library at runtime, while the plain .a file is a more "normal" static
library.
So to link a static executable it looks like I want to be using
libQt5Gui.a. However, when attempting to build the x2goclient
executable I'm ending up with the following link line:
i686-w64-mingw32-g++ -g -fstack-protector -static -static-libstdc++
-static-libgcc -Wl,-subsystem,windows -mthreads -o
release/x2goclient.exe @object_script.x2goclient.Release -lssh.dll
-lwinspool /usr/i686-w64-mingw32/sys-root/mingw/lib/libQt5Svg.dll.a
/usr/i686-w64-mingw32/sys-root/mingw/lib/libQt5Widgets.dll.a
/usr/i686-w64-mingw32/sys-root/mingw/lib/libQt5Gui.dll.a -lgdi32
-lcomdlg32 -loleaut32 -limm32 -luxtheme -ljpeg -lpng -lharfbuzz
/usr/i686-w64-mingw32/sys-root/mingw/lib/libQt5Network.dll.a -lcrypt32
-ldnsapi -liphlpapi
/usr/i686-w64-mingw32/sys-root/mingw/lib/libQt5Core.dll.a -lz -lpcre2-16
-lversion -lole32 -luuid -lwinmm -lws2_32 -ladvapi32 -lshell32 -luser32
-lkernel32 -lnetapi32 -luserenv -liconv release/x2goclient_res.o
-lmingw32 /usr/i686-w64-mingw32/sys-root/mingw/lib/libqt5main.a -lshell32
with lots of references to the .dll.a files. And from what I can tell,
the x2goclient.exe executable does appear to have runtime dependencies
on the various Qt dlls (e.g. Qt5Gui.dll, etc.).
I’m specifying a static config to qmake and QT is specified in the
x2goclient.pro simply with:
QT += svg network
So I really have no idea where the .dll.a references are coming from.
Some possibilities:
/usr/i686-w64-mingw32/sys-root/mingw/lib/Qt5Widgets.prl:
QMAKE_PRL_TARGET = libQt5Widgets.dll.a
$ rpm -qf /usr/i686-w64-mingw32/sys-root/mingw/lib/Qt5Widgets.prl
mingw32-qt5-qtbase-static-5.15.9-1.fc39.noarch
so that file is coming in as part of the -static package, but referring
to the dll import file not the static file. But I'm not finding similar
files for the other libraries.
I'm starting to think that the issue is that both the static and shared
builds of the libraries produce .prl files - but generally the static
build is installed first and then the shared build, so the .prl files
that are in the Fedora packages are for the shared libraries since they
have the same path.
So - is there a way for the static .prl files to be installed in a
different location for for qmake find them there?
Discovered a bit more information, and it's a bit more of a mess than
initially thought:
qmake appears to look for the presence of "staticlib" in the
module_config line of the .pri file to see if a static library is
present. e.g.:
/usr/i686-w64-mingw32/sys-root/mingw/share/qt5/mkspecs/modules/qt_lib_svg.pri:
QT.svg.module_config = v2 staticlib
Now at least for QtSvg, the only difference between the static and
shared version of the pri file is the presence of "staticlib". So we
might be able to get away with simply installing the static build after
the shared build.
Also, it appears that the .prl files are really only necessary for
static libraries, so we could just not build them for shared libraries
with the "no_install_prl" CONFIG option:
MINGW_BUILDDIR_SUFFIX=_static %mingw_qmake_qt5 ../%{qt_module}.pro
CONFIG+="static create_prl"
MINGW_BUILDDIR_SUFFIX=_static %mingw_make_build
MINGW_BUILDDIR_SUFFIX=_shared %mingw_qmake_qt5 ../%{qt_module}.pro
CONFIG+="no_install_prl"
MINGW_BUILDDIR_SUFFIX=_shared %mingw_make_build
Next comes the pkgconfig files. Again the only difference seems to be
the addition of Libs.private:
diff -ru
./qtsvg-everywhere-src-5.15.9/build_win32_shared/lib/pkgconfig/Qt5Svgd.pc
./qtsvg-everywhere-src-5.15.9/build_win32_static/lib/pkgconfig/Qt5Svgd.pc
---
./qtsvg-everywhere-src-5.15.9/build_win32_shared/lib/pkgconfig/Qt5Svgd.pc
2023-05-05 21:51:48.559526488 -0600
+++
./qtsvg
Questions about mingw static libraries
I'm just starting to look into the mingw packages and building mingw
executables with them - and in particular static building. I'm hoping
someone can clarify some things for me.
For "regular" libs we seem to have:
%{mingw32_bindir}/libexample-0.dll
%{mingw32_libdir}/libexample.dll.a
and for static libs:
%{mingw32_libdir}/libexample.a
so for example:
-rw-r--r--. 1 root root 7539008 Apr 11 18:00
/usr/i686-w64-mingw32/sys-root/mingw/bin/Qt5Gui.dll
-rw-r--r--. 1 root root 13373318 Apr 11 18:00
/usr/i686-w64-mingw32/sys-root/mingw/lib/libQt5Gui.a
-rw-r--r--. 1 root root 6699310 Apr 11 18:00
/usr/i686-w64-mingw32/sys-root/mingw/lib/libQt5Gui.dll.a
/usr/i686-w64-mingw32/sys-root/mingw/bin/Qt5Gui.dll: PE32
executable (DLL) (GUI) Intel 80386, for MS Windows, 12 sections
/usr/i686-w64-mingw32/sys-root/mingw/lib/libQt5Gui.dll.a: current ar archive
/usr/i686-w64-mingw32/sys-root/mingw/lib/libQt5Gui.a: current ar archive
From what I've gleaned from some web searches is that the .dll.a file
is an "import" library which seems to encode a dependency on the .dll
library at runtime, while the plain .a file is a more "normal" static
library.
So to link a static executable it looks like I want to be using
libQt5Gui.a. However, when attempting to build the x2goclient
executable I'm ending up with the following link line:
i686-w64-mingw32-g++ -g -fstack-protector -static -static-libstdc++
-static-libgcc -Wl,-subsystem,windows -mthreads -o
release/x2goclient.exe @object_script.x2goclient.Release -lssh.dll
-lwinspool /usr/i686-w64-mingw32/sys-root/mingw/lib/libQt5Svg.dll.a
/usr/i686-w64-mingw32/sys-root/mingw/lib/libQt5Widgets.dll.a
/usr/i686-w64-mingw32/sys-root/mingw/lib/libQt5Gui.dll.a -lgdi32
-lcomdlg32 -loleaut32 -limm32 -luxtheme -ljpeg -lpng -lharfbuzz
/usr/i686-w64-mingw32/sys-root/mingw/lib/libQt5Network.dll.a -lcrypt32
-ldnsapi -liphlpapi
/usr/i686-w64-mingw32/sys-root/mingw/lib/libQt5Core.dll.a -lz -lpcre2-16
-lversion -lole32 -luuid -lwinmm -lws2_32 -ladvapi32 -lshell32 -luser32
-lkernel32 -lnetapi32 -luserenv -liconv release/x2goclient_res.o
-lmingw32 /usr/i686-w64-mingw32/sys-root/mingw/lib/libqt5main.a -lshell32
with lots of references to the .dll.a files. And from what I can tell,
the x2goclient.exe executable does appear to have runtime dependencies
on the various Qt dlls (e.g. Qt5Gui.dll, etc.).
I’m specifying a static config to qmake and QT is specified in the
x2goclient.pro simply with:
QT += svg network
So I really have no idea where the .dll.a references are coming from.
Some possibilities:
/usr/i686-w64-mingw32/sys-root/mingw/lib/Qt5Widgets.prl:
QMAKE_PRL_TARGET = libQt5Widgets.dll.a
$ rpm -qf /usr/i686-w64-mingw32/sys-root/mingw/lib/Qt5Widgets.prl
mingw32-qt5-qtbase-static-5.15.9-1.fc39.noarch
so that file is coming in as part of the -static package, but referring
to the dll import file not the static file. But I'm not finding similar
files for the other libraries.
I'm starting to think that the issue is that both the static and shared
builds of the libraries produce .prl files - but generally the static
build is installed first and then the shared build, so the .prl files
that are in the Fedora packages are for the shared libraries since they
have the same path.
So - is there a way for the static .prl files to be installed in a
different location for for qmake find them there?
--
Orion Poplawski
he/him/his - surely the least important thing about me
IT Systems Manager 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/
smime.p7s
Description: S/MIME Cryptographic Signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: mingw missing debuginfo
On 5/5/23 10:30, Daniel P. Berrangé wrote:
On Fri, May 05, 2023 at 10:29:07AM -0600, Orion Poplawski wrote:
On 5/5/23 09:45, Daniel P. Berrangé wrote:
On Fri, May 05, 2023 at 09:41:01AM -0600, Orion Poplawski wrote:
I'm trying to add mingw builds to the libssh package here:
https://src.fedoraproject.org/rpms/libssh/pull-request/15
build is failing with:
Could not open %files file
/home/orion/fedora/libssh/libssh-0.10.4/mingw32-debugfiles.list: No such
file or directory
What am I doing wrong?
Missing call to:
%{?mingw_debug_install_post}
in the %install section, after installing the mingw build
With regards,
Daniel
Thanks. That seems to be missing from the example spec files in the docs:
https://docs.fedoraproject.org/en-US/packaging-guidelines/MinGW/#_example_integrated_package_specfile
Yeah my bad. I documented it earlier
https://docs.fedoraproject.org/en-US/packaging-guidelines/MinGW/#_debuginfo_subpackage
but missed it from the example. Will send a fix next week.
With regards,
Daniel
Great, thanks. While I'm looking - it also looks like the shared
example static packages are not defined as noarch as well.
--
Orion Poplawski
he/him/his - surely the least important thing about me
IT Systems Manager 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/
smime.p7s
Description: S/MIME Cryptographic Signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: mingw missing debuginfo
On 5/5/23 09:45, Daniel P. Berrangé wrote:
On Fri, May 05, 2023 at 09:41:01AM -0600, Orion Poplawski wrote:
I'm trying to add mingw builds to the libssh package here:
https://src.fedoraproject.org/rpms/libssh/pull-request/15
build is failing with:
Could not open %files file
/home/orion/fedora/libssh/libssh-0.10.4/mingw32-debugfiles.list: No such
file or directory
What am I doing wrong?
Missing call to:
%{?mingw_debug_install_post}
in the %install section, after installing the mingw build
With regards,
Daniel
Thanks. That seems to be missing from the example spec files in the docs:
https://docs.fedoraproject.org/en-US/packaging-guidelines/MinGW/#_example_integrated_package_specfile
--
Orion Poplawski
he/him/his - surely the least important thing about me
IT Systems Manager 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/
smime.p7s
Description: S/MIME Cryptographic Signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
mingw missing debuginfo
I'm trying to add mingw builds to the libssh package here: https://src.fedoraproject.org/rpms/libssh/pull-request/15 build is failing with: Could not open %files file /home/orion/fedora/libssh/libssh-0.10.4/mingw32-debugfiles.list: No such file or directory What am I doing wrong? -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
mingw pkgconfig reqs/provides
I've submitted a test version of autogenerating mingw pkgconfig provides and reqs here: https://github.com/rpm-software-management/rpm/pull/2504 This generates provides like: Provides: mingw32(libtiff-5.dll) mingw32(libtiffxx-5.dll) mingw32-libtiff = 4.4.0-2.fc39 mingw32-pkgconfig(libtiff-4) = 4.4.0 Provides: mingw64(libtiff-5.dll) mingw64(libtiffxx-5.dll) mingw64-libtiff = 4.4.0-2.fc39 mingw64-pkgconfig(libtiff-4) = 4.4.0 Thoughts? -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: octave 8.1 update coming to rawhide
On 4/15/23 01:58, Vascom wrote: Is there a chance to have Octave 8.1 at F38? It's a soname / API change so too late for F38 in my opinion. Though I have been poking at https://copr.fedorainfracloud.org/coprs/g/scitech/octave8.1/ slowly. Not sure how much time I will have for that though. Also, 8.2 just came out... вс, 9 апр. 2023 г. в 18:49, Orion Poplawski : On 4/8/23 17:27, Orion Poplawski wrote: On 4/5/23 20:22, Orion Poplawski wrote: I will be updating octave to 8.1 this weekend. This involves a soname bump and I will be rebuilding all deps. Builds are complete and update submitted: https://bodhi.fedoraproject.org/updates/FEDORA-2023-56669c4da2 -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: octave 8.1 update coming to rawhide
On 4/8/23 17:27, Orion Poplawski wrote: On 4/5/23 20:22, Orion Poplawski wrote: I will be updating octave to 8.1 this weekend. This involves a soname bump and I will be rebuilding all deps. Builds are complete and update submitted: https://bodhi.fedoraproject.org/updates/FEDORA-2023-56669c4da2 -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: octave 8.1 update coming to rawhide
On 4/5/23 20:22, Orion Poplawski wrote: I will be updating octave to 8.1 this weekend. This involves a soname bump and I will be rebuilding all deps. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue This has started: https://koji.fedoraproject.org/koji/taskinfo?taskID=99691863 in f39-build-side-65984 -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fwd: [Yubico/python-fido2] Test fails on RHEL9 due to sha1 removal (Issue #182)
If anyone has any expertise/suggestions for dealing with this, comments in the issue would be welcome. Thanks. Forwarded Message Subject: Re: [Yubico/python-fido2] Test fails on RHEL9 due to sha1 removal (Issue #182) Date: Sat, 08 Apr 2023 01:01:36 -0700 From: Dain Nilsson The underlying issue seems to be this: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/VVLHQAWI3IQ7NRLKMUHJ27JV3V2JAFDP/ <https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/VVLHQAWI3IQ7NRLKMUHJ27JV3V2JAFDP/> The easiest fix would be to detect this and skip those tests, but it doesn't solve the bigger problem of TPM attestation using SHA1 not being verifiable on RHEL. I'm on vacation this coming week, but will take a look at it when I'm back. In the meantime I'd welcome suggestions on how we should tackle this! — Reply to this email directly, view it on GitHub <https://github.com/Yubico/python-fido2/issues/182#issuecomment-1500820012>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGG4RVOO4YI6GULZ4CO2UTXAELOBANCNFSM6AAWUVUK4M>. You are receiving this because you authored the thread.Message ID: -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Need help with nut systemd scriptlets and multiple services and targets
On 4/6/23 21:27, Robert Nichols wrote: > On 4/6/23 17:56, Orion Poplawski wrote: >> The nut package has a number of different systemd units: >> >> /usr/lib/systemd/system/nut-driver-enumerator.path >> /usr/lib/systemd/system/nut-driver-enumerator.service >> '/usr/lib/systemd/system/nut-driver@.service' >> /usr/lib/systemd/system/nut-driver.target >> /usr/lib/systemd/system/nut-server.service >> /usr/lib/systemd/system/nut.target >> >> And I have a number of questions about how to handle them: >> >> * I think we want a preset to automatically enable and start >> nut-driver-enumerator.path. This monitors /etc/ups/ups.conf and runs >> nut-driver-enumerator.service when it does. It also has: >> >> [Install] >> WantedBy=nut.target >> >> Does that seem appropriate? Is is possible to start it immediately after >> install in %post? > > You don't want to start _anything_ until the user has done the rather > extensive > editing required in the config files to tell the package what hardware to look > for and what to do. I still think that auto-enabling nut-driver-enumerator.path may be the right thing to do. That way when a user edits /etc/ups/ups.conf the needed nut-driver-enumerator.service run is done. Or, see below.. >> * What is a user expected to do to enable and start "nut"? It seems like: >> >> systemctl enable nut.target >> systemctl start nut.target > > The user needs to enable nut-driver-enumerator.service if there is any UPS > hardware monitored by this system (i.e., not needed if this is a "secondary" > system and some other "primary" system is actually monitoring the UPS). Why should the user have to explicitly enable nut-driver-enumerator.service? It does seem necessary for some reason to enable it to have it start with nut.target below. But I don't understand why. It has PartOf=nut.target: [Unit] # This unit starts early in system lifecycle to set up nut-driver instances. # End-user may also restart this unit after editing ups.conf to automatically # un-register or add new instances as appropriate. Description=Network UPS Tools - enumeration of configure-file devices into systemd unit instances After=local-fs.target Before=nut-driver.target PartOf=nut.target just like nut-server.service: [Unit] Description=Network UPS Tools - power devices information server After=local-fs.target network.target nut-driver.target # We don't Require drivers to be successfully started! This would be # a change of behavior compared to init SysV, and could prevent from # accessing successfully started, at least to audit a system. Wants=nut-driver.target # The `upsd` is a networked service (even if bound to a `localhost`) # so it requires that the OS has some notion of networking already. # Extending the unit does not require *this* file to be edited, you # can instead drop in an additional piece of configuration, e.g. add # a `/etc/systemd/system/nut-server.service.d/network.conf` with: # [Unit] # Requires=network-online.target # After=network-online.target Requires=network.target Before=nut-monitor.service PartOf=nut.target but nut-server.service is started automatically when nut.target is started despite not being explicitly enabled itself: # systemctl status nut-server ● nut-server.service - Network UPS Tools - power devices information server Loaded: loaded (/usr/lib/systemd/system/nut-server.service; disabled; vendor preset: disabled) Active: active (running) since Fri 2023-04-07 14:34:09 MDT; 1min 27s ago I would have hoped it would be fine to enable nut-driver-enumerator.service automatically via presets - but after some testing it looks like their are situations where it can hang or fail which is not good. This step of needing to enable nut-driver-enumerator.service seems like a very unfortunate step and would be nice to avoid if possible. > Then, running "systemctl enable nut.target" will start the package on the > next boot. Include "--now", or run "systemctl start nut.target" to start it > immediately. > > But all of that has to wait until the user has made the necessary edits in > the config scripts in /etc/ups.conf and edited the /usr/bin/upssched-cmd > script to set up any additional actions (e.g., notifications, etc) that are > wanted. > >> Would do the trick, but I don't think it's very intuitive - most users think >> in terms of service units I think. > > Overall, it's a pretty user-unfriendly package. Some things that used to > "Just Work" back in the days of CentOS 6 need manual configuration now. Yeah, and unfortunately some packaging mistakes have been making it trickier as well. I also still need to address the scriptlets: %pre # do not let upsmon run
[EPEL-devel] python2 in epel8-next
I'm building python3.11-setuptools_scm-epel in epel8-next. It requires mercurial for the tests which requires: /usr/bin/python2 libpython2.7.so.1.0()(64bit) python(abi) = 2.7 python2 On my CS8 system this is satisfied by python2-2.7.18-12.module_el8+299+aa6e9afa.x86_64 from the python27 module. In the epel8-next build I end up with: python2 x86_64 2.7.17-1.el8 python2-for-tests x86_64 2.7.17-1.el8 python2-libs x86_64 2.7.17-1.el8 despite this message: DEBUG util.py:445: Enabling module streams: DEBUG util.py:445: mercurial 4.8 DEBUG util.py:445: python27 2.7 Which then emits a complaint when run: ERROR: Python 2 is disabled in RHEL8. - For guidance on porting to Python 3, see the Conservative Python3 Porting Guide: http://portingguide.readthedocs.io/ - If you need Python 2 at runtime: - Use the python27 module - If you do not have access to BZ#1533919: - Use the python27 module - If you need to use Python 2 only at RPM build time: - File a bug blocking BZ#1533919: https://bugzilla.redhat.com/show_bug.cgi?id=1533919 - Set the environment variable RHEL_ALLOW_PYTHON2_FOR_BUILD=1 (Note that if you do not file the bug as above, this workaround will break without warning in the future.) - If you need to use Python 2 only for tests: - File a bug blocking BZ#1533919: https://bugzilla.redhat.com/show_bug.cgi?id=1533919 (If your test tool does not have a Bugzilla component, feel free to use `python2`.) - Use /usr/bin/python2-for-tests instead of python2 to run your tests. (Note that if you do not file the bug as above, this workaround will break without warning in the future.) For details, see https://hurl.corp.redhat.com/rhel8-py2 Fatal Python error: Python 2 is disabled I can work around it by defining RHEL_ALLOW_PYTHON2_FOR_BUILD=1, but it seems like we really should be pulling in python2 from the module? -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Need help with nut systemd scriptlets and multiple services and targets
The nut package has a number of different systemd units: /usr/lib/systemd/system/nut-driver-enumerator.path /usr/lib/systemd/system/nut-driver-enumerator.service '/usr/lib/systemd/system/nut-driver@.service' /usr/lib/systemd/system/nut-driver.target /usr/lib/systemd/system/nut-server.service /usr/lib/systemd/system/nut.target And I have a number of questions about how to handle them: * I think we want a preset to automatically enable and start nut-driver-enumerator.path. This monitors /etc/ups/ups.conf and runs nut-driver-enumerator.service when it does. It also has: [Install] WantedBy=nut.target Does that seem appropriate? Is is possible to start it immediately after install in %post? * What is a user expected to do to enable and start "nut"? It seems like: systemctl enable nut.target systemctl start nut.target Would do the trick, but I don't think it's very intuitive - most users think in terms of service units I think. It also doesn't seem to work without nut-driver-enumerator.service having run to configure and start the nut-driver@UPS.service instance. Because starting nut.target does not appear to run nut-driver-enumerator.service, at least on EL8. * What systemd scriptlets should get called? Do we call them on target or path units as well? The packaging guidelines don't seem to mention those types specifically, but I do see them in various spec files. Thank you very much for any guidance. -- Orion Poplawski IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
octave 8.1 update coming to rawhide
I will be updating octave to 8.1 this weekend. This involves a soname bump and I will be rebuilding all deps. -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: Future of ClamAV on EPEL ?
On 3/7/23 13:48, Stephen Smoogen wrote: On Tue, 7 Mar 2023 at 15:00, Andrew C Aitchison <mailto:and...@aitchison.me.uk>> wrote: This question is prompted by a question from kumar bava about EPEL7 on the ClamaAV Users list: https://lists.clamav.net/pipermail/clamav-users/2023-March/013338.html <https://lists.clamav.net/pipermail/clamav-users/2023-March/013338.html> EPEL currently ship the anti-virus ClamAV v0.103.8 From September ClamAV 0.103 will be EOL, and all supported versions will require Rust. Rust is available on RHEL 7, 8 and 9 as a part of Red Hat Developer Tools. Does that mean that EPEL will or will not be able to continue packaging ClamAV ? ClamAV do provide rpms, so it may not be the end of the world if ClamAV disappears from EPEL, but the details of the packing, especially config locations and defaults may be different. EPEL packages are maintained by volunteers who 'shephard' a particular package for as long as the volunteer can do so. I have cc'd the main ones I have seen making commits and builds in case they aren't following the epel-devel list closely. That said, EL7 will only be around til June 2024. There will only be so much 'heavy-lifting' possible to keep things going in that time-frame I've been looking into things and I think we will be able to update clamav in EL7 and EL8 to 1.0.X once 0.103.X goes EOL. We're basically just waiting on one issue to get resolved at the moment: https://github.com/Cisco-Talos/clamav/issues/842 -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Test upgrades from F37 to F38 - it will take you just a minute
Thanks for the heads up. Looks like the update got stuck. I've kicked it. Now need to wait for the freeze to end. https://bodhi.fedoraproject.org/updates/FEDORA-2023-fa1d678565 On 2/22/23 06:12, Steve Cossette wrote: I just tried on a second PC, and I see this too on this one: Lmod x86_64 8.7.18-1.fc38 fedora 258 k Seems Lmod is of a lower version on Fedora 38 as well, compared to Fedora 37. Le mer. 22 févr. 2023, à 04 h 30, Miroslav Suchý <mailto:msu...@redhat.com>> a écrit : Do you want to make Fedora 38 better? Please spend 1 minute of your time and try to run: # Run this only if you use default Fedora modules # next time you run any DNF command default modules will be enabled again sudo dnf module reset '*' dnf --releasever=38 --setopt=module_platform_id=platform:f38 \ --enablerepo=updates-testing \ $(rpm -q fedora-repos-modular >/dev/null && echo --enablerepo=updates-testing-modular) \ --assumeno distro-sync This command does not replace `dnf system-upgrade`, but it will reveals potential problems. You may also run `dnf upgrade` before running this command. The `--assumeno` will just test the transaction, but does not make the actual upgrade. In case you hit dependency issues, please report it against the appropriate package. Or against fedora-obsolete-packages if that package should be removed in Fedora 38. Please check existing reports against fedora-obsolete-packages first: https://red.ht/2kuBDPu <https://red.ht/2kuBDPu> and also there is already bunch of "Fails to install" (F38FailsToInstall) reports: https://bugzilla.redhat.com/show_bug.cgi?id=F38FailsToInstall <https://bugzilla.redhat.com/show_bug.cgi?id=F38FailsToInstall> Thank you Miroslav ___ devel mailing list -- devel@lists.fedoraproject.org <mailto:devel@lists.fedoraproject.org> To unsubscribe send an email to devel-le...@lists.fedoraproject.org <mailto:devel-le...@lists.fedoraproject.org> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ <https://docs.fedoraproject.org/en-US/project/code-of-conduct/> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines <https://fedoraproject.org/wiki/Mailing_list_guidelines> List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org <https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue <https://pagure.io/fedora-infrastructure/new_issue> ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: FTBFS bug filed, build already deleted
On 2/20/23 10:46, Fabio Valentini wrote: On Mon, Feb 20, 2023 at 6:43 PM Julian Sikorski wrote: Hello, FTBFS bug was filed against mame [1]. Unfortunately, the corresponding build [2] has already been deleted. This is not ideal from maintainer perspective as it effectively is a bug with no info provided whatsoever. Not to mention being quite wasteful from the resources perspective as mame builds take quite a while. While not much can be done now, can we make sure that the mass rebuild builds do not get garbage collected, or at least the build logs are saved somewhere? Thanks. As far as I know, at least some form of truncated build.log used to get attached when FTBFS bugs were filed after a mass rebuild ... maybe this time this wasn't possible, because bugs were reported *weeks* after the mass rebuild? And I agree, having no logs at all for something that takes a long time to build is annoying :( Well, if your package is tracked by koschei (which I highly recommend), you likely could get a current build log from there. -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaning rubygem-jquery-rails + *js-jquery*
On 2/2/23 10:16, Vít Ondruch wrote: Hi, I have spend some quality time bringing rubygem-railties test suite up2date and this resulted in dropping the dependency on rubygem-jquery-rails. Nothing else in Fedora depends on that package and therefore I orphaned it and I suggest to let it go. Since I don't maintain rubygem-jquery-rails, I have also released ownership of js-jquery package. I have saved the package a while ago from being retired, but I was never good maintainer. Because it is used by other packages, I hope it will find new maintainers quickly. The package was updated while ago by Stephen and recently by Orion, therefore adding them on CC. I've taken it. Co-maintainers welcome. -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: bodhi tests missing
On 2/3/23 08:16, Petr Pisar wrote:
V Fri, Feb 03, 2023 at 07:40:09AM -0700, Orion Poplawski napsal(a):
I've got a couple updates with missing tests:
https://bodhi.fedoraproject.org/updates/FEDORA-2023-96ebcd6f4d
https://bodhi.fedoraproject.org/updates/FEDORA-2023-23e26fcc32
That happens when CI is slow or broken. Or when a message bus about finising
the tests was not properly stored into test results database. Also some tests
performed in Rawhide are not performed in stable Fedoras, based on global CI
configuration.
it seems like I used to have the option to resubmit the tests but I don't
see that now. Is my only option to waive the test results?
Try a command line: bodhi updates trigger-tests FEDORA-2023-96ebcd6f4d.
Thanks, but no go:
bodhi updates trigger-tests FEDORA-2023-96ebcd6f4d
Login successful!
Traceback (most recent call last):
File "/usr/lib/python3.11/site-packages/bodhi/client/bindings.py",
line 382, in trigger_tests
return self.send_request(
^^
File "/usr/lib/python3.11/site-packages/bodhi/client/bindings.py",
line 235, in send_request
raise BodhiClientException(response.text)
bodhi.client.bindings.BodhiClientException: {"status": "error",
"errors": [{"location": "body", "name": "request", "description":
"Update is not in testing status"}]}
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/bin/bodhi", line 8, in
sys.exit(cli())
^
File "/usr/lib/python3.11/site-packages/click/core.py", line 1130, in
__call__
return self.main(*args, **kwargs)
^^
File "/usr/lib/python3.11/site-packages/click/core.py", line 1055, in
main
rv = self.invoke(ctx)
File "/usr/lib/python3.11/site-packages/click/core.py", line 1657, in
invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
^^^
File "/usr/lib/python3.11/site-packages/click/core.py", line 1657, in
invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
^^^
File "/usr/lib/python3.11/site-packages/click/core.py", line 1404, in
invoke
return ctx.invoke(self.callback, **ctx.params)
^^^
File "/usr/lib/python3.11/site-packages/click/core.py", line 760, in
invoke
return __callback(*args, **kwargs)
^^^
File "/usr/lib/python3.11/site-packages/bodhi/client/cli.py", line
269, in wrapper
method(*args, **kwargs)
File "/usr/lib/python3.11/site-packages/bodhi/client/cli.py", line
986, in trigger_tests
resp = client.trigger_tests(update)
File "/usr/lib/python3.11/site-packages/bodhi/client/bindings.py",
line 128, in wrapper
result = method(*args, **kwargs)
^^^
File "/usr/lib/python3.11/site-packages/bodhi/client/bindings.py",
line 386, in trigger_tests
if exc.response.status_code == 404:
AttributeError: 'NoneType' object has no attribute 'status_code'
--
Orion Poplawski
he/him/his - surely the least important thing about me
IT Systems Manager 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/
smime.p7s
Description: S/MIME Cryptographic Signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
bodhi tests missing
I've got a couple updates with missing tests: https://bodhi.fedoraproject.org/updates/FEDORA-2023-96ebcd6f4d https://bodhi.fedoraproject.org/updates/FEDORA-2023-23e26fcc32 it seems like I used to have the option to resubmit the tests but I don't see that now. Is my only option to waive the test results? -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
openmpi 5.0.0 drops 32-bit support
As a heads up - openmpi 5.0.0 drops support for 32-bit builds [1]. I'm not sure how far away it is from release - we're on rc10 at the moment. Affected packages seem to be: amg4psblas-1.1.0-4.fc38.src.rpm arbor-0.7-4.fc38.src.rpm auryn-0.8.2-15.fc38.src.rpm boost-1.78.0-11.fc38.src.rpm bout++-4.4.2-5.fc37.src.rpm cgnslib-4.3.0-6.fc38.src.rpm cgnslib-4.3.0-7.fc38.src.rpm coin-or-Ipopt-3.14.9-2.fc38.src.rpm combblas-1.6.2-0.15.beta2.fc37.src.rpm cp2k-2023.1-2.fc38.src.rpm dolfin-2019.1.0.post0-36.fc38.src.rpm elpa-2022.05.001-2.fc38.src.rpm fftw-3.3.10-3.fc37.src.rpm freefem++-4.12-2.fc38.src.rpm ga-5.7.2-13.fc38.src.rpm gmsh-4.11.1-3.fc38.src.rpm gpaw-22.8.0-5.fc38.src.rpm gretl-2022c-2.fc38.src.rpm h5py-3.7.0-4.fc38.src.rpm hdf5-1.12.1-11.fc38.src.rpm hpx-1.8.1-1.fc37.src.rpm hypre-2.24.0-3.fc37.src.rpm intel-mpi-benchmarks-2021.3-3.fc38.src.rpm lammps-20220623-3.fc38.src.rpm libcircle-0.3-12.fc38.src.rpm libneurosim-1.2.0-6.20210110.gitafc003f.fc38.src.rpm mathgl-8.0.1-2.fc38.src.rpm mpi4py-3.1.4-2.fc38.src.rpm MUMPS-5.5.1-1.fc38.src.rpm MUSIC-1.1.16-10.20201002git8c6b77a.fc38.src.rpm nest-3.3-1.fc38.src.rpm netcdf-4.9.0-5.fc38.src.rpm netcdf-cxx4-4.3.1-8.fc38.src.rpm netcdf-fortran-4.5.4-3.fc38.src.rpm netgen-mesher-6.2.2202-5.fc38.src.rpm neuron-8.0.2-6.fc38.src.rpm nwchem-7.0.2-12.fc38.src.rpm openmpi-4.1.4-8.fc38.src.rpm paraview-5.11.0-3.fc38.src.rpm petsc-3.17.4-7.fc38.src.rpm psblas3-3.8.0-3.fc37.src.rpm python-dijitso-2019.1.0-12.fc38.src.rpm python-ffc-2019.1.0.post0-11.fc38.src.rpm python-lfpy-2.2.6-6.fc38.src.rpm python-steps-3.6.0-27.fc38.src.rpm quantum-espresso-7.0-5.fc38.src.rpm scalapack-2.2.0-3.fc38.src.rpm scotch-6.1.2-3.fc37.src.rpm sundials2-2.7.0-12.fc38.src.rpm sundials-5.8.0-11.fc38.src.rpm superlu_dist-8.1.1-1.fc38.src.rpm vtk-9.2.5-2.fc38.src.rpm Personally I've been planning on dropping 32-bit support in a buch of packages I maintain in this stack like vtk, paraview, etc. This seems like as good a driver for it as any. That said, packages that build serial and parallel versions don't need to drop 32-bit support completely, just for the openmpi builds. 1 - https://github.com/open-mpi/ompi/pull/11282 -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: [SPF:fail] A coordinated plan for ansible-collection updates in EPEL?
On 1/31/23 11:03, Maxwell G wrote: On Tue Jan 31, 2023 at 15:01 +0200, Sagi Shnaidman wrote: Hi all, Hi, Orion Thanks for raising this question. Indeed! I wonder if it's possible to continue to update collections to the newest versions anyway. If someone wants to use the collection version provided in "big ansible", they would use ansible 6.3.0 with all included. If they want a newer collection, they can install a separate newest RPM. I agree. I think we should update collections to the next major version (if it exists) after each RHEL minor release and then keep them updated with point releases in between. We update the ansible bundle to the next major version that corresponds to RHEL's ansible-core version at each RHEL minor release, so it makes to do the same with the standalone collection packages. Collection versions that are EOL upstream won't be tested with newer ansible-core versions. Does this capture the general sentiment? - ansible is the static/stable collection of collections paired with the provided ansible-core for the life of the point release - ansible-collection-* packages will be at least the version of the collection in ansible, and optionally higher while giving due diligence to avoiding breaking changes. -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Bootstrapping package with circular dependencies in koji
On 1/31/23 11:06, Kevin Fenzi wrote: On Tue, Jan 31, 2023 at 02:23:48PM +0100, Vít Ondruch wrote: It seems that Koji supports this, but it need some configuration change. I have opened followup ticket here: https://pagure.io/releng/issue/11254 Yeah, my first thought about this was that it might be too broad, but it was pointed out that maintainers can already override macros in specs anyhow. Might run it by FESCo just to make sure everyone is ok with enabling... kevin I would think the main concern is the audit trail. Defining a macro in a spec file is checked into git and there is a record. Is there a record (and relatively easily accessed) for the macros set in a side tage? -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] A coordinated plan for ansible-collection updates in EPEL?
So, I'm wondering if we should have some kind of (at least semi-)coordinated plan for updating ansible collections in EPEL? My initial thought is we would sort of piggy back on to what the "ansible" community collection bundles on top of the ansible-core package provided by RedHat. So, currently in EL8.7 we have: ansible-core-2.13.3 and EPEL ships: ansible-6.3.0 - which corresponds to the ansible community package that ships with ansible-2.13.3. Then we would endeavor to ship the individual package collection versions that are contained in that package, .e.g: (taken from the MANIFEST.json files): ansible.posix 1.4.0 ansible.utils 2.6.1 chocolatey.chocolatey 1.3.0 community.docker 2.7.1 community.general 5.5.0 community.libvirt 1.2.0 community.mysql 3.4.0 community.rabbitmq 1.2.2 containers.podman 1.9.4 netbox.netbox 3.7.1 For reference, currently in epel we have: ansible-collection-ansible-posix.noarch 1.4.0-1.el8 epel ansible-collection-ansible-utils.noarch 2.6.1-1.el8 epel ansible-collection-chocolatey-chocolatey.noarch 1.4.0-1.el8 epel ansible-collection-community-docker.noarch 2.6.0-1.el8 epel ansible-collection-community-general.noarch 3.8.9-1.el8 epel ansible-collection-community-libvirt.noarch 1.1.0-3.el8 epel ansible-collection-community-mysql.noarch 3.5.1-1.el8 epel ansible-collection-community-rabbitmq.noarch1.2.3-1.el8 epel ansible-collection-containers-podman.noarch 1.10.1-1.el8epel ansible-collection-netbox-netbox.noarch 3.7.1-1.el8 epel However, it's hard for me to resist the allure of the shiny and new, so I've updated chocolatey. Similarly some others have been updated to later versions. The other interesting case here is community.general - ansible has it at 5.5.0, but it looks like Maxwell G has taken the generally preferred course for EPEL of sticking with the stable release track of 3.X. Although I suspect very few collections maintain multiple release tracks (no idea). I don't really have a particular agenda here, just trying to solicit people's thoughts. Personally I like minimal installs so I have been only using ansible-core + collections on the systems I maintain and would like to continue to see them be usable together. -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] python3-qt5-webkit for EPEL 8
The python-qt5 package in RHEL 8 does not ship the webkit package. I'm
assuming that this is unlikely to be changed since qt5-qtwebkit isn't in
RHEL but is in EPEL.
I think I'm close to producing a python-qt5-epel package here [1] that
produces python3-qt5-webkit and would love to hear from people more
familiar with the package if this seems like it's reasonable/workable.
I think we're depending on the fact that the RHEL python3-qt5-devel
package does ship the WebKit sip files and that these would match up
with what this package ships.
It also just seems like webengine isn't in there, or I'm missing what's
needed to build it. I also don't need it for my purposes.
[1] - https://copr.fedorainfracloud.org/coprs/orion/python-qt5-epel/
--
Orion Poplawski
he/him/his - surely the least important thing about me
IT Systems Manager 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/%global with_python3 1
%global python3_dbus_dir %(%{__python3} -c "import dbus.mainloop; print(dbus.mainloop.__path__[0])" 2>/dev/null || echo "%{python3_sitearch}/dbus/mainloop")
# enable/disable individual modules
# drop power64, it's not supported yet (than)
%ifarch %{?qt5_qtwebengine_arches}%{?!qt5_qtwebengine_arches:%{ix86} x86_64 %{arm} aarch64 mips mipsel mips64el}
%global webengine 0
%endif
%global webkit 1
%global py3_sipdir %{_datadir}/sip/PyQt5
%global sip_ver 4.19.23
# see also https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/JQQ66XJSIT2FGTK2YQY7AXMEH5IXMPUX/
%undefine _strict_symbol_defs_build
Summary: PyQt5 is Python bindings for Qt5
Name:python-qt5-epel
Version: 5.15.0
Release: 3.0.1%{?dist}
License: GPLv3
Url: http://www.riverbankcomputing.com/software/pyqt/
Source0: https://files.pythonhosted.org/packages/8c/90/82c62bbbadcca98e8c6fa84f1a638de1ed1c89e85368241e9cc43fcbc320/PyQt5-%{version}.tar.gz
## upstreamable patches
Patch0: python-qt5_sipdir.patch
# support newer Qt5 releases
Patch1: PyQt5-Timeline.patch
#BuildRequires: pkgconfig(dbus-1)
BuildRequires: python%{python3_pkgversion}
BuildRequires: python%{python3_pkgversion}-sip-devel >= %{sip_ver}
%description
%{summary}.
%global __provides_exclude_from ^(%{_qt5_plugindir}/.*\\.so)$
%if 0%{?webengine}
%package -n python%{python3_pkgversion}-qt5-webengine
Summary: Python3 bindings for Qt5 WebEngine
BuildRequires: pkgconfig(Qt5WebEngine)
Requires: python%{python3_pkgversion}-qt5%{?_isa} = %{version}-%{release}
%{?python_provide:%python_provide python%{python3_pkgversion}-qt5-webengine}
%description -n python%{python3_pkgversion}-qt5-webengine
%{summary}.
%endif
%package -n python%{python3_pkgversion}-qt5-webkit
Summary: Python3 bindings for Qt5 Webkit
BuildRequires: pkgconfig(Qt5WebKit)
BuildRequires: pkgconfig(Qt5WebKitWidgets)
Requires: python%{python3_pkgversion}-qt5%{?_isa} = %{version}-%{release}
%{?python_provide:%python_provide python%{python3_pkgversion}-qt5-webkit}
%description -n python%{python3_pkgversion}-qt5-webkit
%{summary}.
%prep
%setup -q -n PyQt5-%{version}
%patch0 -p1
%patch1 -p1
%build
PATH=%{_qt5_bindir}:$PATH ; export PATH
mkdir %{_target_platform}-python3
cp -a * %{_target_platform}-python3/ ||:
pushd %{_target_platform}-python3
%{__python3} ./configure.py \
--assume-shared \
--confirm-license \
--qmake=%{_qt5_qmake} \
%{?py3_sip:--sip=%{_bindir}/python3-sip} \
%{?py3_sipdir:--sipdir=%{py3_sipdir}} \
--enable QtWebKit \
--enable QtWebKitWidgets \
--verbose \
QMAKE_CFLAGS_RELEASE="%{optflags}" \
QMAKE_CXXFLAGS_RELEASE="%{optflags} `pkg-config --cflags dbus-python`" \
QMAKE_LFLAGS_RELEASE="%{?__global_ldflags}"
# --dbus=%{_includedir}/dbus-1.0/ \
%make_build
popd
%install
%make_install INSTALL_ROOT=%{buildroot} -C %{_target_platform}-python3
rm -r %{buildroot}%{_datadir} \
%{buildroot}%{_bindir} \
%{buildroot}%{python3_sitearch}/PyQt5*info \
%{buildroot}%{python3_sitearch}/PyQt5/__init__.py \
%{buildroot}%{python3_sitearch}/PyQt5/py* \
%{buildroot}%{python3_sitearch}/PyQt5/Qt.so \
%{buildroot}%{python3_sitearch}/PyQt5/uic
%if 0%{?webengine}
%files -n python%{python3_pkgversion}-qt5-webengine
%{python3_sitearch}/PyQt5/QtWebEngine.*
%{python3_sitearch}/PyQt5/QtWebEngineCore.*
%{python3_sitearch}/PyQt5/QtWebEngineWidgets.*
%endif
%files -n python%{python3_pkgversion}-qt5-webkit
%{python3_sitearch}/PyQt5/QtWebKit.*
%{python3_sitearch}/PyQt5/QtWebKitWidgets.*
%changelog
smime.p7s
Description: S/MIME Cryptographic Signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraprojec
[EPEL-devel] python3-qt5-webkit for EPEL 8
The python-qt5 package in RHEL 8 does not ship the webkit package. I'm
assuming that this is unlikely to be changed since qt5-qtwebkit isn't in
RHEL but is in EPEL.
I think I'm close to producing a python-qt5-epel package here [1] that
produces python3-qt5-webkit and would love to hear from people more
familiar with the package if this seems like it's reasonable/workable.
I think we're depending on the fact that the RHEL python3-qt5-devel
package does ship the WebKit sip files and that these would match up
with what this package ships.
It also just seems like webengine isn't in there, or I'm missing what's
needed to build it. I also don't need it for my purposes.
[1] - https://copr.fedorainfracloud.org/coprs/orion/python-qt5-epel/
--
Orion Poplawski
he/him/his - surely the least important thing about me
IT Systems Manager 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/%global with_python3 1
%global python3_dbus_dir %(%{__python3} -c "import dbus.mainloop; print(dbus.mainloop.__path__[0])" 2>/dev/null || echo "%{python3_sitearch}/dbus/mainloop")
# enable/disable individual modules
# drop power64, it's not supported yet (than)
%ifarch %{?qt5_qtwebengine_arches}%{?!qt5_qtwebengine_arches:%{ix86} x86_64 %{arm} aarch64 mips mipsel mips64el}
%global webengine 0
%endif
%global webkit 1
%global py3_sipdir %{_datadir}/sip/PyQt5
%global sip_ver 4.19.23
# see also https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/JQQ66XJSIT2FGTK2YQY7AXMEH5IXMPUX/
%undefine _strict_symbol_defs_build
Summary: PyQt5 is Python bindings for Qt5
Name:python-qt5-epel
Version: 5.15.0
Release: 3.0.1%{?dist}
License: GPLv3
Url: http://www.riverbankcomputing.com/software/pyqt/
Source0: https://files.pythonhosted.org/packages/8c/90/82c62bbbadcca98e8c6fa84f1a638de1ed1c89e85368241e9cc43fcbc320/PyQt5-%{version}.tar.gz
## upstreamable patches
Patch0: python-qt5_sipdir.patch
# support newer Qt5 releases
Patch1: PyQt5-Timeline.patch
#BuildRequires: pkgconfig(dbus-1)
BuildRequires: python%{python3_pkgversion}
BuildRequires: python%{python3_pkgversion}-sip-devel >= %{sip_ver}
%description
%{summary}.
%global __provides_exclude_from ^(%{_qt5_plugindir}/.*\\.so)$
%if 0%{?webengine}
%package -n python%{python3_pkgversion}-qt5-webengine
Summary: Python3 bindings for Qt5 WebEngine
BuildRequires: pkgconfig(Qt5WebEngine)
Requires: python%{python3_pkgversion}-qt5%{?_isa} = %{version}-%{release}
%{?python_provide:%python_provide python%{python3_pkgversion}-qt5-webengine}
%description -n python%{python3_pkgversion}-qt5-webengine
%{summary}.
%endif
%package -n python%{python3_pkgversion}-qt5-webkit
Summary: Python3 bindings for Qt5 Webkit
BuildRequires: pkgconfig(Qt5WebKit)
BuildRequires: pkgconfig(Qt5WebKitWidgets)
Requires: python%{python3_pkgversion}-qt5%{?_isa} = %{version}-%{release}
%{?python_provide:%python_provide python%{python3_pkgversion}-qt5-webkit}
%description -n python%{python3_pkgversion}-qt5-webkit
%{summary}.
%prep
%setup -q -n PyQt5-%{version}
%patch0 -p1
%patch1 -p1
%build
PATH=%{_qt5_bindir}:$PATH ; export PATH
mkdir %{_target_platform}-python3
cp -a * %{_target_platform}-python3/ ||:
pushd %{_target_platform}-python3
%{__python3} ./configure.py \
--assume-shared \
--confirm-license \
--qmake=%{_qt5_qmake} \
%{?py3_sip:--sip=%{_bindir}/python3-sip} \
%{?py3_sipdir:--sipdir=%{py3_sipdir}} \
--enable QtWebKit \
--enable QtWebKitWidgets \
--verbose \
QMAKE_CFLAGS_RELEASE="%{optflags}" \
QMAKE_CXXFLAGS_RELEASE="%{optflags} `pkg-config --cflags dbus-python`" \
QMAKE_LFLAGS_RELEASE="%{?__global_ldflags}"
# --dbus=%{_includedir}/dbus-1.0/ \
%make_build
popd
%install
%make_install INSTALL_ROOT=%{buildroot} -C %{_target_platform}-python3
rm -r %{buildroot}%{_datadir} \
%{buildroot}%{_bindir} \
%{buildroot}%{python3_sitearch}/PyQt5*info \
%{buildroot}%{python3_sitearch}/PyQt5/__init__.py \
%{buildroot}%{python3_sitearch}/PyQt5/py* \
%{buildroot}%{python3_sitearch}/PyQt5/Qt.so \
%{buildroot}%{python3_sitearch}/PyQt5/uic
%if 0%{?webengine}
%files -n python%{python3_pkgversion}-qt5-webengine
%{python3_sitearch}/PyQt5/QtWebEngine.*
%{python3_sitearch}/PyQt5/QtWebEngineCore.*
%{python3_sitearch}/PyQt5/QtWebEngineWidgets.*
%endif
%files -n python%{python3_pkgversion}-qt5-webkit
%{python3_sitearch}/PyQt5/QtWebKit.*
%{python3_sitearch}/PyQt5/QtWebKitWidgets.*
%changelog
smime.p7s
Description: S/MIME Cryptographic Signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraprojec
Re: When is dnf5 going to replace dnf4?
On 1/26/23 18:30, Reon Beon via devel wrote: Are there still some outstanding bugs preventing this from happening? There seems to be lots of missing functionality IMHO. -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-Astro-FITS-CFITSIO] PR #1: Update to 1.16
orion merged a pull-request against the project: `perl-Astro-FITS-CFITSIO` that you are following. Merged pull-request: `` Update to 1.16 `` https://src.fedoraproject.org/rpms/perl-Astro-FITS-CFITSIO/pull-request/1 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Update to clamav 1.0.0 coming next week to rawhide
This has now been submitted: https://bodhi.fedoraproject.org/updates/FEDORA-2023-5b701c93c4 On 1/16/23 09:28, Orion Poplawski wrote: I will be updating clamav to 1.0.0 next week in rawhide. This includes a switch to rust, a soname update and a slight API change. Dependent packages have been rebuilt here: https://copr.fedorainfracloud.org/coprs/orion/clamav-1.0/builds/ Fix for klamav has been filed here: https://src.fedoraproject.org/rpms/klamav/pull-request/1 This has been in the works for quite a while due to the switch to rust. Many thanks to Fabio Valentini for reviewing all of the rust dependencies. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: How to build two flavors of the same package?
On 1/17/23 14:28, Till Hofmann wrote:
Hi all,
Someone (rightfully) suggested that we should build glfw twice, once
with wayland support and once without:
https://bugzilla.redhat.com/show_bug.cgi?id=2152319
Is there any best practice how to build the same package in two
different flavors, in this case cmake-based? I vaguely remember seeing a
spec file that did that, but I don't remember where.
Thanks for any pointers!
In vtk.spec I do things like:
%global _vpath_builddir build
%cmake %{cmake_gen} \
%{vtk_cmake_options} \
-DVTK_BUILD_DOCUMENTATION:BOOL=ON \
-DVTK_BUILD_EXAMPLES:BOOL=ON \
-DVTK_BUILD_TESTING:BOOL=ON
%cmake_build -- --output-sync
%cmake_build --target DoxygenDoc
%if %{with mpich}
%global _vpath_builddir build-mpich
%_mpich_load
export CC=mpicc
export CXX=mpic++
%cmake %{cmake_gen} \
%{vtk_cmake_options} \
-DCMAKE_PREFIX_PATH:PATH=$MPI_HOME \
-DCMAKE_INSTALL_PREFIX:PATH=$MPI_HOME \
-DCMAKE_INSTALL_LIBDIR:PATH=lib \
-DCMAKE_INSTALL_JNILIBDIR:PATH=lib/%{name} \
-DCMAKE_INSTALL_QMLDIR:PATH=lib/qt5/qml \
-DVTK_USE_MPI:BOOL=ON
%cmake_build -- --output-sync
%_mpich_unload
%endif
--
Orion Poplawski
he/him/his - surely the least important thing about me
IT Systems Manager 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/
smime.p7s
Description: S/MIME Cryptographic Signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
vtk build failure with gcc 13.0.0 - enum class
e/c++/13/fstream:40, from /builddir/build/BUILD/VTK-9.2.5/Common/Core/vtkIOStream.h:29, from /builddir/build/BUILD/VTK-9.2.5/Common/Core/vtkSystemIncludes.h:39, from /builddir/build/BUILD/VTK-9.2.5/Common/Core/vtkIndent.h:28, from /builddir/build/BUILD/VTK-9.2.5/Common/Core/vtkObjectBase.h:53, from /builddir/build/BUILD/VTK-9.2.5/Common/Core/vtkObject.h:45, from /builddir/build/BUILD/VTK-9.2.5/Common/ExecutionModel/vtkExtentTranslator.h:29, from /builddir/build/BUILD/VTK-9.2.5/IO/Image/vtkSEPReader.h:24: /usr/include/bits/stdint-intn.h:26:19: note: 'int32_t' declared here 26 | typedef __int32_t int32_t; | ^~~ /builddir/build/BUILD/VTK-9.2.5/IO/Image/vtkSEPReader.h:103:19: error: 'int32_t' is not a member of 'std'; did you mean 'int32_t'? 103 | std::array ComputeExtent() const; | ^~~ /usr/include/bits/stdint-intn.h:26:19: note: 'int32_t' declared here 26 | typedef __int32_t int32_t; | ^~~ Any initial thoughts on whether this is a GCC or VTK issues? Does: enum class EndiannessType : std::uint8_t just become: enum EndiannessType : std::uint8_t ? -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
fedpkg local - do not clean build directory
How the #$@! do I get fedpkg local to not cleanup the local build directory after a successful build? This is the most annoying change to come around in a long time IMHO. Thanks. -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Update to clamav 1.0.0 coming next week to rawhide
I will be updating clamav to 1.0.0 next week in rawhide. This includes a switch to rust, a soname update and a slight API change. Dependent packages have been rebuilt here: https://copr.fedorainfracloud.org/coprs/orion/clamav-1.0/builds/ Fix for klamav has been filed here: https://src.fedoraproject.org/rpms/klamav/pull-request/1 This has been in the works for quite a while due to the switch to rust. Many thanks to Fabio Valentini for reviewing all of the rust dependencies. -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: libharu 2.4.3, mathgl 8.0.1, vtk 9.2.5 update coming to rawhide soon
On 1/15/23 20:03, Richard Shaw wrote: On Sat, Jan 14, 2023 at 10:31 AM Orion Poplawski <mailto:or...@nwra.com>> wrote: On 1/9/23 07:43, Orion Poplawski wrote: > I'm hoping to start updating libharu to 2.4.3, mathgl to 8.0.1, and vtk > to 9.2.5 at the end of this week. Builds will be done in a side tag. > Test builds are being done here: > > https://copr.fedorainfracloud.org/coprs/orion/libharu2.4/builds/ <https://copr.fedorainfracloud.org/coprs/orion/libharu2.4/builds/> This is starting in f38-build-side-61967. There are some issues with opencascade and mayavi, but I'm hopeful that they will be able to get addressed relatively soon. Careful, I just built opencascade 7.6.3 which is in Rawhide. Hopefully that helps? It still needed a patch, but I was able to get it to build. Thanks. -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: opencv updated to 4.7.0 in rawhide
Okay. Let me know if you need any help from me. PS - why the need to wait for the eln build? On 1/15/23 17:53, Sérgio Basto wrote: Hi, I will take care of it, I'm just waiting for opencv-4.7.0-2.eln125 finish to build , to start rebuilds of dependents packages On Sun, 2023-01-15 at 17:43 -0700, Orion Poplawski wrote: Unfortunately, an update to opencv 4.7.0 (with soname update) got got up in my vtk update build and pushed to rawhide. Sorry about that. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Accidental opencv soname bump
On 1/15/23 15:43, Miro Hrončok wrote: On 15. 01. 23 21:11, Sérgio Basto wrote: On Sun, 2023-01-15 at 18:47 +0100, Miro Hrončok wrote: On 14. 01. 23 17:31, Orion Poplawski wrote: On 1/9/23 07:43, Orion Poplawski wrote: I'm hoping to start updating libharu to 2.4.3, mathgl to 8.0.1, and vtk to 9.2.5 at the end of this week. Builds will be done in a side tag. Test builds are being done here: https://copr.fedorainfracloud.org/coprs/orion/libharu2.4/builds/ This is starting in f38-build-side-61967. There are some issues with opencascade and mayavi, but I'm hopeful that they will be able to get addressed relatively soon. Hello. The vtk rebuild of opencv effectively bumped the soname. What do we do? Untag or rebuild everything that links to opencv? My fault, I was prepare Opencv sidetag , my I move Opencv to one sidtag ? Just do the builds in rawhide quick? I'll get started I guess... -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
opencv updated to 4.7.0 in rawhide
Unfortunately, an update to opencv 4.7.0 (with soname update) got got up in my vtk update build and pushed to rawhide. Sorry about that. -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: libharu 2.4.3, mathgl 8.0.1, vtk 9.2.5 update coming to rawhide soon
On 1/14/23 09:31, Orion Poplawski wrote: On 1/9/23 07:43, Orion Poplawski wrote: I'm hoping to start updating libharu to 2.4.3, mathgl to 8.0.1, and vtk to 9.2.5 at the end of this week. Builds will be done in a side tag. Test builds are being done here: https://copr.fedorainfracloud.org/coprs/orion/libharu2.4/builds/ This is starting in f38-build-side-61967. There are some issues with opencascade and mayavi, but I'm hopeful that they will be able to get addressed relatively soon. This has been merged now. -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: libharu 2.4.3, mathgl 8.0.1, vtk 9.2.5 update coming to rawhide soon
On 1/9/23 07:43, Orion Poplawski wrote: I'm hoping to start updating libharu to 2.4.3, mathgl to 8.0.1, and vtk to 9.2.5 at the end of this week. Builds will be done in a side tag. Test builds are being done here: https://copr.fedorainfracloud.org/coprs/orion/libharu2.4/builds/ This is starting in f38-build-side-61967. There are some issues with opencascade and mayavi, but I'm hopeful that they will be able to get addressed relatively soon. -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
libharu 2.4.3, mathgl 8.0.1, vtk 9.2.5 update coming to rawhide soon
I'm hoping to start updating libharu to 2.4.3, mathgl to 8.0.1, and vtk to 9.2.5 at the end of this week. Builds will be done in a side tag. Test builds are being done here: https://copr.fedorainfracloud.org/coprs/orion/libharu2.4/builds/ -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: TeXLive 2022 landing in rawhide today
On 1/8/23 19:30, Tom Callaway wrote: Please open a bug on this so I can track it. https://bugzilla.redhat.com/show_bug.cgi?id=2159178 On Sat, Jan 7, 2023 at 11:11 AM Orion Poplawski <mailto:or...@nwra.com>> wrote: On 1/4/23 17:52, Tom Callaway wrote: > Hi Fedora, > > TeXLive 2022 (composed of texlive-base and texlive SRPMs) is landing in > rawhide today. I've done extensive local testing in mock to try to make > sure it doesn't break anything obvious... but the size and scope of TL > means that there are probably still some bugs introduced by this update. > > Please let me know if something stops building as a result of the new > texlive packages, either via email, bugzilla, twitter, mastodon, or > carrier pigeon, with as much detail as you can provide. > > I do not plan to push this to any stable Fedora, BUT, I have tested with > it installed over Fedora 37 and it seems to work okay for me. > > Apologies on the delay in getting this done. I realize TL 2023 is > probably coming out in a few months, hopefully, it will not take a year > for me to get that update in place. > > ~spot Seems to be breaking LaTeXML's tests: https://apps.fedoraproject.org/koschei/package/LaTeXML?collection=f38 <https://apps.fedoraproject.org/koschei/package/LaTeXML?collection=f38> Unfortunately koschei's query to see what else might be affected hits a gateway timeout: https://koschei.fedoraproject.org/affected-by/texlive-latex?epoch1=9=20210325=52.fc38=10=svn63825=55.fc38=f38 <https://koschei.fedoraproject.org/affected-by/texlive-latex?epoch1=9=20210325=52.fc38=10=svn63825=55.fc38=f38> Would be nice if that could be given more time to complete. -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com <mailto:or...@nwra.com> Boulder, CO 80301 https://www.nwra.com/ <https://www.nwra.com/> ___ devel mailing list -- devel@lists.fedoraproject.org <mailto:devel@lists.fedoraproject.org> To unsubscribe send an email to devel-le...@lists.fedoraproject.org <mailto:devel-le...@lists.fedoraproject.org> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ <https://docs.fedoraproject.org/en-US/project/code-of-conduct/> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines <https://fedoraproject.org/wiki/Mailing_list_guidelines> List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org <https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue <https://pagure.io/fedora-infrastructure/new_issue> ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: TeXLive 2022 landing in rawhide today
On 1/8/23 12:11, Kevin Fenzi wrote: On Sat, Jan 07, 2023 at 09:11:32AM -0700, Orion Poplawski wrote: Seems to be breaking LaTeXML's tests: https://apps.fedoraproject.org/koschei/package/LaTeXML?collection=f38 Unfortunately koschei's query to see what else might be affected hits a gateway timeout: https://koschei.fedoraproject.org/affected-by/texlive-latex?epoch1=9=20210325=52.fc38=10=svn63825=55.fc38=f38 Would be nice if that could be given more time to complete. Looks like it takes about 45s for that to load. I increased the timeout to 180s. :) kevin Thank you. -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: TeXLive 2022 landing in rawhide today
On 1/4/23 17:52, Tom Callaway wrote: Hi Fedora, TeXLive 2022 (composed of texlive-base and texlive SRPMs) is landing in rawhide today. I've done extensive local testing in mock to try to make sure it doesn't break anything obvious... but the size and scope of TL means that there are probably still some bugs introduced by this update. Please let me know if something stops building as a result of the new texlive packages, either via email, bugzilla, twitter, mastodon, or carrier pigeon, with as much detail as you can provide. I do not plan to push this to any stable Fedora, BUT, I have tested with it installed over Fedora 37 and it seems to work okay for me. Apologies on the delay in getting this done. I realize TL 2023 is probably coming out in a few months, hopefully, it will not take a year for me to get that update in place. ~spot Seems to be breaking LaTeXML's tests: https://apps.fedoraproject.org/koschei/package/LaTeXML?collection=f38 Unfortunately koschei's query to see what else might be affected hits a gateway timeout: https://koschei.fedoraproject.org/affected-by/texlive-latex?epoch1=9=20210325=52.fc38=10=svn63825=55.fc38=f38 Would be nice if that could be given more time to complete. -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: TeXLive 2022 landing in rawhide today
On 1/6/23 13:50, Jerry James wrote: On Fri, Jan 6, 2023 at 1:41 PM Michael J Gruber wrote: First breakage seems to be here: https://koji.fedoraproject.org/koji/taskinfo?taskID=95811080 Related to lua loading of otf fonts See https://bugzilla.redhat.com/show_bug.cgi?id=2158837 Thanks. Seems to be hitting BibTool as well. -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: Forcing Python minor version in EPEL builds
On 1/7/23 06:04, Mark E. Fuller wrote: Hi Folks, I am looking to update one of my packages in EPEL 8 and Python3.6 was dropped. Can anyone point me in the right direction as to how to edit my spec file `buildrequires` and the macros to enforce Python 3.7 (or higher) instead of Python 3.6 anto do it "the right way", not a kludge? For producing versions for other python 3.X versions, there is this: https://fedoraproject.org/wiki/EPEL/Python3X and you can check out the various python3*-foo-epel packages. I don't know of a 3.7, but there is 3.8 and 3.9. HTH, Orion -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: TeXLive 2022 landing in rawhide today
On 1/4/23 17:52, Tom Callaway wrote: Hi Fedora, TeXLive 2022 (composed of texlive-base and texlive SRPMs) is landing in rawhide today. I've done extensive local testing in mock to try to make sure it doesn't break anything obvious... but the size and scope of TL means that there are probably still some bugs introduced by this update. Please let me know if something stops building as a result of the new texlive packages, either via email, bugzilla, twitter, mastodon, or carrier pigeon, with as much detail as you can provide. I do not plan to push this to any stable Fedora, BUT, I have tested with it installed over Fedora 37 and it seems to work okay for me. Apologies on the delay in getting this done. I realize TL 2023 is probably coming out in a few months, hopefully, it will not take a year for me to get that update in place. ~spot Spot - Thanks again for managing to maintain this package, whatever the schedule. It's a big lift. Orion -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Scripts to rebuild dependencies in copr
I've been using an old review_pr.py script produced by the Fedora Stewardship SIG to rebuild the depedencies of a package in COPR to test changes/updates to packages. It's been incredibly useful. However, it seems that the github repo has disappeared. Is there anything else out there in use that is actively maintained? Thanks. -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: mmap() being called instead of mmap2() on i686 Rawhide
On 12/17/22 17:12, devel@lists.fedoraproject.org wrote: I *think* I may have found a bug in glibc in rawhide, but I'm not sure. I figured I would ask here first before filing a bug. I'm trying to track down a shared memory issue in openmpi on i686 rawhide: https://bugzilla.redhat.com/show_bug.cgi?id=2142304 https://github.com/open-mpi/ompi/issues/11065 and the oddity that I'm looking at now is that a strange mmap() system call is being made rather than mmap2() which appears to be standard on i686: [pid 84] 19:38:24 mmap(NULL) = -1 EFAULT (Bad address) normally I see calls like: [pid 157] mmap2(NULL, 62328, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 24, 0) = 0xf5a74000 Now is there any way that the openmpi code could be affecting how mmap() is being called? It basically does: mmap(NULL, real_size, PROT_READ | PROT_WRITE, MAP_SHARED, seg_id, 0) Well, it turns out that openmpi is intercepting the mmap call, so it seems to be an incompatibility with how it is doing that now. Still no idea what, but hopefully openmpi upstream will have some ideas. -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
mmap() being called instead of mmap2() on i686 Rawhide
I *think* I may have found a bug in glibc in rawhide, but I'm not sure. I figured I would ask here first before filing a bug. I'm trying to track down a shared memory issue in openmpi on i686 rawhide: https://bugzilla.redhat.com/show_bug.cgi?id=2142304 https://github.com/open-mpi/ompi/issues/11065 and the oddity that I'm looking at now is that a strange mmap() system call is being made rather than mmap2() which appears to be standard on i686: [pid84] 19:38:24 mmap(NULL) = -1 EFAULT (Bad address) normally I see calls like: [pid 157] mmap2(NULL, 62328, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 24, 0) = 0xf5a74000 Now is there any way that the openmpi code could be affecting how mmap() is being called? It basically does: mmap(NULL, real_size, PROT_READ | PROT_WRITE, MAP_SHARED, seg_id, 0) on a file it created in /dev/shm/. Thanks. -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Include minor version number in packaged Python shebangs
On 12/10/22 06:38, Neal Gompa wrote: On Fri, Dec 9, 2022 at 5:04 PM Audrey Toskin wrote: DNF modules let you install multiple different versions of Python 3, and the `alternatives` tool lets you change which is the default version invoked by `/usr/bin/python3`. However, at least for *Enterprise Linux 8, it seems a lot of packages were built assuming the distro's default Python 3.6, but at runtime only invoke "Python 3", not 3.6 specifically. It seems that I still need Python 3.6 for most packages installed via DNF on EL8, but I also definitely need Python 3.8+ for multiple packages I use installed with PIP. So, the workaround to having both installed on my system at the same time would be to edit the shebangs to include the minor version of Python that each application requires. ...Right? I wanted a sanity check before I bother sending spam to EPEL package maintainers. Or, is this even a reasonable thing to ask package maintainers to change, or should I just start patching the local shebangs myself? Or is there a better solution? RHEL 8 has brp-mangle-shebangs, and when correctly invoked (which EPEL should do already), the interpreter path is already rewritten for you. My packages in EPEL 8 seem to have this, at least. Yeah, this should get done automatically, but on my system at least there are some files in /usr/bin without the minor version: /usr/bin/django-admin:#!/usr/bin/python3 /usr/bin/django-admin-3:#!/usr/bin/python3 /usr/bin/django-admin-3.6:#!/usr/bin/python3 /usr/bin/fedpkg:#!/usr/bin/python3 /usr/bin/ipython:#!/usr/bin/python3 /usr/bin/ipython3:#!/usr/bin/python3 /usr/bin/koji:#!/usr/bin/python3 /usr/bin/python3-django-admin:#!/usr/bin/python3 /usr/bin/suricatactl:#!/usr/bin/python3 /usr/bin/suricatasc:#!/usr/bin/python3 /usr/bin/suricata-update:#!/usr/bin/python3 -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: OpenMPI tests blocked
On 11/11/22 07:52, Christoph Junghans wrote: On Thu, Nov 10, 2022 at 10:27 PM Orion Poplawski wrote: On 11/6/22 07:31, Dominik 'Rathann' Mierzejewski wrote: On Saturday, 05 November 2022 at 21:27, Antonio T. sagitter wrote: Hi all. Many OpenMPI tests in RPM packaging are blocked for unknown reason, no output or error, just hanged until test timeout. For example, PETSc test is blocked with this message: Executing: /usr/lib64/openmpi/bin/mpiexec -n 8 --mca btl_base_warn_component_unused 0 -n 1 /tmp/petsc-p7fo3olx/config.packages.MPI/conftest Running Executable with threads to time it out at 120 Executing: /usr/lib64/openmpi/bin/mpiexec -n 8 --mca btl_base_warn_component_unused 0 -n 1 /tmp/petsc-p7fo3olx/config.packages.MPI/conftest Runaway process exceeded time limit of 120 ERROR while running executable: Could not execute "['/usr/lib64/openmpi/bin/mpiexec -n 8 --mca btl_base_warn_component_unused 0 -n 1 /tmp/petsc-p7fo3olx/config.packages.MPI/conftest']": Runaway process exceeded time limit of 120 Something like this happened with Sundials and Ipopt, when OpenMPI is used, not with MPICH. At this time, these tests in Rawhide (and ELN) cannot be executed. I've got the same issue with elpa. OpenMPI hangs, MPICH works fine. Let's open a bug against OpenMPI and compare notes. ;) Regards, Dominik We have: https://bugzilla.redhat.com/show_bug.cgi?id=2141137 I've reported it upstream as well. Hopefully they can help. openSUSE had a similar bug: https://bugzilla.opensuse.org/show_bug.cgi?id=1205139 Maybe that is related. Christoph Thank you! I believe that is it exactly. -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: OpenMPI tests blocked
On 11/6/22 07:31, Dominik 'Rathann' Mierzejewski wrote: On Saturday, 05 November 2022 at 21:27, Antonio T. sagitter wrote: Hi all. Many OpenMPI tests in RPM packaging are blocked for unknown reason, no output or error, just hanged until test timeout. For example, PETSc test is blocked with this message: Executing: /usr/lib64/openmpi/bin/mpiexec -n 8 --mca btl_base_warn_component_unused 0 -n 1 /tmp/petsc-p7fo3olx/config.packages.MPI/conftest Running Executable with threads to time it out at 120 Executing: /usr/lib64/openmpi/bin/mpiexec -n 8 --mca btl_base_warn_component_unused 0 -n 1 /tmp/petsc-p7fo3olx/config.packages.MPI/conftest Runaway process exceeded time limit of 120 ERROR while running executable: Could not execute "['/usr/lib64/openmpi/bin/mpiexec -n 8 --mca btl_base_warn_component_unused 0 -n 1 /tmp/petsc-p7fo3olx/config.packages.MPI/conftest']": Runaway process exceeded time limit of 120 Something like this happened with Sundials and Ipopt, when OpenMPI is used, not with MPICH. At this time, these tests in Rawhide (and ELN) cannot be executed. I've got the same issue with elpa. OpenMPI hangs, MPICH works fine. Let's open a bug against OpenMPI and compare notes. ;) Regards, Dominik We have: https://bugzilla.redhat.com/show_bug.cgi?id=2141137 I've reported it upstream as well. Hopefully they can help. -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Non-responsive maintainer check for deji - grads
Non-responsive maintainer check for deji Mainly for grads: https://bugzilla.redhat.com/show_bug.cgi?id=2140875 But there is also an old bug for TexMaker: https://bugzilla.redhat.com/show_bug.cgi?id=2088781 Has anyone else heard from Deji? Is anyone else interested in taking over grads or TexMaker should it come to that? Thanks, Orion ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Is is worth packaging PHP stuff in EPEL8+?
Is is worth packaging PHP stuff in EPEL8+? It seems very modular in RHEL and Remi's repos, but EPEL isn't doing modules. If it is worthwhile, is anyone interested in helping out? I was hoping to get mediawiki 1.35 into EPEL8. Orion -- Orion Poplawski IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
%set_build_flags, clang/flang-new and FC/FCFLAGS
While poking at building openmpi with clang, I started wondering about flang and some things: * Should %set_build_flags set FC? I think it should since it sets FCFLAGS. * Is flang-new even worth bothering with? See the following configure check: configure:32655: flang-new -c -O2 -flto -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS --config /usr/lib/rpm/redhat/redhat-hardened-clang.cfg -fstack-protector-strong -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -I/usr/lib64/gfortran/modules conftest.F >&5 flang-new: warning: argument unused during compilation: '-fexceptions' flang-new: warning: argument unused during compilation: '-g' flang-new: warning: argument unused during compilation: '-grecord-command-line' flang-new: warning: argument unused during compilation: '-Wall' flang-new: warning: argument unused during compilation: '-Wp,-D_FORTIFY_SOURCE=2' flang-new: warning: argument unused during compilation: '-Wp,-D_GLIBCXX_ASSERTIONS' flang-new: warning: argument unused during compilation: '-fstack-protector-strong' flang-new: warning: argument unused during compilation: '-mtune=generic' flang-new: warning: argument unused during compilation: '-fasynchronous-unwind-tables' flang-new: warning: argument unused during compilation: '-fstack-clash-protection' flang-new: warning: argument unused during compilation: '-fcf-protection=full' error: Only `-Werror` is supported currently. Of particular note is ignoring the '-g' option. * If we do, it looks like we need a different set of FCFLAGS for flang-new - in particular dropping the -Werror=format-security option as seen above, as well as LTO options per: configure:33152: flang-new -o conftest -O2 -flto -fexceptions -g -grecord-gcc-switches -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS --config /usr/lib/rpm/redhat/redhat-hardened-clang.cfg -fstack-protector-strong -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -I/usr/lib64/gfortran/modules -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -flto -fno-openmp-implicit-rpath -Wl,--build-id=sha1 conftest.f >&5 flang-new: warning: argument unused during compilation: '-fexceptions' flang-new: warning: argument unused during compilation: '-grecord-command-line' flang-new: warning: argument unused during compilation: '-Wall' flang-new: warning: argument unused during compilation: '-Wp,-D_FORTIFY_SOURCE=2' flang-new: warning: argument unused during compilation: '-Wp,-D_GLIBCXX_ASSERTIONS' flang-new: warning: argument unused during compilation: '-fstack-protector-strong' flang-new: warning: argument unused during compilation: '-mtune=generic' flang-new: warning: argument unused during compilation: '-fasynchronous-unwind-tables' flang-new: warning: argument unused during compilation: '-fstack-clash-protection' flang-new: warning: argument unused during compilation: '-fcf-protection=full' /usr/bin/ld: error: LLVM gold plugin has failed to create LTO module: input module has no datalayout flang-new: error: linker command failed with exit code 1 (use -v to see invocation) I started poking at implementing this in redhat-rpm-config, but it seems pretty tricky as for the most part we seem to assume that every compiler can accept the same set of flags. This also bites us if we try to use gfortran with clang as I end up with it trying to use the clang config. configure:33152: gfortran -o conftest -O2 -flto -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS --config /usr/lib/rpm/redhat/redhat-hardened-clang.cfg -fstack-protector-strong -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -I/usr/lib64/gfortran/modules -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -flto -fno-openmp-implicit-rpath -Wl,--build-id=sha1 conftest.f >&5 gfortran: error: unrecognized command-line option '--config'; did you mean '-mpconfig'? gfortran: error: unrecognized command-line option '-fno-openmp-implicit-rpath' Thoughts? -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedorapro
