[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-ffb6e04eb7 drupal7-7.98-1.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-c283911e27 ckeditor-4.22.1-1.el7 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-97dd2d11b6 xrdp-0.9.23.1-1.el7 1 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-3ee7f851c6 composer-1.10.27-1.el7 1 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-a99c56df6a libptytty-2.0-4.el7 rxvt-unicode-9.31-1.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing inxi-3.3.30-1.el7 iotop-c-1.24-1.el7 Details about builds: inxi-3.3.30-1.el7 (FEDORA-EPEL-2023-c59bbaee57) A full featured system information script Update Information: Update to 3.3.30. ChangeLog: * Sun Oct 1 2023 Vasiliy N. Glazov - 3.3.30-1 - Update to 3.3.30 iotop-c-1.24-1.el7 (FEDORA-EPEL-2023-4200bf1025) Simple top-like I/O monitor (implemented in C) Update Information: Update to latest ver 1.24 ChangeLog: * Sat Sep 30 2023 Boian Bonev - 1.24-1 - Update to latest ver 1.24 - Remove patch addressed upstream * Thu Jul 20 2023 Fedora Release Engineering - 1.23-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild ___ 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] Fedora EPEL 8 updates-testing report
The following Fedora EPEL 8 Security updates need testing: Age URL 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-27c714a6a4 xrdp-0.9.23.1-1.el8 The following builds have been pushed to Fedora EPEL 8 updates-testing inxi-3.3.30-1.el8 iotop-c-1.24-1.el8 Details about builds: inxi-3.3.30-1.el8 (FEDORA-EPEL-2023-e4c244fa39) A full featured system information script Update Information: Update to 3.3.30. ChangeLog: * Sun Oct 1 2023 Vasiliy N. Glazov - 3.3.30-1 - Update to 3.3.30 iotop-c-1.24-1.el8 (FEDORA-EPEL-2023-0321338bb3) Simple top-like I/O monitor (implemented in C) Update Information: Update to latest ver 1.24 ChangeLog: * Sat Sep 30 2023 Boian Bonev - 1.24-1 - Update to latest ver 1.24 * Thu Jul 20 2023 Fedora Release Engineering - 1.23-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild ___ 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] Fedora EPEL 9 updates-testing report
The following Fedora EPEL 9 Security updates need testing: Age URL 3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-93ac846983 xrdp-0.9.23.1-1.el9 1 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-9791f0b66c composer-2.6.4-1.el9 The following builds have been pushed to Fedora EPEL 9 updates-testing fluidsynth-2.3.4-1.el9 inxi-3.3.30-1.el9 iotop-c-1.24-1.el9 python-pypresence-4.3.0-1.el9 rust-aes-gcm-0.10.3-1.el9 rust-bindgen-cli-0.68.1-2.el9 rust-packaging-25.2-1.el9 Details about builds: fluidsynth-2.3.4-1.el9 (FEDORA-EPEL-2023-b854d633bc) Real-time software synthesizer Update Information: Update to 2.3.4 ChangeLog: * Wed Sep 27 2023 Christoph Karl - 2.3.4-1 - Update to 2.3.4 * Wed Jul 19 2023 Fedora Release Engineering - 2.3.2-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild * Wed May 31 2023 Christoph Karl - 2.3.2-3 - Re-add dependency fluidsynth-libs inxi-3.3.30-1.el9 (FEDORA-EPEL-2023-883ab504b3) A full featured system information script Update Information: Update to 3.3.30. ChangeLog: * Sun Oct 1 2023 Vasiliy N. Glazov - 3.3.30-1 - Update to 3.3.30 iotop-c-1.24-1.el9 (FEDORA-EPEL-2023-d7733f69ac) Simple top-like I/O monitor (implemented in C) Update Information: Update to latest ver 1.24 ChangeLog: * Sat Sep 30 2023 Boian Bonev - 1.24-1 - Update to latest ver 1.24 * Thu Jul 20 2023 Fedora Release Engineering - 1.23-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild python-pypresence-4.3.0-1.el9 (FEDORA-EPEL-2023-4351fcc57f) A Discord Rich Presence Client in Python Update Information: Update to 4.3.0 ChangeLog: * Sun Oct 1 2023 Steve Cossette - 4.3.0-1 - Update to 4.3.0 rust-aes-gcm-0.10.3-1.el9 (FEDORA-EPEL-2023-1b27cb1ee9) Pure Rust implementation of the AES-GCM AEAD Cipher Update Information: Update to version 0.10.3. Addresses CVE-2023-42811. https://cve.mitre.org/cgi- bin/cvename.cgi?name=CVE-2023-42811 ChangeLog: * Sun Sep 24 2023 Fabio Valentini - 0.10.3-1 - Update to version 0.10.3; Fixes RHBZ#2240136 * Fri Jul 21 2023 Fedora Release Engineering - 0.10.2-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild References: [ 1 ] Bug #2240270 - CVE-2023-42811 rust-aes-gcm: aes-gcm: Plaintext exposed in decrypt_in_place_detached even on tag verification failure [epel-all] https://bugzilla.redhat.com/show_bug.cgi?id=2240270 rust-bindgen-cli-0.68.1-2.el9 (FEDORA-EPEL-2023-8f24d6e8d2) Automatically generates Rust FFI bindings to C and C++ libraries Update Information: Load libclang.so at runtime to prevent situations where versions of clang/LLVM and the linked libclang.so don't match. ChangeLog: * Sun Oct 1 2023 Fabio Valentini - 0.68.1-2 - Build with support for dlopening libclang.so at runtime References: [ 1 ] Bug #2240402 - Compilation fails when compiling Linux using LLVM with rust support enabled
Fedora 39 compose report: 20230930.n.0 changes
OLD: Fedora-39-20230929.n.0 NEW: Fedora-39-20230930.n.0 = SUMMARY = Added images:2 Dropped images: 1 Added packages: 5 Dropped packages:0 Upgraded packages: 38 Downgraded packages: 0 Size of added packages: 2.42 MiB Size of dropped packages:0 B Size of upgraded packages: 485.49 MiB Size of downgraded packages: 0 B Size change of upgraded packages: 9.89 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Silverblue dvd-ostree x86_64 Path: Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-39-20230930.n.0.iso Image: KDE live aarch64 Path: Spins/aarch64/iso/Fedora-KDE-Live-aarch64-39-20230930.n.0.iso = DROPPED IMAGES = Image: LXQt live aarch64 Path: Spins/aarch64/iso/Fedora-LXQt-Live-aarch64-39-20230929.n.0.iso = ADDED PACKAGES = Package: python-pygments-git-1.6.0-4.fc39 Summary: Pygments lexers for Git output and files RPMs:python3-pygments-git Size:16.34 KiB Package: rust-enumn-0.1.12-1.fc39 Summary: Convert number to enum RPMs:rust-enumn+default-devel rust-enumn-devel Size:22.88 KiB Package: rust-four-cc-0.3.0-2.fc39 Summary: Newtype wrapper for representing four-character-code values RPMs:rust-four-cc+default-devel rust-four-cc+nightly-devel rust-four-cc+serde-devel rust-four-cc+std-devel rust-four-cc-devel Size:45.11 KiB Package: rust-libheif-rs-0.21.0-2.fc39 Summary: Safe wrapper around the libheif-sys crate for parsing heif/heic files RPMs:rust-libheif-rs+default-devel rust-libheif-rs-devel Size:37.53 KiB Package: rust-libheif-sys-1.16.2-1.fc39 Summary: Libheif bindings RPMs:rust-libheif-sys+default-devel rust-libheif-sys+use-bindgen-devel rust-libheif-sys-devel Size:2.30 MiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: arpack-3.9.0-1.fc39 Old package: arpack-3.8.0-7.fc39 Summary: Fortran 77 subroutines for solving large scale eigenvalue problems RPMs: arpack arpack-devel arpack-doc arpack-static Size: 2.06 MiB Size change: 120.49 KiB Changelog: * Tue Sep 26 2023 Dominik Mierzejewski - 3.9.0-1 - update to 3.9.0 (resolves rhbz#2169134) - drop obsolete patch - cmake files are no longer installed when building with autotools - enable eigen3 tests (64-bit only, not enough memory on 32-bit) Package: chatterino2-2.4.5-5.fc39 Old package: chatterino2-2.4.5-4.fc39 Summary: Chat client for https://twitch.tv RPMs: chatterino2 Size: 12.85 MiB Size change: -2.38 KiB Changelog: * Wed Sep 20 2023 Christian Birk - 2.4.5-5 - migrate to system provided websocketpp Package: cppcheck-2.12.1-1.fc39 Old package: cppcheck-2.12.0-2.fc39 Summary: Tool for static C/C++ code analysis RPMs: cppcheck cppcheck-gui cppcheck-htmlreport Size: 18.53 MiB Size change: -1.24 KiB Changelog: * Wed Sep 20 2023 Wolfgang St??ggl - 2.12.1-1 - Update to 2.12.1 Package: dleyna-0.8.3-1.fc39 Old package: dleyna-0.8.2-3.fc39 Summary: Services and D-Bus APIs for UPnP access RPMs: dleyna dleyna-connector-dbus dleyna-devel dleyna-renderer dleyna-server Size: 839.29 KiB Size change: 2.01 KiB Changelog: * Wed Sep 20 2023 David King - 0.8.3-1 - Update to 0.8.3 Package: erofs-utils-1.7-1.fc39 Old package: erofs-utils-1.6-3.fc39 Summary: Utilities for working with EROFS RPMs: erofs-fuse erofs-utils Size: 763.93 KiB Size change: 178.73 KiB Changelog: * Thu Sep 21 2023 David Michael - 1.7-1 - Update to the 1.7 release. Package: fedora-obsolete-packages-39-16 Old package: fedora-obsolete-packages-39-14 Summary: A package to obsolete retired packages RPMs: fedora-obsolete-packages Size: 23.64 KiB Size change: 1.00 KiB Changelog: * Wed Sep 20 2023 Miro Hron??ok - 39-15 - Update the list of obsoleted Python 3.11 packages * Thu Sep 21 2023 Miro Hron??ok - 39-16 - Don't obsolete pytoolconfig Package: giflib-5.2.1-17.fc39 Old package: giflib-5.2.1-16.fc39 Summary: A library and utilities for processing GIFs RPMs: giflib giflib-devel giflib-utils mingw32-giflib mingw32-giflib-tools mingw64-giflib mingw64-giflib-tools Size: 2.00 MiB Size change: -972 B Changelog: * Thu Sep 14 2023 Sandro Mani - 5.2.1-17 - Add patch for CVE-2023-39742 Package: git-extras-7.0.0-1.fc39 Old package: git-extras-6.5.0-3.fc39 Summary: Little git extras RPMs: git-extras Size: 257.44 KiB Size change: 1.93 KiB Changelog: * Mon Sep 18 2023 Vasiliy N. Glazov - 7.0.0-1 - Update to 7.0.0 Package: glib2-2.78.0-3.fc39 Old package: glib2-2.78.0-2.fc39 Summary: A library of handy utility functions RPMs: glib2 glib2-devel glib2-doc glib2-static glib2-tests Size: 37.27 MiB Size change: 1.12 MiB Changelog: * Wed Sep 27 2023 Zephyr Lykos - 2.78.0-3 - gthreadedresolver: Fix race between source callbacks and finalize
Re: mame validation time takes forever on rawhide/aarch64
Am 01.10.23 um 18:32 schrieb Julian Sikorski: Am 01.10.23 um 18:14 schrieb Dan Horák: On Sun, 1 Oct 2023 14:21:23 +0200 Julian Sikorski wrote: Am 01.10.23 um 10:17 schrieb Julian Sikorski: Am 01.10.23 um 09:37 schrieb Dan Horák: On Sun, 1 Oct 2023 09:32:10 +0200 Julian Sikorski wrote: Am 30.09.23 um 09:09 schrieb Julian Sikorski: Hello, mame package uses mame -validate as %check step. It has recently started to cause problems on rawhide/aarch64: - I had to cancel 0.258 build after 16 hours [1] - 0.259 build is stuck since ca. 1600 UTC yesterday [2] Other branches built fine for aarch64, and so did other arches for rawhide. Additionally, there are no rawhide koschei builds since August making it harder to find the potential culprit. How can I investigate further? I might need to disable %check if the reason cannot be found. Best regards, Julian [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=106453404 [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=106887762 The build is still stuck. Do we have aarch64 machines accessible to maintainers which could be used to see what the problem is? The last we do have, please see https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers Dan Thanks! Unfortunately it appears that aarch64 is only available as f38 and f37 which both finish the validation successfully. Rawhide is only available as x86_64 which does not exhibit the issue either. I will see if doing a rawhide mock build on f38 host is sufficient. This is what koji seems to be doing anyway. Best regards, Julian I managed to reproduce this on the aarch64 machine in mock. Validation seems to get stuck right away at: (gdb) bt #0 0xb5bddb08 in ___ZN4bgfx12VertexLayoutC1Ev_bti_veneer () hmm, couldn't it be related to the PAC & BTI feature [1]? I believe someone mentioned some issues with it, probably here on the devel list and the workaround was to disable the related compiler flags ... The feature dates back to F33 whereas the breakage started after F39 was branched. I discussed this with upstream [1] and the suspicion is that the linker is misbehaving. I am attempting a build using lld to confirm. Best regards, Julian [1] https://github.com/mamedev/mame/issues/11587 Build using -fuse-ld=lld has succeeded: https://koji.fedoraproject.org/koji/taskinfo?taskID=106961583 I have reported the problem to binutils upstream: https://sourceware.org/bugzilla/show_bug.cgi?id=30930 Thanks for the help tracking this down. Best regards, Julian #1 0xf5870b2c in __libc_start_main_impl () from /lib64/libc.so.6 #2 0xaef01570 in _start () One question: the binary in /builddir/build/BUILD still has symbols in, correct? yes, the files under /builddir/build/BUILDROOT/... are split into stripped binaries and debuginfos Best regards, Julian [1] https://fedoraproject.org/wiki/Changes/Aarch64_PointerAuthentication Dan ___ 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: mame validation time takes forever on rawhide/aarch64
Am 01.10.23 um 18:14 schrieb Dan Horák: On Sun, 1 Oct 2023 14:21:23 +0200 Julian Sikorski wrote: Am 01.10.23 um 10:17 schrieb Julian Sikorski: Am 01.10.23 um 09:37 schrieb Dan Horák: On Sun, 1 Oct 2023 09:32:10 +0200 Julian Sikorski wrote: Am 30.09.23 um 09:09 schrieb Julian Sikorski: Hello, mame package uses mame -validate as %check step. It has recently started to cause problems on rawhide/aarch64: - I had to cancel 0.258 build after 16 hours [1] - 0.259 build is stuck since ca. 1600 UTC yesterday [2] Other branches built fine for aarch64, and so did other arches for rawhide. Additionally, there are no rawhide koschei builds since August making it harder to find the potential culprit. How can I investigate further? I might need to disable %check if the reason cannot be found. Best regards, Julian [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=106453404 [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=106887762 The build is still stuck. Do we have aarch64 machines accessible to maintainers which could be used to see what the problem is? The last we do have, please see https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers Dan Thanks! Unfortunately it appears that aarch64 is only available as f38 and f37 which both finish the validation successfully. Rawhide is only available as x86_64 which does not exhibit the issue either. I will see if doing a rawhide mock build on f38 host is sufficient. This is what koji seems to be doing anyway. Best regards, Julian I managed to reproduce this on the aarch64 machine in mock. Validation seems to get stuck right away at: (gdb) bt #0 0xb5bddb08 in ___ZN4bgfx12VertexLayoutC1Ev_bti_veneer () hmm, couldn't it be related to the PAC & BTI feature [1]? I believe someone mentioned some issues with it, probably here on the devel list and the workaround was to disable the related compiler flags ... The feature dates back to F33 whereas the breakage started after F39 was branched. I discussed this with upstream [1] and the suspicion is that the linker is misbehaving. I am attempting a build using lld to confirm. Best regards, Julian [1] https://github.com/mamedev/mame/issues/11587 #1 0xf5870b2c in __libc_start_main_impl () from /lib64/libc.so.6 #2 0xaef01570 in _start () One question: the binary in /builddir/build/BUILD still has symbols in, correct? yes, the files under /builddir/build/BUILDROOT/... are split into stripped binaries and debuginfos Best regards, Julian [1] https://fedoraproject.org/wiki/Changes/Aarch64_PointerAuthentication Dan ___ 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: mame validation time takes forever on rawhide/aarch64
Am 01.10.23 um 18:08 schrieb John Reiser:
mame package uses mame -validate as %check step. It has recently
started
to cause problems on rawhide/aarch64:
- 0.259 build is stuck since ca. 1600 UTC yesterday [2]
I managed to reproduce this on the aarch64 machine in mock. Validation
seems to get stuck right away at:
(gdb) bt
#0 0xb5bddb08 in ___ZN4bgfx12VertexLayoutC1Ev_bti_veneer ()
#1 0xf5870b2c in __libc_start_main_impl () from /lib64/libc.so.6
#2 0xaef01570 in _start ()
One question: the binary in /builddir/build/BUILD still has symbols
in, correct?
The backtrace above does not contain a filename or line number for frame
#0,
so it looks like the app (or a library that it uses) was compiled
without "-g",
or the debug information has been stripped or separated after building.
Of course the app does contain some global symbol information
that is required for run-time dynamic linking ("readelf --symbols
--use-dynamic ./my_app"). It is remarkable that the symbol
for frame #0 '___ZN4bgfx12VertexLayoutC1Ev_bti_veneer'
begins with three underscores instead of only 1.
I have to build with -g1 as building with normal -g2 causes the
compilation to exhaust all available memory.
Best regards,
Julian
___
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: mame validation time takes forever on rawhide/aarch64
On Sun, 1 Oct 2023 14:21:23 +0200 Julian Sikorski wrote: > Am 01.10.23 um 10:17 schrieb Julian Sikorski: > > Am 01.10.23 um 09:37 schrieb Dan Horák: > >> On Sun, 1 Oct 2023 09:32:10 +0200 > >> Julian Sikorski wrote: > >> > >>> Am 30.09.23 um 09:09 schrieb Julian Sikorski: > Hello, > > mame package uses mame -validate as %check step. It has recently > started > to cause problems on rawhide/aarch64: > - I had to cancel 0.258 build after 16 hours [1] > - 0.259 build is stuck since ca. 1600 UTC yesterday [2] > Other branches built fine for aarch64, and so did other arches for > rawhide. Additionally, there are no rawhide koschei builds since August > making it harder to find the potential culprit. > How can I investigate further? I might need to disable %check if the > reason cannot be found. > > Best regards, > Julian > > [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=106453404 > [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=106887762 > >>> > >>> The build is still stuck. Do we have aarch64 machines accessible to > >>> maintainers which could be used to see what the problem is? The last > >> > >> we do have, please see > >> https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers > >> > >> > >> Dan > > > > Thanks! Unfortunately it appears that aarch64 is only available as f38 > > and f37 which both finish the validation successfully. Rawhide is only > > available as x86_64 which does not exhibit the issue either. > > I will see if doing a rawhide mock build on f38 host is sufficient. This > > is what koji seems to be doing anyway. > > > > Best regards, > > Julian > > I managed to reproduce this on the aarch64 machine in mock. Validation > seems to get stuck right away at: > > (gdb) bt > #0 0xb5bddb08 in ___ZN4bgfx12VertexLayoutC1Ev_bti_veneer () hmm, couldn't it be related to the PAC & BTI feature [1]? I believe someone mentioned some issues with it, probably here on the devel list and the workaround was to disable the related compiler flags ... > #1 0xf5870b2c in __libc_start_main_impl () from /lib64/libc.so.6 > #2 0xaef01570 in _start () > > One question: the binary in /builddir/build/BUILD still has symbols in, > correct? yes, the files under /builddir/build/BUILDROOT/... are split into stripped binaries and debuginfos > Best regards, > Julian [1] https://fedoraproject.org/wiki/Changes/Aarch64_PointerAuthentication Dan ___ 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: mame validation time takes forever on rawhide/aarch64
mame package uses mame -validate as %check step. It has recently started
to cause problems on rawhide/aarch64:
- 0.259 build is stuck since ca. 1600 UTC yesterday [2]
I managed to reproduce this on the aarch64 machine in mock. Validation seems to
get stuck right away at:
(gdb) bt
#0 0xb5bddb08 in ___ZN4bgfx12VertexLayoutC1Ev_bti_veneer ()
#1 0xf5870b2c in __libc_start_main_impl () from /lib64/libc.so.6
#2 0xaef01570 in _start ()
One question: the binary in /builddir/build/BUILD still has symbols in, correct?
The backtrace above does not contain a filename or line number for frame #0,
so it looks like the app (or a library that it uses) was compiled without "-g",
or the debug information has been stripped or separated after building.
Of course the app does contain some global symbol information
that is required for run-time dynamic linking ("readelf --symbols
--use-dynamic ./my_app"). It is remarkable that the symbol
for frame #0 '___ZN4bgfx12VertexLayoutC1Ev_bti_veneer'
begins with three underscores instead of only 1.
___
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: mame validation time takes forever on rawhide/aarch64
Am 01.10.23 um 10:17 schrieb Julian Sikorski: Am 01.10.23 um 09:37 schrieb Dan Horák: On Sun, 1 Oct 2023 09:32:10 +0200 Julian Sikorski wrote: Am 30.09.23 um 09:09 schrieb Julian Sikorski: Hello, mame package uses mame -validate as %check step. It has recently started to cause problems on rawhide/aarch64: - I had to cancel 0.258 build after 16 hours [1] - 0.259 build is stuck since ca. 1600 UTC yesterday [2] Other branches built fine for aarch64, and so did other arches for rawhide. Additionally, there are no rawhide koschei builds since August making it harder to find the potential culprit. How can I investigate further? I might need to disable %check if the reason cannot be found. Best regards, Julian [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=106453404 [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=106887762 The build is still stuck. Do we have aarch64 machines accessible to maintainers which could be used to see what the problem is? The last we do have, please see https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers Dan Thanks! Unfortunately it appears that aarch64 is only available as f38 and f37 which both finish the validation successfully. Rawhide is only available as x86_64 which does not exhibit the issue either. I will see if doing a rawhide mock build on f38 host is sufficient. This is what koji seems to be doing anyway. Best regards, Julian I managed to reproduce this on the aarch64 machine in mock. Validation seems to get stuck right away at: (gdb) bt #0 0xb5bddb08 in ___ZN4bgfx12VertexLayoutC1Ev_bti_veneer () #1 0xf5870b2c in __libc_start_main_impl () from /lib64/libc.so.6 #2 0xaef01570 in _start () One question: the binary in /builddir/build/BUILD still has symbols in, correct? Best regards, Julian ___ 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: mame validation time takes forever on rawhide/aarch64
Am 01.10.23 um 09:37 schrieb Dan Horák: On Sun, 1 Oct 2023 09:32:10 +0200 Julian Sikorski wrote: Am 30.09.23 um 09:09 schrieb Julian Sikorski: Hello, mame package uses mame -validate as %check step. It has recently started to cause problems on rawhide/aarch64: - I had to cancel 0.258 build after 16 hours [1] - 0.259 build is stuck since ca. 1600 UTC yesterday [2] Other branches built fine for aarch64, and so did other arches for rawhide. Additionally, there are no rawhide koschei builds since August making it harder to find the potential culprit. How can I investigate further? I might need to disable %check if the reason cannot be found. Best regards, Julian [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=106453404 [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=106887762 The build is still stuck. Do we have aarch64 machines accessible to maintainers which could be used to see what the problem is? The last we do have, please see https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers Dan Thanks! Unfortunately it appears that aarch64 is only available as f38 and f37 which both finish the validation successfully. Rawhide is only available as x86_64 which does not exhibit the issue either. I will see if doing a rawhide mock build on f38 host is sufficient. This is what koji seems to be doing anyway. Best regards, Julian ___ 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: mame validation time takes forever on rawhide/aarch64
On Sun, 1 Oct 2023 09:32:10 +0200 Julian Sikorski wrote: > Am 30.09.23 um 09:09 schrieb Julian Sikorski: > > Hello, > > > > mame package uses mame -validate as %check step. It has recently started > > to cause problems on rawhide/aarch64: > > - I had to cancel 0.258 build after 16 hours [1] > > - 0.259 build is stuck since ca. 1600 UTC yesterday [2] > > Other branches built fine for aarch64, and so did other arches for > > rawhide. Additionally, there are no rawhide koschei builds since August > > making it harder to find the potential culprit. > > How can I investigate further? I might need to disable %check if the > > reason cannot be found. > > > > Best regards, > > Julian > > > > [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=106453404 > > [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=106887762 > > The build is still stuck. Do we have aarch64 machines accessible to > maintainers which could be used to see what the problem is? The last we do have, please see https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers Dan > lines in the build log are (and have been for a while): > > Executing(%check): /bin/sh -e /var/tmp/rpm-tmp.cLY2Y2 > + umask 022 > + cd /builddir/build/BUILD > + cd mame-mame0259 > + ./mame -validate > > Best regards, > Julian > ___ > 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: mame validation time takes forever on rawhide/aarch64
Am 30.09.23 um 09:09 schrieb Julian Sikorski: Hello, mame package uses mame -validate as %check step. It has recently started to cause problems on rawhide/aarch64: - I had to cancel 0.258 build after 16 hours [1] - 0.259 build is stuck since ca. 1600 UTC yesterday [2] Other branches built fine for aarch64, and so did other arches for rawhide. Additionally, there are no rawhide koschei builds since August making it harder to find the potential culprit. How can I investigate further? I might need to disable %check if the reason cannot be found. Best regards, Julian [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=106453404 [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=106887762 The build is still stuck. Do we have aarch64 machines accessible to maintainers which could be used to see what the problem is? The last lines in the build log are (and have been for a while): Executing(%check): /bin/sh -e /var/tmp/rpm-tmp.cLY2Y2 + umask 022 + cd /builddir/build/BUILD + cd mame-mame0259 + ./mame -validate Best regards, Julian ___ 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
