Re: rpmbuild core dumps
* Sam Varshavchik: > Stephen Smoogen writes: > >>https://github.com/rpm-software-management/rpm/issues/ >>2826>https://github.com/rpm-software-management/rpm/issues/2826 >> >> >> And thanks for opening a bug. I will watch to see what happens. > > I'm genuinely curious. Am I really the only one seeing this? The bug > seems fairly clear cut to me. What the heck. I suspect most of us package only files from one user, so the cache never needs evicting? Thanks, Florian -- ___ 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: Update on the Modern C initiative
* Solomon Peachy via devel: > On Fri, Dec 22, 2023 at 10:27:55PM +0100, Florian Weimer wrote: >> >> gutenprint jpopelka jridky twaugh zdohnal >> > ...FWIW as of a few minutes ago this should be resolved upstream. >> >> Thanks, I can confirm this fixes the issue for the Fedora package as >> well. Should I push this to rawhide? It makes tracking easier for us. > > Yes please! > > There's no good reason for not having rawhide track Gutenprint upstream. > > IMO it should get pulled into current Fedora versions too; the first > thing I tell anyone reporting an issue is to rebuild from current > sources. (Granted most of those users are on EL/LTS-type distros..) Oh, I meant to backport just this one fix. I'll look into that later this week. Thanks, Florian -- ___ 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: rpmbuild core dumps
On 1/2/24 11:49, Florian Weimer wrote: * Sam Varshavchik: Stephen Smoogen writes: https://github.com/rpm-software-management/rpm/issues/ 2826>https://github.com/rpm-software-management/rpm/issues/2826 And thanks for opening a bug. I will watch to see what happens. I'm genuinely curious. Am I really the only one seeing this? The bug seems fairly clear cut to me. What the heck. I suspect most of us package only files from one user, so the cache never needs evicting? Indeed. Technically the "thread-unsafe" bug has been there since rpm 4.15 which was the first version to parallelize the package generation. It's just that 4.19 eliminates some code that has previously managed to more or less mask it it seems. It could've manifested as silent user/group name corruption before this AFAICS. - Panu - -- ___ 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
RISC-V ABI issue with ULEB128
I'm not sure exactly the effect on RISC-V binaries, but I wanted to raise it here to get the attention of the Fedora toolchain team ... Here's the bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31179 RISC-V: The SET/ADD/SUB fix breaks ABI compatibility with 2.41 objects It refers to this change in binutils 2.41: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=73d931e560059a87d76f528fafbb4270a98746bc As far as I understand the issue (which is not too far) this mainly affects shipped *.o and *.a files (ie. static libraries and similar) which were compiled with binutils < 2.41, which either won't link correctly or will give a linker error when using GNU ld from binutils 2.41. Unclear if it also affects *.so files (which would be a much more serious ABI break), and also if it affects most binaries or just a few. I initially thought this only affected programs using 128 bit ints, so didn't think it was too important, but after reading the commit I'm not sure that is really true. There's been discussion about adding an ELF tag, but that seems very problematic to me: https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/414 Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v -- ___ 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: F40 Change Proposal: Optimized Binaries for the AMD64 Architecture (System-Wide)
Dne 28. 12. 23 v 17:12 Aoife Moloney napsal(a): The dynamic linker already has the `glibc-hwcaps` mechanism to load optimized implementations of ''shared objects'' [3]. This means that packages can provide optimized libraries and they linker will be automatically load them from separate directories if appropriate. (For AMD64, this is `/usr/lib64/glibc-hwcaps/x86-64-v{2,3,4}/`.) Is this something specific to x86_64 that the libs needs to be nested in a place such as `/usr/lib64/glibc-hwcaps/x86-64-v{2,3,4}/`? Why not use e.g. `/usr/x86-64-v{2,3,4}/lib` directories instead? Or something more universal. Vít OpenPGP_signature.asc Description: OpenPGP digital 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
Fedora rawhide compose report: 20240102.n.0 changes
OLD: Fedora-Rawhide-20240101.n.0 NEW: Fedora-Rawhide-20240102.n.0 = SUMMARY = Added images:5 Dropped images: 2 Added packages: 5 Dropped packages:0 Upgraded packages: 36 Downgraded packages: 0 Size of added packages: 3.20 MiB Size of dropped packages:0 B Size of upgraded packages: 1.80 GiB Size of downgraded packages: 0 B Size change of upgraded packages: -66.67 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Container_Minimal_Base docker ppc64le Path: Container/ppc64le/images/Fedora-Container-Minimal-Base-Rawhide-20240102.n.0.ppc64le.tar.xz Image: Workstation live aarch64 Path: Workstation/aarch64/iso/Fedora-Workstation-Live-aarch64-Rawhide-20240102.n.0.iso Image: Workstation live-osbuild x86_64 Path: Workstation/x86_64/iso/Fedora-Workstation-Live-osb-Rawhide-20240102.n.0.x86_64.iso Image: Jam_KDE live x86_64 Path: Labs/x86_64/iso/Fedora-Jam_KDE-Live-x86_64-Rawhide-20240102.n.0.iso Image: Workstation live-osbuild aarch64 Path: Workstation/aarch64/iso/Fedora-Workstation-Live-osb-Rawhide-20240102.n.0.aarch64.iso = DROPPED IMAGES = Image: KDE live aarch64 Path: Spins/aarch64/iso/Fedora-KDE-Live-aarch64-Rawhide-20240101.n.0.iso Image: Kinoite dvd-ostree ppc64le Path: Kinoite/ppc64le/iso/Fedora-Kinoite-ostree-ppc64le-Rawhide-20240101.n.0.iso = ADDED PACKAGES = Package: krdp-5.27.80~git20231227.4931015-1.fc40 Summary: Library for creating an RDP server RPMs:krdp krdp-devel krdp-server Size:770.71 KiB Package: python-esbonio-0.16.3-1.fc40 Summary: A Language Server for Sphinx projects RPMs:python3-esbonio python3-esbonio+dev python3-esbonio+test python3-esbonio+typecheck Size:328.23 KiB Package: python-geodatasets-2023.12.0-1.fc40 Summary: Spatial data examples RPMs:python3-geodatasets Size:43.72 KiB Package: python-types-pygments-2.17.0.0-1.fc40 Summary: Typing stubs for Pygments RPMs:python3-types-pygments Size:30.24 KiB Package: zimpl-3.5.3-1.fc40 Summary: Zuse Institut Mathematical Programming Language RPMs:libzimpl libzimpl-devel zimpl Size:2.05 MiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: alglib-4.01.0-1.fc40 Old package: alglib-4.00.0-2.fc39 Summary: A numerical analysis and data processing library RPMs: alglib alglib-devel alglib-doc Size: 9.57 MiB Size change: 678.34 KiB Changelog: * Mon Jan 01 2024 Sandro Mani - 4.01.0-1 - Update to 4.01.0 Package: atasm-1.23-1.fc40 Old package: atasm-1.09-6.fc39 Summary: 6502 cross-assembler RPMs: atasm Size: 328.94 KiB Size change: 51.46 KiB Changelog: * Mon Jan 01 2024 Dan Hor??k - 1.24-1 - update to 1.23 from an active fork Package: catch-3.5.1-1.fc40 Old package: catch-3.5.0-1.fc40 Summary: Modern, C++-native, header-only, framework for unit-tests, TDD and BDD RPMs: catch catch-devel Size: 2.88 MiB Size change: -11.34 KiB Changelog: * Mon Jan 01 2024 Tom Hughes - 3.5.1-1 - Update to 3.5.1 upstream release Package: contour-terminal-0.4.1.6292-1.fc40 Old package: contour-terminal-0.4.0.6245-1.fc40 Summary: Modern C++ Terminal Emulator RPMs: contour-terminal Size: 2.15 MiB Size change: -412 B Changelog: * Wed Dec 20 2023 Maja Massarini - 0.4.0.6245-2 - Add upstream_tag_template in .packit.yaml * Wed Dec 20 2023 topazus - 0.4.0.6245-3 - remove the duplicate packit config file * Mon Jan 01 2024 topazus - 0.4.0.6245-4 - fix for unexisted file with new release 0.4.1.6292 * Mon Jan 01 2024 Packit - 0.4.1.6292-1 - [packit] 0.4.1.6292 upstream release - Resolves rhbz#2256368 Package: edgar-1.37-1.fc40 Old package: edgar-1.36-3.fc39 Summary: A platform game RPMs: edgar Size: 489.71 MiB Size change: -4.14 KiB Changelog: * Mon Jan 01 2024 Andrea Musuruane - 1.37-1 - Updated to new upstream release Package: ghostwriter-24.01.85-1.fc40 Old package: ghostwriter-23.08.2-1.fc40 Summary: Cross-platform, aesthetic, distraction-free Markdown editor RPMs: ghostwriter Size: 7.90 MiB Size change: 2.94 MiB Changelog: * Sat Dec 30 2023 Marie Loise Nolden - 24.01.85-1 - 24.01.85 Package: ginga-4.1.1-1.fc40 Old package: ginga-4.0.1-4.fc39 Summary: A scientific image viewer and toolkit RPMs: ginga python3-ginga python3-ginga+qt5 python3-ginga+recommended python3-ginga-examples Size: 7.66 MiB Size change: 3.81 KiB Changelog: * Tue Jan 02 2024 Sergio Pascual - 4.1.1-1 - Update to 4.1.1 - Using SPDX license name Package: gmsh-4.12.0-1.fc40 Old package: gmsh-4.11.1-7.fc40 Summary: A three-dimensional finite element mesh generator RPMs: gmsh gmsh-common gmsh-devel gmsh-doc gmsh-libs gmsh-mpich gmsh-mpich-devel gmsh-mpich-libs gmsh-openmpi gmsh-openmpi-devel gmsh-openmpi-libs python3-gmsh Size: 63.92 MiB Size change: 546.67 KiB
Re: F40 Change Proposal: Optimized Binaries for the AMD64 Architecture (System-Wide)
On Tue, 2 Jan 2024 at 06:21, Vít Ondruch wrote: > > Dne 28. 12. 23 v 17:12 Aoife Moloney napsal(a): > > The dynamic linker already has the `glibc-hwcaps` mechanism to load > optimized implementations of ''shared objects'' [3]. This means that > packages can provide optimized libraries and they linker will be > automatically load them from separate directories if appropriate. > (For AMD64, this is `/usr/lib64/glibc-hwcaps/x86-64-v{2,3,4}/`.) > > > > Is this something specific to x86_64 that the libs needs to be nested in a > place such as `/usr/lib64/glibc-hwcaps/x86-64-v{2,3,4}/`? Why not use e.g. > `/usr/x86-64-v{2,3,4}/lib` > directories instead? Or something more universal. > > Adding directories to the /usr sub-space generally gets bogged down into 'You are polluting my name-space' arguments which get no-where because some of the people getting angry is having to live with some 3rd party rules and regulations which stipulated how things look and will only get updated once a decade or so. [The same goes with subdirectories in /usr/bin etc where it causes similar problems.] There tends to be no 'general' case which works unless it gets 'agreed' upon by some outside of the distro body that publishes 'versioned' standards. > Vít > -- > ___ > 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 > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren -- ___ 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: RISC-V ABI issue with ULEB128
On Tue, Jan 2, 2024 at 1:09 PM Richard W.M. Jones wrote: > > > I'm not sure exactly the effect on RISC-V binaries, but I wanted to > raise it here to get the attention of the Fedora toolchain team ... > > Here's the bug: > > https://sourceware.org/bugzilla/show_bug.cgi?id=31179 > RISC-V: The SET/ADD/SUB fix breaks ABI compatibility with 2.41 objects > > It refers to this change in binutils 2.41: > > https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=73d931e560059a87d76f528fafbb4270a98746bc > > As far as I understand the issue (which is not too far) this mainly > affects shipped *.o and *.a files (ie. static libraries and similar) > which were compiled with binutils < 2.41, which either won't link > correctly or will give a linker error when using GNU ld from binutils 2.41. Correction. This is broken in <= 2.41 (incl. the current stable binutils release). > > Unclear if it also affects *.so files (which would be a much more > serious ABI break), and also if it affects most binaries or just a > few. I initially thought this only affected programs using 128 bit > ints, so didn't think it was too important, but after reading the > commit I'm not sure that is really true. Nelson Chu committed (5 days ago) a change: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=73d931e560059a87d76f528fafbb4270a98746bc This will accept whatever is produced by <= 2.41 and the final binary will be correct. There is also a new ld flag (--check-uleb128) which can produce a warning if it detects an issue. I plan/hope to use binutils 2.42 in Fedora/RISCV 40. That would happen before I start mass rebuilding, and that should fix this. > > There's been discussion about adding an ELF tag, but that seems very > problematic to me: > https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/414 Yeah. I doubt we need a tag. I don't think it solves anything. Nelson commit (i.e. workaround) + mass rebuild should resolve any inconveniences AFAIK. Cheers, david > > Rich. > > -- > Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones > Read my programming and virtualization blog: http://rwmj.wordpress.com > virt-p2v converts physical machines to virtual machines. Boot with a > live CD or over the network (PXE) and turn machines into KVM guests. > http://libguestfs.org/virt-v2v > -- > ___ > 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
flrig: C++ warning help
While it's only a warning, I would like to "fix" it. When building flrig I'm seeing the following: widgets/font_browser.cxx: In member function '__ct_base .constprop': widgets/font_browser.cxx:202:52: warning: argument 1 value '18446744073709551615' exceeds maximum object size 9223372036854775807 [-Walloc-size-larger-than=] 202 | font_pairs = new font_pair[numfonts]; |^ The code can be found here: https://sourceforge.net/p/fldigi/flrig/ci/master/tree/src/widgets/font_browser.cxx#l201 Any hints would be appreciated. Thanks, Richard -- ___ 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: F40 Change Proposal: Optimized Binaries for the AMD64 Architecture (System-Wide)
On Tue, Jan 2, 2024 at 1:20 PM Vít Ondruch wrote: > > > Dne 28. 12. 23 v 17:12 Aoife Moloney napsal(a): > > The dynamic linker already has the `glibc-hwcaps` mechanism to load > optimized implementations of ''shared objects'' [3]. This means that > packages can provide optimized libraries and they linker will be > automatically load them from separate directories if appropriate. > (For AMD64, this is `/usr/lib64/glibc-hwcaps/x86-64-v{2,3,4}/`.) > > > Is this something specific to x86_64 that the libs needs to be nested in a > place such as `/usr/lib64/glibc-hwcaps/x86-64-v{2,3,4}/`? Why not use e.g. > `/usr/x86-64-v{2,3,4}/lib` directories instead? Or something more universal. IIRC this is not specific to x86_64 (other arches can also use it). This is specific to glibc implementation (implemented 4 years ago IIRC). The paths glibc dynamic loader looks for shared libraries does not change, but it will check specific subdirectories based on your hardware capabilities. I believe openSUSE already ships optional architecture optimized packages, which use exactly this glibc feature. david > > Vít > > -- > ___ > 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
Re: RISC-V ABI issue with ULEB128
* David Abdurachmanov: > On Tue, Jan 2, 2024 at 1:09 PM Richard W.M. Jones wrote: >> >> >> I'm not sure exactly the effect on RISC-V binaries, but I wanted to >> raise it here to get the attention of the Fedora toolchain team ... >> >> Here's the bug: >> >> https://sourceware.org/bugzilla/show_bug.cgi?id=31179 >> RISC-V: The SET/ADD/SUB fix breaks ABI compatibility with 2.41 objects >> >> It refers to this change in binutils 2.41: >> >> https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=73d931e560059a87d76f528fafbb4270a98746bc >> >> As far as I understand the issue (which is not too far) this mainly >> affects shipped *.o and *.a files (ie. static libraries and similar) >> which were compiled with binutils < 2.41, which either won't link >> correctly or will give a linker error when using GNU ld from binutils 2.41. > > Correction. This is broken in <= 2.41 (incl. the current stable > binutils release). > >> >> Unclear if it also affects *.so files (which would be a much more >> serious ABI break), and also if it affects most binaries or just a >> few. I initially thought this only affected programs using 128 bit >> ints, so didn't think it was too important, but after reading the >> commit I'm not sure that is really true. > > Nelson Chu committed (5 days ago) a change: > > https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=73d931e560059a87d76f528fafbb4270a98746bc > > This will accept whatever is produced by <= 2.41 and the final binary > will be correct. There is also a new ld flag (--check-uleb128) which > can produce a warning if it detects an issue. > > I plan/hope to use binutils 2.42 in Fedora/RISCV 40. That would happen > before I start mass rebuilding, and that should fix this. Cc:ing Nick and Siddhesh for awareness. The current plan is to use binutils 2.41 for the mass rebuild. Thanks, Florian -- ___ 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: F40 Change Proposal: Optimized Binaries for the AMD64 Architecture (System-Wide)
* Vít Ondruch: > Dne 28. 12. 23 v 17:12 Aoife Moloney napsal(a): > > > The dynamic linker already has the `glibc-hwcaps` mechanism to load > optimized implementations of ''shared objects'' [3]. This means that > packages can provide optimized libraries and they linker will be > automatically load them from separate directories if appropriate. > (For AMD64, this is `/usr/lib64/glibc-hwcaps/x86-64-v{2,3,4}/`.) > > Is this something specific to x86_64 that the libs needs to be nested > in a place such as `/usr/lib64/glibc-hwcaps/x86-64-v{2,3,4}/`? Why not > use e.g. `/usr/x86-64-v{2,3,4}/lib` directories instead? Or something > more universal. The path layout was chosen so that ldconfig can auto-detect the directories and process their contents, without having to know which subdirectories are recognized by the dynamic loader (and in fact, arbitrary directories can be added using ld.so --glibc-hwcaps-prepend). Thanks, Florian -- ___ 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: RISC-V ABI issue with ULEB128
On Tue, Jan 2, 2024 at 3:54 PM Florian Weimer wrote: > > * David Abdurachmanov: > > > On Tue, Jan 2, 2024 at 1:09 PM Richard W.M. Jones wrote: > >> > >> > >> I'm not sure exactly the effect on RISC-V binaries, but I wanted to > >> raise it here to get the attention of the Fedora toolchain team ... > >> > >> Here's the bug: > >> > >> https://sourceware.org/bugzilla/show_bug.cgi?id=31179 > >> RISC-V: The SET/ADD/SUB fix breaks ABI compatibility with 2.41 objects > >> > >> It refers to this change in binutils 2.41: > >> > >> https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=73d931e560059a87d76f528fafbb4270a98746bc > >> > >> As far as I understand the issue (which is not too far) this mainly > >> affects shipped *.o and *.a files (ie. static libraries and similar) > >> which were compiled with binutils < 2.41, which either won't link > >> correctly or will give a linker error when using GNU ld from binutils 2.41. > > > > Correction. This is broken in <= 2.41 (incl. the current stable > > binutils release). > > > >> > >> Unclear if it also affects *.so files (which would be a much more > >> serious ABI break), and also if it affects most binaries or just a > >> few. I initially thought this only affected programs using 128 bit > >> ints, so didn't think it was too important, but after reading the > >> commit I'm not sure that is really true. > > > > Nelson Chu committed (5 days ago) a change: > > > > https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=73d931e560059a87d76f528fafbb4270a98746bc > > > > This will accept whatever is produced by <= 2.41 and the final binary > > will be correct. There is also a new ld flag (--check-uleb128) which > > can produce a warning if it detects an issue. > > > > I plan/hope to use binutils 2.42 in Fedora/RISCV 40. That would happen > > before I start mass rebuilding, and that should fix this. > > Cc:ing Nick and Siddhesh for awareness. > > The current plan is to use binutils 2.41 for the mass rebuild. In Fedora/RISCV we typically end up using the latest available binutils. We are slightly different from upstream/normal Fedora. Cheers, david > > Thanks, > Florian > -- ___ 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: F40 Change Proposal: Optimized Binaries for the AMD64 Architecture (System-Wide)
Dne 02. 01. 24 v 13:42 Stephen Smoogen napsal(a): On Tue, 2 Jan 2024 at 06:21, Vít Ondruch wrote: Dne 28. 12. 23 v 17:12 Aoife Moloney napsal(a): The dynamic linker already has the `glibc-hwcaps` mechanism to load optimized implementations of ''shared objects'' [3]. This means that packages can provide optimized libraries and they linker will be automatically load them from separate directories if appropriate. (For AMD64, this is `/usr/lib64/glibc-hwcaps/x86-64-v{2,3,4}/`.) Is this something specific to x86_64 that the libs needs to be nested in a place such as `/usr/lib64/glibc-hwcaps/x86-64-v{2,3,4}/`? Why not use e.g. `/usr/x86-64-v{2,3,4}/lib` directories instead? Or something more universal. Adding directories to the /usr sub-space generally gets bogged down into 'You are polluting my name-space' arguments which get no-where because some of the people getting angry is having to live with some 3rd party rules and regulations which stipulated how things look and will only get updated once a decade or so. [The same goes with subdirectories in /usr/bin etc where it causes similar problems.] There tends to be no 'general' case which works unless it gets 'agreed' upon by some outside of the distro body that publishes 'versioned' standards. Checking what Debian does, they have paths such as `/usr/lib/x86_64-linux-gnu/`. So we would not be alone. Vít Vít -- ___ 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 -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren -- ___ devel mailing list --devel@lists.fedoraproject.org To unsubscribe send an email todevel-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 OpenPGP_signature.asc Description: OpenPGP digital 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: F40 Change Proposal: Optimized Binaries for the AMD64 Architecture (System-Wide)
On Tue, 2 Jan 2024 at 10:24, Vít Ondruch wrote: > > Dne 02. 01. 24 v 13:42 Stephen Smoogen napsal(a): > > > > On Tue, 2 Jan 2024 at 06:21, Vít Ondruch wrote: > >> >> Dne 28. 12. 23 v 17:12 Aoife Moloney napsal(a): >> >> The dynamic linker already has the `glibc-hwcaps` mechanism to load >> optimized implementations of ''shared objects'' [3]. This means that >> packages can provide optimized libraries and they linker will be >> automatically load them from separate directories if appropriate. >> (For AMD64, this is `/usr/lib64/glibc-hwcaps/x86-64-v{2,3,4}/`.) >> >> >> >> Is this something specific to x86_64 that the libs needs to be nested in >> a place such as `/usr/lib64/glibc-hwcaps/x86-64-v{2,3,4}/`? Why not use >> e.g. `/usr/x86-64-v{2,3,4}/lib` directories instead? Or something more >> universal. >> >> > Adding directories to the /usr sub-space generally gets bogged down into > 'You are polluting my name-space' arguments which get no-where because some > of the people getting angry is having to live with some 3rd party rules and > regulations which stipulated how things look and will only get updated once > a decade or so. [The same goes with subdirectories in /usr/bin etc where it > causes similar problems.] There tends to be no 'general' case which works > unless it gets 'agreed' upon by some outside of the distro body that > publishes 'versioned' standards. > > > Checking what Debian does, they have paths such as > `/usr/lib/x86_64-linux-gnu/`. So we would not be alone. > Do they have /usr/bin/{arch} directories also? I thought they did the /usr/lib/{arch-os-type}/ for libraries to deal with multiarch (aka x86_32, x86_64, etc) libs . the main item will be if we are following https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s04.html or if there is enough variation in https://www.freedesktop.org/software/systemd/man/latest/file-hierarchy.html to allow subdirectories in /usr/bin. It would seem that in the freedesktop version /usr/lib/{arch-id} is acceptable and I think in the FHS-3.0, then /usr/lib{qualifier} is ok. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren -- ___ 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: F40 Change Proposal: Optimized Binaries for the AMD64 Architecture (System-Wide)
On Fri, Dec 29, 2023 at 03:20:45PM -0600, Chris Adams wrote: > Once upon a time, Zbigniew Jędrzejewski-Szmek said: > > But building packages is just one thing. Those packages would need > > to be distributed, causing additional load on mirrors and archives. > > Our mirrors would not be keen on seeing this increase. > > You're adding binaries, so you're either increasing the size of existing > packages or adding alternate packages. The size increase will be there > either way; the difference is that with separate packages, not everybody > will be downloading all the content (so easier on the mirrors than just > bigger packages containing multiple binaries). > > So if distribution is a concern, separate packages is a plus, not a > minus. We don't have a mechanism in dnf/rpm to mix & match, i.e. to select from one microarchitecture if available and from a different one otherwise. So if we were to provide e.g. a -v2 variant, then it'd have to provide _all_ packages. In the proposed scheme, we only provide additional packages for select packages. > > And then there's a question of how those packages would be consumed: > > firstly, the installer would need to be modified to pick the variant > > at installation time, and secondly, such an installation could never > > be used with a different CPU, the initial choice would be locked in. > > It's not like we haven't had this before. Yes, it was annoying, but it > wasn't THAT big of an issue. There is certainly more than one way to skin this particular cat. I don't expect most users to know which microarchitectures are supported by their CPU. We are always trying to make the installer as simple as possible so we shouldn't add a very complex technical question. One of the advantages of the proposed scheme is that we should be able to make it work transparently and automatically for the end users. I know that my approach is different then what other distros have tried: CentoOS/RHEL simply upgraded to a higher baseline and lost support for some CPUs, OpenSUSE/Ubuntu/Arch provide alternative repos which need to be explicitly selected by users. If the proposal gets accepted, we will be able to compare. Zbyszek -- ___ 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: rpmbuild core dumps
Florian Weimer writes: * Sam Varshavchik: > Stephen Smoogen writes: > >>https://github.com/rpm-software-management/rpm/issues/ >>2826>https://github.com/rpm-software-management/rpm/issues/2826 >> >> >> And thanks for opening a bug. I will watch to see what happens. > > I'm genuinely curious. Am I really the only one seeing this? The bug > seems fairly clear cut to me. What the heck. I suspect most of us package only files from one user, so the cache never needs evicting? You know, I think you're right. You need to put files into rpms that have different user and group ownership. Nearly all packages likely %defattr away all files to the same user and group id the race condition never gets triggered. The race condition occurs when the next file that gets added to the rpm is specified to have a different user or group ownership from the previous file. pgpehJrVvEXHx.pgp Description: PGP 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: RISC-V ABI issue with ULEB128
On Tue, Jan 2, 2024 at 2:05 PM David Abdurachmanov wrote: > > On Tue, Jan 2, 2024 at 3:54 PM Florian Weimer wrote: > > > > * David Abdurachmanov: > > > > > On Tue, Jan 2, 2024 at 1:09 PM Richard W.M. Jones > > > wrote: > > >> > > >> > > >> I'm not sure exactly the effect on RISC-V binaries, but I wanted to > > >> raise it here to get the attention of the Fedora toolchain team ... > > >> > > >> Here's the bug: > > >> > > >> https://sourceware.org/bugzilla/show_bug.cgi?id=31179 > > >> RISC-V: The SET/ADD/SUB fix breaks ABI compatibility with 2.41 objects > > >> > > >> It refers to this change in binutils 2.41: > > >> > > >> https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=73d931e560059a87d76f528fafbb4270a98746bc > > >> > > >> As far as I understand the issue (which is not too far) this mainly > > >> affects shipped *.o and *.a files (ie. static libraries and similar) > > >> which were compiled with binutils < 2.41, which either won't link > > >> correctly or will give a linker error when using GNU ld from binutils > > >> 2.41. > > > > > > Correction. This is broken in <= 2.41 (incl. the current stable > > > binutils release). > > > > > >> > > >> Unclear if it also affects *.so files (which would be a much more > > >> serious ABI break), and also if it affects most binaries or just a > > >> few. I initially thought this only affected programs using 128 bit > > >> ints, so didn't think it was too important, but after reading the > > >> commit I'm not sure that is really true. > > > > > > Nelson Chu committed (5 days ago) a change: > > > > > > https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=73d931e560059a87d76f528fafbb4270a98746bc > > > > > > This will accept whatever is produced by <= 2.41 and the final binary > > > will be correct. There is also a new ld flag (--check-uleb128) which > > > can produce a warning if it detects an issue. > > > > > > I plan/hope to use binutils 2.42 in Fedora/RISCV 40. That would happen > > > before I start mass rebuilding, and that should fix this. > > > > Cc:ing Nick and Siddhesh for awareness. > > > > The current plan is to use binutils 2.41 for the mass rebuild. > > In Fedora/RISCV we typically end up using the latest available > binutils. We are slightly different from upstream/normal Fedora. Which is fine when you're an out of mainline architecture but these sorts of things need to be resolved well and truly before any incorporation can happen. -- ___ 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: RISC-V ABI issue with ULEB128
On Tue, Jan 2, 2024 at 6:26 PM Peter Robinson wrote: > > On Tue, Jan 2, 2024 at 2:05 PM David Abdurachmanov > wrote: > > > > On Tue, Jan 2, 2024 at 3:54 PM Florian Weimer wrote: > > > > > > * David Abdurachmanov: > > > > > > > On Tue, Jan 2, 2024 at 1:09 PM Richard W.M. Jones > > > > wrote: > > > >> > > > >> > > > >> I'm not sure exactly the effect on RISC-V binaries, but I wanted to > > > >> raise it here to get the attention of the Fedora toolchain team ... > > > >> > > > >> Here's the bug: > > > >> > > > >> https://sourceware.org/bugzilla/show_bug.cgi?id=31179 > > > >> RISC-V: The SET/ADD/SUB fix breaks ABI compatibility with 2.41 objects > > > >> > > > >> It refers to this change in binutils 2.41: > > > >> > > > >> https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=73d931e560059a87d76f528fafbb4270a98746bc > > > >> > > > >> As far as I understand the issue (which is not too far) this mainly > > > >> affects shipped *.o and *.a files (ie. static libraries and similar) > > > >> which were compiled with binutils < 2.41, which either won't link > > > >> correctly or will give a linker error when using GNU ld from binutils > > > >> 2.41. > > > > > > > > Correction. This is broken in <= 2.41 (incl. the current stable > > > > binutils release). > > > > > > > >> > > > >> Unclear if it also affects *.so files (which would be a much more > > > >> serious ABI break), and also if it affects most binaries or just a > > > >> few. I initially thought this only affected programs using 128 bit > > > >> ints, so didn't think it was too important, but after reading the > > > >> commit I'm not sure that is really true. > > > > > > > > Nelson Chu committed (5 days ago) a change: > > > > > > > > https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=73d931e560059a87d76f528fafbb4270a98746bc > > > > > > > > This will accept whatever is produced by <= 2.41 and the final binary > > > > will be correct. There is also a new ld flag (--check-uleb128) which > > > > can produce a warning if it detects an issue. > > > > > > > > I plan/hope to use binutils 2.42 in Fedora/RISCV 40. That would happen > > > > before I start mass rebuilding, and that should fix this. > > > > > > Cc:ing Nick and Siddhesh for awareness. > > > > > > The current plan is to use binutils 2.41 for the mass rebuild. > > > > In Fedora/RISCV we typically end up using the latest available > > binutils. We are slightly different from upstream/normal Fedora. > > Which is fine when you're an out of mainline architecture but these > sorts of things need to be resolved well and truly before any > incorporation can happen. 100% true. We have plenty of stuff that isn't yet submitted to the official dist-git. I have been considering not going for 2.42 for Fedora 40, but we will do this again one more time (hopefully it's the last time, but you never know). > -- > ___ > 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
Re: RISC-V ABI issue with ULEB128
On Tue, Jan 2, 2024 at 5:15 PM David Abdurachmanov wrote: > > On Tue, Jan 2, 2024 at 6:26 PM Peter Robinson wrote: > > > > On Tue, Jan 2, 2024 at 2:05 PM David Abdurachmanov > > wrote: > > > > > > On Tue, Jan 2, 2024 at 3:54 PM Florian Weimer wrote: > > > > > > > > * David Abdurachmanov: > > > > > > > > > On Tue, Jan 2, 2024 at 1:09 PM Richard W.M. Jones > > > > > wrote: > > > > >> > > > > >> > > > > >> I'm not sure exactly the effect on RISC-V binaries, but I wanted to > > > > >> raise it here to get the attention of the Fedora toolchain team ... > > > > >> > > > > >> Here's the bug: > > > > >> > > > > >> https://sourceware.org/bugzilla/show_bug.cgi?id=31179 > > > > >> RISC-V: The SET/ADD/SUB fix breaks ABI compatibility with 2.41 > > > > >> objects > > > > >> > > > > >> It refers to this change in binutils 2.41: > > > > >> > > > > >> https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=73d931e560059a87d76f528fafbb4270a98746bc > > > > >> > > > > >> As far as I understand the issue (which is not too far) this mainly > > > > >> affects shipped *.o and *.a files (ie. static libraries and similar) > > > > >> which were compiled with binutils < 2.41, which either won't link > > > > >> correctly or will give a linker error when using GNU ld from > > > > >> binutils 2.41. > > > > > > > > > > Correction. This is broken in <= 2.41 (incl. the current stable > > > > > binutils release). > > > > > > > > > >> > > > > >> Unclear if it also affects *.so files (which would be a much more > > > > >> serious ABI break), and also if it affects most binaries or just a > > > > >> few. I initially thought this only affected programs using 128 bit > > > > >> ints, so didn't think it was too important, but after reading the > > > > >> commit I'm not sure that is really true. > > > > > > > > > > Nelson Chu committed (5 days ago) a change: > > > > > > > > > > https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=73d931e560059a87d76f528fafbb4270a98746bc > > > > > > > > > > This will accept whatever is produced by <= 2.41 and the final binary > > > > > will be correct. There is also a new ld flag (--check-uleb128) which > > > > > can produce a warning if it detects an issue. > > > > > > > > > > I plan/hope to use binutils 2.42 in Fedora/RISCV 40. That would happen > > > > > before I start mass rebuilding, and that should fix this. > > > > > > > > Cc:ing Nick and Siddhesh for awareness. > > > > > > > > The current plan is to use binutils 2.41 for the mass rebuild. > > > > > > In Fedora/RISCV we typically end up using the latest available > > > binutils. We are slightly different from upstream/normal Fedora. > > > > Which is fine when you're an out of mainline architecture but these > > sorts of things need to be resolved well and truly before any > > incorporation can happen. > > 100% true. We have plenty of stuff that isn't yet submitted to the > official dist-git. Is that delta easily viewable somewhere? > I have been considering not going for 2.42 for Fedora 40, but we will > do this again one more time (hopefully it's the last time, but you > never know). > > > -- > > ___ > > 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 -- ___ 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: RISC-V ABI issue with ULEB128
On Tue, Jan 2, 2024 at 7:20 PM Peter Robinson wrote: > > On Tue, Jan 2, 2024 at 5:15 PM David Abdurachmanov > wrote: > > > > On Tue, Jan 2, 2024 at 6:26 PM Peter Robinson wrote: > > > > > > On Tue, Jan 2, 2024 at 2:05 PM David Abdurachmanov > > > wrote: > > > > > > > > On Tue, Jan 2, 2024 at 3:54 PM Florian Weimer > > > > wrote: > > > > > > > > > > * David Abdurachmanov: > > > > > > > > > > > On Tue, Jan 2, 2024 at 1:09 PM Richard W.M. Jones > > > > > > wrote: > > > > > >> > > > > > >> > > > > > >> I'm not sure exactly the effect on RISC-V binaries, but I wanted to > > > > > >> raise it here to get the attention of the Fedora toolchain team ... > > > > > >> > > > > > >> Here's the bug: > > > > > >> > > > > > >> https://sourceware.org/bugzilla/show_bug.cgi?id=31179 > > > > > >> RISC-V: The SET/ADD/SUB fix breaks ABI compatibility with 2.41 > > > > > >> objects > > > > > >> > > > > > >> It refers to this change in binutils 2.41: > > > > > >> > > > > > >> https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=73d931e560059a87d76f528fafbb4270a98746bc > > > > > >> > > > > > >> As far as I understand the issue (which is not too far) this mainly > > > > > >> affects shipped *.o and *.a files (ie. static libraries and > > > > > >> similar) > > > > > >> which were compiled with binutils < 2.41, which either won't link > > > > > >> correctly or will give a linker error when using GNU ld from > > > > > >> binutils 2.41. > > > > > > > > > > > > Correction. This is broken in <= 2.41 (incl. the current stable > > > > > > binutils release). > > > > > > > > > > > >> > > > > > >> Unclear if it also affects *.so files (which would be a much more > > > > > >> serious ABI break), and also if it affects most binaries or just a > > > > > >> few. I initially thought this only affected programs using 128 bit > > > > > >> ints, so didn't think it was too important, but after reading the > > > > > >> commit I'm not sure that is really true. > > > > > > > > > > > > Nelson Chu committed (5 days ago) a change: > > > > > > > > > > > > https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=73d931e560059a87d76f528fafbb4270a98746bc > > > > > > > > > > > > This will accept whatever is produced by <= 2.41 and the final > > > > > > binary > > > > > > will be correct. There is also a new ld flag (--check-uleb128) which > > > > > > can produce a warning if it detects an issue. > > > > > > > > > > > > I plan/hope to use binutils 2.42 in Fedora/RISCV 40. That would > > > > > > happen > > > > > > before I start mass rebuilding, and that should fix this. > > > > > > > > > > Cc:ing Nick and Siddhesh for awareness. > > > > > > > > > > The current plan is to use binutils 2.41 for the mass rebuild. > > > > > > > > In Fedora/RISCV we typically end up using the latest available > > > > binutils. We are slightly different from upstream/normal Fedora. > > > > > > Which is fine when you're an out of mainline architecture but these > > > sorts of things need to be resolved well and truly before any > > > incorporation can happen. > > > > 100% true. We have plenty of stuff that isn't yet submitted to the > > official dist-git. > > Is that delta easily viewable somewhere? Kinda. If you list all the builds for the f40 tag in Fedora/RISCV Koji, and then look for the .X.riscv64 pattern before %{?dist} you will get a list of packages that are modified in some way. Today that's around ~277 packages. A good portion of those are easy fixes (e.g. a lot of packages assume that valgrind is available on just any arch, and never check %{valgrind_arches}). Some of the changes are bigger, like full ports, that for one or another reason were not accepted upstream (yet). Not all the changes are good to for a PR. Thus some definitely need some refinement to do the correct thing. Then actual changes are here: http://fedora.riscv.rocks:3000/rpms/ Typically this should have a branch with "-riscv64" suffix, e.g., f38-riscv64 or main-riscv64. I hope to reduce that to a minimum during Fedora 40, but I am not making any promises. Cheers, david > > > I have been considering not going for 2.42 for Fedora 40, but we will > > do this again one more time (hopefully it's the last time, but you > > never know). > > > > > -- > > > ___ > > > 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 > >
Non responsive maintainer check for marxin
Hi folks, Would anyone know how to contact @marxin? They only maintain the one package, python-pebble, but it doesn't look like they've been active in a while. The package did not see to have been updated at all since the initial import: https://bugzilla.redhat.com/show_bug.cgi?id=2227456 and there are now new pending bugs that have not seen responses too: https://bugzilla.redhat.com/show_bug.cgi?id=2250914 We've waited for responses to PRs in the past and then had to use proven packager rights to update and maintain the package: https://src.fedoraproject.org/rpms/python-pebble/pull-request/2 https://src.fedoraproject.org/rpms/python-pebble/commits/rawhide Since a Neuro-SIG package depends on it, we're happy to take it over. Here's what I could get from fedora-active-user: python fedora_active_user.py --user marxin --email mli...@suse.cz --nofas Last action on koji: Fri, 15 Sep 2023 tag_package_owners entry created by humaton [still active] Last package update on bodhi: 2020-06-29 07:10:30 on package python-pebble-4.5.3-1.fc33 Last actions performed according to fedmsg: Last email on mailing list: ERROR:active-user:name 'mailinglist' is not defined Here's the tracker bug: https://bugzilla.redhat.com/show_bug.cgi?id=2256491 -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London signature.asc Description: PGP 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: Non responsive maintainer check for marxin
Does any package depend on python-pebble? I could not find anything running repoquery --whatrequires python-pebble On Tue, Jan 2, 2024 at 2:56 PM Ankur Sinha wrote: > Hi folks, > > Would anyone know how to contact @marxin? They only maintain the one > package, python-pebble, but it doesn't look like they've been active in > a while. The package did not see to have been updated at all since the > initial import: > > https://bugzilla.redhat.com/show_bug.cgi?id=2227456 > > and there are now new pending bugs that have not seen responses too: > https://bugzilla.redhat.com/show_bug.cgi?id=2250914 > > We've waited for responses to PRs in the past and then had to use proven > packager rights to update and maintain the package: > > https://src.fedoraproject.org/rpms/python-pebble/pull-request/2 > https://src.fedoraproject.org/rpms/python-pebble/commits/rawhide > > Since a Neuro-SIG package depends on it, we're happy to take it over. > > Here's what I could get from fedora-active-user: > > python fedora_active_user.py --user marxin --email mli...@suse.cz > --nofas > Last action on koji: >Fri, 15 Sep 2023 tag_package_owners entry created by humaton [still >active] > >Last package update on bodhi: > 2020-06-29 07:10:30 on package python-pebble-4.5.3-1.fc33 > Last actions performed according to fedmsg: > > Last email on mailing list: > ERROR:active-user:name 'mailinglist' is not defined > > > Here's the tracker bug: > https://bugzilla.redhat.com/show_bug.cgi?id=2256491 > > -- > Thanks, > Regards, > Ankur Sinha "FranciscoD" (He / Him / His) | > https://fedoraproject.org/wiki/User:Ankursinha > Time zone: Europe/London > -- > ___ > 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
Re: Non responsive maintainer check for marxin
On 02-01-2024 20:28, Priscila Gutierres wrote: Does any package depend on python-pebble? I could not find anything running repoquery --whatrequires python-pebble You need to query for `python3-pebble`. $ dnf repoquery --whatrequires python3-pebble Last metadata expiration check: 0:04:03 ago on Tue 02 Jan 2024 20:57:02. cvise-0:2.8.0-1.fc39.x86_64 python3-bluepyopt-0:1.14.3-1.fc39.x86_64 python3-bluepyopt-0:1.14.6-5.fc39.x86_64 I use `fedrq` these days. $ fedrq wr -s python3-pebble cvise-2.9.0-1.fc40.src python-bluepyopt-1.14.6-5.fc40.src -- Sandro -- ___ 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: Non responsive maintainer check for marxin
Thank you ! Em ter., 2 de jan. de 2024 às 17:05, Sandro escreveu: > On 02-01-2024 20:28, Priscila Gutierres wrote: > > Does any package depend on python-pebble? > > I could not find anything running repoquery --whatrequires python-pebble > > You need to query for `python3-pebble`. > > $ dnf repoquery --whatrequires python3-pebble > Last metadata expiration check: 0:04:03 ago on Tue 02 Jan 2024 20:57:02. > cvise-0:2.8.0-1.fc39.x86_64 > python3-bluepyopt-0:1.14.3-1.fc39.x86_64 > python3-bluepyopt-0:1.14.6-5.fc39.x86_64 > > I use `fedrq` these days. > > $ fedrq wr -s python3-pebble > cvise-2.9.0-1.fc40.src > python-bluepyopt-1.14.6-5.fc40.src > > -- Sandro > > -- > ___ > 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
Re: F40 Change Proposal: Optimized Binaries for the AMD64 Architecture (System-Wide)
Hi, On 12/28/23 10:12, Aoife Moloney wrote: Wiki -> https://fedoraproject.org/wiki/Changes/Optimized_Binaries_for_the_AMD64_Architecture This is a proposed Change for Fedora Linux. This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Additional paths will be inserted into the search path used for executables on systems which have a compatible CPU. Those additional paths will mirror the AMD64 "microarchitecture levels" supported by the glibc-hwcaps mechanism: `x86-64-v2`, `x86-64-v3`, `x86_64-v4`. Systemd will be modified to insert the additional directories into the `$PATH` environment variable (affecting all programs on the system) and the equivalent internal mechanism in `systemd` (affecting what executables are used by services). Individual packages can provide optimized libraries via the (trimming) Glibc-hwcaps together with the new feature in systemd provide a generic mechanism. It will be up to individual packages to actually provide code which makes use of it. Individual package maintainers are encouraged to benchmark their packages after recompilation, and provide the optimized variants if useful. (I.e. the code in question is measureably faster '''and''' the program is ran often enough for this to make a difference.) The Change Owners will implement the packaging changes for a few packages while developing the general mechanism and will submit those as pull requests. Other maintainers are asked to do the same for their packages. Optimized variants of programs and libraries MAY be packaged in a separate subpackage. The general packaging rules should be applied, i.e. a separate package or packages SHOULD be created if it is files are large enough. Available benchmark results [2,4] are narrow and not very convincing. We should plan an evaluation of results after one release. If it turns out that the real gains are too small, we can scrap the effort. On the other hand, we should also consider other architectures. For example, microarchitecture levels `z{14,15}` for `s390x` or `power{9,10}` for `ppc64le`. Other architectures are not included in this Change Proposal to reduce its scope. While I realize this is intended as an amd64 specific change, I'm interested in helping to assure the infrastructure is in place for similar testing of aarch64 packages, since we have similar problems. There remains a desire to support arm v8.0 machines (ex: the rpi4) into the foreseeable future, but significant uplifts exist for some packages/workloads with newer arch revisions. In most cases those features are currently being enabled at runtime but have perf hits for operations that traditionally are just part of the instruction stream. Outline-atomics, which leverage the v8.2 atomics are one such example, but also SVE (vectors, used for crypto, regex, etc), and more recently the v8.8 CPY (memcpy) should all ideally be inline. So, while some other organizations have moved their platform/OSs to a v8.2 baseline, it would be nice to have another fedora tool that can be utilized to remain perf competitive. == Feedback == == Benefit to Fedora == The developers who are interested in this kind of optimization work can perform it within Fedora, without having to build separate repositories. The users who have the appropriate hardware will gain performance benefits. Faster code is also more energy-efficient. The change will be automatic and transparent to users. Note that other distributions use higher microarchitecture levels. For example RHEL 9 uses x86-64-v2 as the baseline, RHEL 10 will use x86-64-v3, and other distros provide optimized variants (OpenSUSE, Arch Linux). We implement the same change in Fedora in a way that is scoped more narrowly, but should provide the same performance and energy benefits. == Scope == * Proposal owners: ** Extend systemd to set the executable search path using the same criteria as the dynamic linker. ** Implement packaging changes for at least one package with a library and at least one package with executables and submit this as pull requests. ** Provide a pull request for the Packaging Guidelines to describe the changes listed in Description above. * Other developers: ** Do benchmarking and implement packaging changes for other packages if beneficial. * Release engineering: [https://pagure.io/releng/issue/11864 #11864] * Policies and guidelines: TBD. * Trademark approval: N/A (not needed for this Change) * Alignment with Community Initiatives: == Upgrade/compatibility impact == No impact. == How To Test == * Use `/usr/bin/ld.so --help` to check which hwcaps are supported by the system. * Install one or more packages which provide optimized code. * Restart the system or re-login to reinitialize `$PATH`. * Check that appropriate directo
Re: F40 Change Proposal: Optimized Binaries for the AMD64 Architecture (System-Wide)
On 12/31/23 18:27, Dominique Martinet wrote: John Reiser wrote on Sun, Dec 31, 2023 at 02:52:53PM -0800: Additional paths will be inserted into the search path used for executables on systems which have a compatible CPU. Searching $PATH is a slow operation. It is so slow that a shell script which typically processes many files using utilities from packages coreutils and/or binutils often factors-out the PATH search by using shell variables: CP=$(which cp) ... $(CP) $file.in $file.out (getting slighly off topic, sorry) That hasn't been needed for as long as I've used a compter, all^W most shells already do this for you. (It's obvious in interactive mode when you need to use hash/rehash built-ins after moving a binary that you ran once, but it's true as well when running scripts: if you e.g. strace for stat() calls a script that calls cp twice you'll see it only looks through PATH once. This is true of at least bash, zsh, dash, and even busybox ash... Interestingly fish doesn't seem to do it, I'm a bit surpised here) Some programs DO search $PATH because they use execlp() or execvp() or execvpe(). Example of /usr/bin/rpm searching for "sh": = [edited for clarity] $ echo $PATH /A:/B:/usr/local/bin:/usr/bin: ... $ strace -f -e trace=newfstatat rpm --install -p zip-3.0-37.fc38.src.rpm 19792 newfstatat(AT_FDCWD, "/A/sh", 0x7fff8c204840, 0) = -1 ENOENT 19792 newfstatat(AT_FDCWD, "/B/sh", 0x7fff8c204840, 0) = -1 ENOENT 19792 newfstatat(AT_FDCWD, "/usr/local/bin/sh", 0x7fff8c204840, 0) = -1 ENOENT 19792 newfstatat(AT_FDCWD, "/usr/bin/sh", ...}, 0) = 0 = That's with rpm-4.18.2-1.fc38.x86_64 and glibc-2.37-16.fc38.x86_64. -- ___ 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: Mock Configs v39.3 released - DNF5 used for F40+ builds
On pondělí 18. prosince 2023 10:08:06 CET Pavel Raiskup wrote: > On pátek 1. prosince 2023 15:04:10 CET Pavel Raiskup wrote: > > Hello maintainers! > > > > Let me announce a new release of Mock Core Configs v39.3, aka > > the configuration files for Mock, the chroot build environment manager > > for building RPMs. > > > > The notable change in this release is that we are switching the default > > package_manager from DNF4 to DNF5, according to the F40 change: > > https://fedoraproject.org/wiki/Changes/BuildWithDNF5 > > Full release notes: > >https://rpm-software-management.github.io/mock/Release-Notes-Configs-39.3 > > > > We plan to push this update into Fedora Copr to get some early testing > > next week. Then, depending on the releng team, we might push this into > > Koji soon. The Bodhi updates links are here: > > > > F39 https://bodhi.fedoraproject.org/updates/FEDORA-2023-0a947db1d0 > > F38 https://bodhi.fedoraproject.org/updates/FEDORA-2023-6ef1e12930 > > F37 https://bodhi.fedoraproject.org/updates/FEDORA-2023-cd9c489f40 > > EL9 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-c2c4082053 > > EL8 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-eab5217f46 > > > > Note that we **will not** push these updates into Fedora stable earlier > > than on Monday 2023-12-18 (but very likely we'll wait till the next > > year, depending on the feedback). > > And the push eventually happened, despite that I did not want it to > happen, yet. I probably messed up the Bodhi updates (I thought I > disabled the stable-by-time feature). Sorry, folks. > > The builds often just work. But there are two issues that blocks us > from letting this update go to Fedora Copr at least: > > - the builddep globbing issue > https://github.com/rpm-software-management/dnf5/pull/1088 which is > going to be fixed by a new release (just a new DNF5 release into > Rawhide means the problem is fixed) > > - the weird hangs against Fedora Copr repositories > https://github.com/fedora-copr/copr/issues/3067 - this will probably > not hit you locally, but I am not sure yet. > > In any case, if you need to - stay with DNF4 for a while - either do > > $ cat ~/.config/mock/fedora-rawhide-x86_64.cfg > include("/etc/mock/fedora-rawhide-x86_64.cfg") > config_opts["package_manager"] = "dnf" > > ... or stay with the `mock-core-configs v39.2` a bit longer please. Just a quick update, we already have DNF5 5.1.10 submitted for Fedora Rawhide repos (should be in mirrors tomorrow). This DNF5 release has no known "blocker" issues. I just wanted to give you a quick heads-up that I plan to enable the BuildWithDNF5 change in Fedora Copr as soon as the new Rawhide compose gets distributed to mirrors. Pavel signature.asc Description: This is a digitally signed message part. -- ___ 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