During the Fedora 41 mass rebuild, some of the provides of guile22/guile30 disappeared: $ repoquery -q --repo=rawhide --provides guile22-0:2.2.7-12.fc41.x86_64 bundled(gnulib) guile22 = 2.2.7-12.fc41 guile22(x86-64) = 2.2.7-12.fc41 libguile-2.2.so.1()(64bit) libguile-2.2.so.1(GUILE_2.0)(64bit) $ repoquery -q --repo=koji --provides guile22-0:2.2.7-14.fc41.x86_64 bundled(gnulib) guile22 = 2.2.7-14.fc41 guile22(x86-64) = 2.2.7-14.fc41 $ repoquery -q --repo=rawhide --provides guile30-0:3.0.9-1.fc41.x86_64 bundled(gnulib) guile30 = 3.0.9-1.fc41 guile30(x86-64) = 3.0.9-1.fc41 libguile-3.0.so.1()(64bit) libguile-3.0.so.1(GUILE_2.0)(64bit) $ repoquery -q --repo=koji --provides guile30-0:3.0.9-2.fc41.x86_64 bundled(gnulib) guile30 = 3.0.9-2.fc41 guile30(x86-64) = 3.0.9-2.fc41 aarch64 and ppc64le still have the provides, but not i686, s390x, or x86_64 This breaks many dependent packages: $ repoquery -q --repo=rawhide --whatrequires 'libguile-3.0.so.1()(64bit)' --whatrequires 'libguile-2.2.so.1()(64bit)' aisleriot-1:3.22.21-6.fc40.x86_64 autogen-0:5.18.16-20.fc40.x86_64 denemo-0:2.6.0-11.fc40.x86_64 gnubik-0:2.4.3-18.fc40.x86_64 graphviz-guile-0:12.0.0-1.fc41.x86_64 guile-gnutls-0:3.7.11-1.fc39.x86_64 guile22-devel-0:2.2.7-12.fc41.x86_64 guile30-devel-0:3.0.9-1.fc41.x86_64 maildir-utils-0:1.12.1-2.fc41.x86_64 maildir-utils-guile-0:1.12.1-2.fc41.x86_64 make-1:4.4.1-6.fc40.x86_64 mdk-0:1.3.0-1.fc41.x86_64 trackballs-0:1.3.1-9.fc40.x86_64 weechat-0:4.3.5-1.fc41.x86_64 xbindkeys-0:1.8.7-8.fc40.x86_64 The builds where this worked correctly were built with 4.19.1.1-1.fc40. The builds where this did not work correctly were built with 4.19.92-2.fc41. I manually tried to build with rpm-4.19.91-13.fc41 -- the Provides are still missing. I don't know if this is caused by RPM 4.20, but it's a possibility. Reproducible: Always Steps to Reproduce: Build guile22 or guile30 on Rawhide x86_64. Actual Results: No provides like this are generated: libguile-2.2.so.1()(64bit) libguile-2.2.so.1(GUILE_2.0)(64bit) libguile-3.0.so.1()(64bit) libguile-3.0.so.1(GUILE_2.0)(64bit) Expected Results: The provides are generated.
Installed rpm-4.19.1.1-2.fc41 with redhat-rpm-config-290-1.fc41 to a Rawhide mock chroot and built guile22: ... Provides: bundled(gnulib) guile22 = 2.2.7-14.fc41 guile22(x86-64) = 2.2.7-14.fc41 libguile-2.2.so.1()(64bit) libguile-2.2.so.1(GUILE_2.0)(64bit) ... This indeed sounds like a regression in RPM 4.20.
$ rpmdiff -iT guile22-2.2.7-1* S.5..... LICENSE removed REQUIRES libc.so.6()(64bit) removed REQUIRES libc.so.6(GLIBC_2.10)(64bit) removed REQUIRES libc.so.6(GLIBC_2.11)(64bit) removed REQUIRES libc.so.6(GLIBC_2.14)(64bit) removed REQUIRES libc.so.6(GLIBC_2.15)(64bit) removed REQUIRES libc.so.6(GLIBC_2.17)(64bit) removed REQUIRES libc.so.6(GLIBC_2.2.5)(64bit) removed REQUIRES libc.so.6(GLIBC_2.3)(64bit) removed REQUIRES libc.so.6(GLIBC_2.3.2)(64bit) removed REQUIRES libc.so.6(GLIBC_2.3.4)(64bit) removed REQUIRES libc.so.6(GLIBC_2.32)(64bit) removed REQUIRES libc.so.6(GLIBC_2.33)(64bit) removed REQUIRES libc.so.6(GLIBC_2.34)(64bit) removed REQUIRES libc.so.6(GLIBC_2.38)(64bit) removed REQUIRES libc.so.6(GLIBC_2.4)(64bit) removed REQUIRES libc.so.6(GLIBC_2.6)(64bit) removed REQUIRES libc.so.6(GLIBC_2.7)(64bit) removed REQUIRES libc.so.6(GLIBC_2.9)(64bit) removed REQUIRES libc.so.6(GLIBC_ABI_DT_RELR)(64bit) removed REQUIRES libcrypt.so.2()(64bit) removed REQUIRES libcrypt.so.2(XCRYPT_2.0)(64bit) removed REQUIRES libffi.so.8()(64bit) removed REQUIRES libffi.so.8(LIBFFI_BASE_8.0)(64bit) removed REQUIRES libffi.so.8(LIBFFI_CLOSURE_8.0)(64bit) removed REQUIRES libgc.so.1()(64bit) removed REQUIRES libgmp.so.10()(64bit) removed REQUIRES libguile-2.2.so.1()(64bit) removed REQUIRES libguile-2.2.so.1(GUILE_2.0)(64bit) removed REQUIRES libltdl.so.7()(64bit) removed REQUIRES libm.so.6()(64bit) removed REQUIRES libm.so.6(GLIBC_2.2.5)(64bit) removed REQUIRES libm.so.6(GLIBC_2.29)(64bit) removed REQUIRES libm.so.6(GLIBC_2.35)(64bit) removed REQUIRES libm.so.6(GLIBC_2.38)(64bit) removed REQUIRES libncurses.so.6()(64bit) removed REQUIRES libreadline.so.8()(64bit) removed REQUIRES libtinfo.so.6()(64bit) removed REQUIRES libunistring.so.5()(64bit) removed REQUIRES rtld(GNU_HASH) removed PROVIDES guile22 = 2.2.7-12.fc41 removed PROVIDES guile22(x86-64) = 2.2.7-12.fc41 removed PROVIDES libguile-2.2.so.1()(64bit) removed PROVIDES libguile-2.2.so.1(GUILE_2.0)(64bit) added PROVIDES guile22 = 2.2.7-14.fc41 added PROVIDES guile22(x86-64) = 2.2.7-14.fc41 ..5........ /usr/bin/guile2.2 removed /usr/lib/.build-id/1c removed /usr/lib/.build-id/1c/e61b3e8c644689534139b9156bb0fb063fdf5a added /usr/lib/.build-id/31 added /usr/lib/.build-id/31/9f71f9ca48b67f69b82cb83d90bf572ee3c51d added /usr/lib/.build-id/5c added /usr/lib/.build-id/5c/49431c69be409b4918f6d47bc336d14d6bf5c5 removed /usr/lib/.build-id/77 removed /usr/lib/.build-id/77/4e55eaf5ea0fb3bff5388424d5dc03114efad0 removed /usr/lib/.build-id/7d removed /usr/lib/.build-id/7d/5fdfadd03da047897052cb406e59461f75bb90 added /usr/lib/.build-id/ec added /usr/lib/.build-id/ec/f601ff604073db665734185a1a1b76d7c4722c S.5........ /usr/lib64/guile/2.2/ccache/srfi/srfi-4/gnu.go S.5........ /usr/lib64/guile/2.2/extensions/guile-readline.so.0.0.0 S.5........ /usr/lib64/libguile-2.2.so.1.4.2
When I unpack the rpm and run elfdeps on the so file, the requires get generated correctly with elfdeps from F40. So it doesn't seem that there's any problem with the so file, but really with the generators. Build log diff: -Provides: bundled(gnulib) guile22 = 2.2.7-12.fc41 guile22(x86-64) = 2.2.7-12.fc41 libguile-2.2.so.1()(64bit) libguile-2.2.so.1(GUILE_2.0)(64bit) +Provides: bundled(gnulib) guile22 = 2.2.7-14.fc41 guile22(x86-64) = 2.2.7-14.fc41 Requires(interp): /bin/sh Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 -Requires: /usr/bin/sh libc.so.6()(64bit) libc.so.6(GLIBC_2.10)(64bit) libc.so.6(GLIBC_2.11)(64bit) libc.so.6(GLIBC_2.14)(64bit) libc.so.6(GLIBC_2.15)(64bit) libc.so.6(GLIBC_2.17)(64bit) libc.so.6(GLIBC_2.2.5)(64bit) libc.so.6(GLIBC_2.3)(64bit) libc.so.6(GLIBC_2.3.2)(64bit) libc.so.6(GLIBC_2.3.4)(64bit) libc.so.6(GLIBC_2.32)(64bit) libc.so.6(GLIBC_2.33)(64bit) libc.so.6(GLIBC_2.34)(64bit) libc.so.6(GLIBC_2.38)(64bit) libc.so.6(GLIBC_2.4)(64bit) libc.so.6(GLIBC_2.6)(64bit) libc.so.6(GLIBC_2.7)(64bit) libc.so.6(GLIBC_2.9)(64bit) libc.so.6(GLIBC_ABI_DT_RELR)(64bit) libcrypt.so.2()(64bit) libcrypt.so.2(XCRYPT_2.0)(64bit) libffi.so.8()(64bit) libffi.so.8(LIBFFI_BASE_8.0)(64bit) libffi.so.8(LIBFFI_CLOSURE_8.0)(64bit) libgc.so.1()(64bit) libgmp.so.10()(64bit) libguile-2.2.so.1()(64bit) libguile-2.2.so.1(GUILE_2.0)(64bit) libltdl.so.7()(64bit) libm.so.6()(64bit) libm.so.6(GLIBC_2.2.5)(64bit) libm.so.6(GLIBC_2.29)(64bit) libm.so.6(GLIBC_2.35)(64bit) libm.so.6(GLIBC_2.38)(64bit) libncurses.so.6()(64bit) libreadline.so.8()(64bit) libtinfo.so.6()(64bit) libunistring.so.5()(64bit) rtld(GNU_HASH) -Processing files: guile22-devel-2.2.7-12.fc41.x86_64 -Provides: guile22-devel = 2.2.7-12.fc41 guile22-devel(x86-64) = 2.2.7-12.fc41 pkgconfig(guile-2.2) = 2.2.7 +Requires: /usr/bin/sh +Processing files: guile22-devel-2.2.7-14.fc41.x86_64 +Provides: guile22-devel = 2.2.7-14.fc41 guile22-devel(x86-64) = 2.2.7-14.fc41 pkgconfig(guile-2.2) = 2.2.7 Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 Requires: /usr/bin/pkg-config /usr/bin/sh libguile-2.2.so.1()(64bit) -Processing files: guile22-debugsource-2.2.7-12.fc41.x86_64 -Provides: guile22-debugsource = 2.2.7-12.fc41 guile22-debugsource(x86-64) = 2.2.7-12.fc41 +Processing files: guile22-debugsource-2.2.7-14.fc41.x86_64 +Provides: guile22-debugsource = 2.2.7-14.fc41 guile22-debugsource(x86-64) = 2.2.7-14.fc41 Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 -Processing files: guile22-debuginfo-2.2.7-12.fc41.x86_64 -Provides: debuginfo(build-id) = 1ce61b3e8c644689534139b9156bb0fb063fdf5a debuginfo(build-id) = 774e55eaf5ea0fb3bff5388424d5dc03114efad0 debuginfo(build-id) = 7d5fdfadd03da047897052cb406e59461f75bb90 guile22-debuginfo = 2.2.7-12.fc41 guile22-debuginfo(x86-64) = 2.2.7-12.fc41 libguile-2.2.so.1.4.2-2.2.7-12.fc41.x86_64.debug()(64bit) +Processing files: guile22-debuginfo-2.2.7-14.fc41.x86_64 +Provides: debuginfo(build-id) = 319f71f9ca48b67f69b82cb83d90bf572ee3c51d debuginfo(build-id) = 5c49431c69be409b4918f6d47bc336d14d6bf5c5 debuginfo(build-id) = ecf601ff604073db665734185a1a1b76d7c4722c guile22-debuginfo = 2.2.7-14.fc41 guile22-debuginfo(x86-64) = 2.2.7-14.fc41 libguile-2.2.so.1.4.2-2.2.7-14.fc41.x86_64.debug()(64bit) Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 -Recommends: guile22-debugsource(x86-64) = 2.2.7-12.fc41 -Checking for unpackaged file(s): /usr/lib/rpm/check-files /builddir/build/BUILDROOT/guile22-2.2.7-12.fc41.x86_64 -Wrote: /builddir/build/RPMS/guile22-devel-2.2.7-12.fc41.x86_64.rpm -Wrote: /builddir/build/RPMS/guile22-debuginfo-2.2.7-12.fc41.x86_64.rpm -Wrote: /builddir/build/RPMS/guile22-debugsource-2.2.7-12.fc41.x86_64.rpm -Wrote: /builddir/build/RPMS/guile22-2.2.7-12.fc41.x86_64.rpm +Recommends: guile22-debugsource(x86-64) = 2.2.7-14.fc41 +Checking for unpackaged file(s): /usr/lib/rpm/check-files /builddir/build/BUILD/guile22-2.2.7-build/BUILDROOT +Wrote: /builddir/build/RPMS/guile22-devel-2.2.7-14.fc41.x86_64.rpm +Wrote: /builddir/build/RPMS/guile22-debuginfo-2.2.7-14.fc41.x86_64.rpm +Wrote: /builddir/build/RPMS/guile22-debugsource-2.2.7-14.fc41.x86_64.rpm +Wrote: /builddir/build/RPMS/guile22-2.2.7-14.fc41.x86_64.rpm
Running elfdeps from rpm-4.19.92-2.fc41.x86_64 directly on the installed file also works: $ rpm -qf /usr/lib/rpm/elfdeps rpm-build-4.19.92-2.fc41.x86_64 $ rpm -qf /usr/lib64/libguile-2.2.so.1 guile22-2.2.7-14.fc41.x86_64 $ /usr/lib/rpm/elfdeps --provides /usr/lib64/libguile-2.2.so.1 libguile-2.2.so.1(GUILE_2.0)(64bit) libguile-2.2.so.1()(64bit)
elfdeps switched to multifile protocol in the new rpm. But it still seems to work fine: $ /usr/lib/rpm/elfdeps --multifile --provides /builddir/build/BUILD/guile22-2.2.7-build/guile-2.2.7/libguile/.libs/libguile-2.2.so ;/builddir/build/BUILD/guile22-2.2.7-build/guile-2.2.7/libguile/.libs/libguile-2.2.so libguile-2.2.so.1(GUILE_2.0)(64bit) libguile-2.2.so.1()(64bit) This is in mock, on the build dir, with rpm-4.19.92-5.fc41.x86_64. But the rpm is still generated without the expected R/P. With --rpmbuild-opts=--rpmfcdebug: 352 /builddir/build/BUILD/guile22-2.2.7-build/BUILDROOT/usr/lib64/libguile-2.2.so.1 [none] 353 /builddir/build/BUILD/guile22-2.2.7-build/BUILDROOT/usr/lib64/libguile-2.2.so.1.4.2 0x2 [elf,glibc] So it seems that the magic matches. It really looks like a problem in rpm itself.
Looks like we encounter an integer division by zero: 35 pread64(3, "\3`\0247\6\0\0\3\2`\0247\230\0\0\0\0`\0247\0\0\1\0\1`\0247\230\1\0\0\f\0\0\0\354\1\0\0\4`\0247H\5\0\0\0\0\0\0\0\0\0\0", 56, 1376) = 56 35 --- SIGFPE {si_signo=SIGFPE, si_code=FPE_INTDIV, si_addr=0x5663338d} --- 34 futex(0x570dae24, FUTEX_WAIT_PRIVATE, 8, NULL <unfinished ...> 33 futex(0x570dae24, FUTEX_WAIT_PRIVATE, 8, NULL <unfinished ...> 32 futex(0x570dae24, FUTEX_WAIT_PRIVATE, 8, NULL <unfinished ...> 28 <... pselect6 resumed>) = 1 (in [5]) 35 +++ killed by SIGFPE (core dumped) +++ Unfortunately, RPM seems to ignore this error. The crash reproduces with: /usr/lib/rpm/elfdeps /builddir/build/BUILD/guile30-3.0.9-build/BUILDROOT/usr/lib/guile/3.0/ccache/ice-9/eval.go GDB shows: (gdb) bt #0 0x5655738d in __udivdi3 () #1 0x56556dcd in processDynamic (scn=<optimized out>, shdr=<optimized out>, ei=<optimized out>) at /usr/src/debug/rpm-4.19.92-5.fc41.i386/tools/elfdeps.c:200 #2 processSections (ei=<optimized out>) at /usr/src/debug/rpm-4.19.92-5.fc41.i386/tools/elfdeps.c:252 #3 processFile ( fn=0x5655b390 "/builddir/build/BUILD/guile30-3.0.9-build/BUILDROOT/usr/lib/guile/3.0/ccache/ice-9/eval.go", dtype=0) at /usr/src/debug/rpm-4.19.92-5.fc41.i386/tools/elfdeps.c:306 #4 0x565565eb in main (argc=2, argv=0xffffd454) at /usr/src/debug/rpm-4.19.92-5.fc41.i386/tools/elfdeps.c:389 (gdb) l 195 196 static void processDynamic(Elf_Scn *scn, GElf_Shdr *shdr, elfInfo *ei) 197 { 198 Elf_Data *data = NULL; 199 while ((data = elf_getdata(scn, data)) != NULL) { 200 for (int i = 0; i < (shdr->sh_size / shdr->sh_entsize); i++) { 201 const char *s = NULL; 202 GElf_Dyn dyn_mem, *dyn; 203 204 dyn = gelf_getdyn (data, i, &dyn_mem); And indeed, readelf -SW shows that .dynamic has entry size zero: [ 6] .dynamic DYNAMIC 0000bc08 00bc08 000038 00 A 0 0 8 It should have size 8 instead. This looks like something specific to the Guile ELF writer. We have a couple of RPM bugs here, too: elfdeps shouldn't crash (and maybe flag this as an error explicitly). RPM should detect that dependency generators fail. So not reassigning.
> Unfortunately, RPM seems to ignore this error. That is https://github.com/rpm-software-management/rpm/issues/1183
Thanks guys for investigating! Indeed, RPM (the elfdeps binary) plays a part here since it, ehm, really shouldn't make any assumption about the entry size always being non-zero. In fact, according to the man elf(5) man page: sh_entsize Some sections hold a table of fixed-sized entries, such as a symbol table. For such a section, this member gives the size in bytes for each entry. This member contains zero if the section does not hold a table of fixed-size entries. The fix seems to be simple, we just skip over such sections altogether... except that I'm not sure if that's really the right thing to do? Can anybody who has a clue about the ELF format chime in (Florian)? Sure, we should improve (add) error reporting here (#1183, thanks for digging that up) but that's not something that's doable in a short time frame, we probably need a hotfix in Fedora first.
FWIW, doing just that (skipping over sections with sh_entsize of 0) fixes the issue for me here, i.e. the missing R/P are back in the resulting package.
(In reply to Michal Domonkos from comment #8) > Thanks guys for investigating! Indeed, RPM (the elfdeps binary) plays a > part here since it, ehm, really shouldn't make any assumption about the > entry size always being non-zero. > > In fact, according to the man elf(5) man page: > > sh_entsize > Some sections hold a table of fixed-sized entries, such as > a symbol table. For such a section, this > member gives the size in bytes for each entry. This member > contains zero if the section does not hold > a table of fixed-size entries. > > The fix seems to be simple, we just skip over such sections altogether... > except that I'm not sure if that's really the right thing to do? Can > anybody who has a clue about the ELF format chime in (Florian)? If you don't trust the sh_entsize given in a file you could ask libelf what it should be for the given type. /* Return size of array of COUNT elements of the type denoted by TYPE in the external representation. The binary class is taken from ELF. The result is based on version VERSION of the ELF standard. */ extern size_t gelf_fsize (Elf *__elf, Elf_Type __type, size_t __count, unsigned int __version); So in this case you could do something like: size_t expected_entsize = gelf_fsize (elf, ELF_T_DYN, 1, EV_CURRENT); for (int i = 0; i < (shdr->sh_size / expected_entsize); i++) { ... } And/or warn/error out if shdr->sh_entsize != expected_entsize. But this is really a bug in whatever generated the guile SHT_DYNAMIC section.
(In reply to Mark Wielaard from comment #10) > (In reply to Michal Domonkos from comment #8) > > Thanks guys for investigating! Indeed, RPM (the elfdeps binary) plays a > > part here since it, ehm, really shouldn't make any assumption about the > > entry size always being non-zero. > > > > In fact, according to the man elf(5) man page: > > > > sh_entsize > > Some sections hold a table of fixed-sized entries, such as > > a symbol table. For such a section, this > > member gives the size in bytes for each entry. This member > > contains zero if the section does not hold > > a table of fixed-size entries. > > > > The fix seems to be simple, we just skip over such sections altogether... > > except that I'm not sure if that's really the right thing to do? Can > > anybody who has a clue about the ELF format chime in (Florian)? > > If you don't trust the sh_entsize given in a file you could ask libelf what > it should be for the given type. Is there a valid reason for sh_entsize being 0 while there actually being a table? Otherwise, I suppose that if you don't trust that value, you shouldn't trust the entire elf file and treat it as malformed (?) > /* Return size of array of COUNT elements of the type denoted by TYPE > in the external representation. The binary class is taken from ELF. > The result is based on version VERSION of the ELF standard. */ > extern size_t gelf_fsize (Elf *__elf, Elf_Type __type, size_t __count, > unsigned int __version); > > So in this case you could do something like: > > size_t expected_entsize = gelf_fsize (elf, ELF_T_DYN, 1, EV_CURRENT); > for (int i = 0; i < (shdr->sh_size / expected_entsize); i++) { > ... > } > > And/or warn/error out if shdr->sh_entsize != expected_entsize. Yep, this would be one step above just checking if it isn't zero, but... I ended up just adding a zero check and submitted an update to Rawhide: https://bodhi.fedoraproject.org/updates/FEDORA-2024-af6f84b62a @mhroncok, can someone please rebuild libguile once this hits the compose?
I will submit scratch builds and if they have the provides, I will build them for real.
Good, thanks. I probably should've kept the bug opened until we confirm that the provides are back, but nah...
FWIW, this potential division by zero in rpm was 22 years old. So for us to run into this just now, it seems like a fairly new regression in whatever creates the buggy section in guile.
(In reply to Panu Matilainen from comment #14) > FWIW, this potential division by zero in rpm was 22 years old. So for us to > run into this just now, it seems like a fairly new regression in whatever > creates the buggy section in guile. I think it's related to the RPM multifile protocol (if I correctly guessed what its name implies). In the past, the SIGFPE crash would have dropped dependencies for just one file, which was fine because it wasn't expected to have any anyway.
FEDORA-2024-5b23aca541 (guile30-3.0.9-3.fc41) has been submitted as an update to Fedora 41. https://bodhi.fedoraproject.org/updates/FEDORA-2024-5b23aca541
FEDORA-2024-5b23aca541 (guile30-3.0.9-3.fc41) has been pushed to the Fedora 41 stable repository. If problem still persists, please make note of it in this bug report.
> I think it's related to the RPM multifile protocol (if I correctly guessed what its name implies). In the past, the SIGFPE crash would have dropped dependencies for just one file, which was fine because it wasn't expected to have any anyway. Oh. I keep forgetting about the multifile protocol. So in that case probably yeah - it may have been crashing for who knows how long, but nobody noticed.
FEDORA-2024-a9a60cbd1f (guile22-2.2.7-15.fc41) has been submitted as an update to Fedora 41. https://bodhi.fedoraproject.org/updates/FEDORA-2024-a9a60cbd1f
FEDORA-2024-a9a60cbd1f (guile22-2.2.7-15.fc41) has been pushed to the Fedora 41 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2025-7cfef27a27 (guile30-3.0.9-1.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2025-7cfef27a27
FEDORA-2025-7cfef27a27 (guile30-3.0.9-1.fc43) has been pushed to the Fedora 43 stable repository. If problem still persists, please make note of it in this bug report.