xorriso in Rawhide fails to work because of a missing symbol in libisoburn: $ xorriso --help xorriso: symbol lookup error: /lib64/libisoburn.so.1: undefined symbol: iso_write_opts_set_max_ce_entries, version LIBISOFS6 xorriso-1.5.6-1.fc39.x86_64 libisoburn-1.5.6-1.fc39.x86_64 Reproducible: Always
Originally reported by Richard W.M. Jones at bug #2216134 comment #13
Hi, iso_write_opts_set_max_ce_entries is provided by libisofs-1.5.6 and advertised in its libisofs/libisofs.ver file. The installed libisofs.so seems not to provide this symbol and thus appears to be outdated. The source tarball of libisofs-1.5.6 is supposed to produce libisofs.so.6.92.0 This page agrees: https://packages.fedoraproject.org/pkgs/libisofs/libisofs/fedora-rawhide.html#files So is your libisofs.so.6 a link to this file ? Do you get at least one match reported from this run: strings /usr/lib64/libisofs.so.6.92.0 | grep iso_write_opts_set_max_ce_entries The upstream source version is not to see as text in the .so file, i fear. It is handed out to callers as three integer numbers. The numbers are defined in the file /usr/include/libisofs/libisofs.h of the libisofs-devel package that was used to produce libisofs.so. They are supposed to have been: #define iso_lib_header_version_major 1 #define iso_lib_header_version_minor 5 #define iso_lib_header_version_micro 6 (I wonder why libisofs-devel provides file /usr/lib64/libisofs.so which i would have expected with the libisofs package. If you have it installed then check whether it finally points to libisofs.so.6.92.0 .) Have a nice day :) Thomas
> The source tarball of libisofs-1.5.6 is supposed to produce libisofs.so.6.92.0 - libisofs-1.5.6-1.fc39.x86_64.rpm provides /usr/lib64/libisofs.so.6 and /usr/lib64/libisofs.so.6.92.0, see: https://koji.fedoraproject.org/koji/rpminfo?rpmID=34805992 - libisofs-devel-1.5.6-1.fc39.x86_64.rpm provides /usr/lib64/libisofs.so, see: https://koji.fedoraproject.org/koji/rpminfo?rpmID=34805996 - /usr/lib64/libisofs.so and /usr/lib64/libisofs.so.6 are boths symlinks to /usr/lib64/libisofs.so.6.92.0 and comply with Fedora Packaging Guidelines > strings /usr/lib64/libisofs.so.6.92.0 | grep iso_write_opts_set_max_ce_entries $ strings /usr/lib64/libisofs.so.6.92.0 | grep iso_write_opts_set_max_ce_entries iso_write_opts_set_max_ce_entries $ Additionally, I am unable to reproduce this issue in a container with Fedora Rawhide. Sorry, Thomas for bothering you! Richard, your report does not include the version of libisofs, could you provide this one as well, please? Is it possible that the local system is somehow screwed up?
I actually have: libisofs-1.5.4-5.fc38.x86_64 Let me upgrade that ...
I now have: xorriso-1.5.6-1.fc39.x86_64 libisoburn-1.5.6-1.fc39.x86_64 libisofs-1.5.6-1.fc39.x86_64 but I still see a problem (slightly different this time): $ xorriso --version xorriso: symbol lookup error: /lib64/libisoburn.so.1: undefined symbol: burn_write_opts_set_bdr_obs_exempt, version LIBBURN4
There is also libburn: libburn-1.5.4-6.fc38.x86_64 Upgrading to: libburn-0:1.5.6-1.fc39.x86_64 FIXES the problem. I wonder if it'd be better to use some versioned Requires lines in xorriso.spec? Or else get upstream to use proper symbol versioning (they seem to be using some half-assed versioning).
Hi, Richard W.M. Jones wrote: > libisofs-1.5.4-5.fc38.x86_64 > libburn-1.5.4-6.fc38.x86_64 So the "symbol lookup error" comes before the internal tests of libisoburn and xorriso get an opportunity to complain about insufficiently modern libisofs and libburn. But shouldn't the package system know that libisoburn-1.5.6 wants the 1.5.6 versions of the underlying companion libraries ? > Or else get upstream to use proper > symbol versioning (they seem to be using some half-assed versioning). There is only one version strain libisofs.so.6 which is kept compatible for older API/ABI users. The .ver files of libisoburn, libisofs, and libburn were introduced mainly to prevent rogue function calling which circumvented the defined API and accessed internal functions from outside the library. A first version check happens at compile time of libisoburn which would fail if not the development headers of the needed libisofs and libburn versions are included. Another version check happens at run time when the library gets initialized. But this check is not reached because the library loader already prevented the program start. If you can point me to docs or examples how to let the error message tell something like "LIBISOFS.6.91.0/1.5.4" instead of "LIBISOFS6" then i will consider to improve the .ver files. Have a nice day :) Thomas
RPM creates automatic dependencies for soname versions, like *.so.6. From my understanding if you break/change ABI, you should bump the soname version, e.g. to *.so.7.
Every time you add a new symbol to the library you should version it with the version where it appears. Here's an example from libvirt: https://github.com/libvirt/libvirt/blob/master/src/libvirt_public.syms Dan wrote about that here: https://www.berrange.com/posts/2011/01/13/versioning-in-the-libvirt-library/
There's no need to bump the SONAME, in fact that would be wrong since these are not breaking changes. Simple symbol versioning can cope with this.
Thank you for correcting me! :)
Hi, Robert Scheck wrote: > From my > understanding if you break/change ABI, you should bump the soname version, > e.g. to *.so.7. The ABI is not broken but only expanded. New functions get in, but old function stay and keep their parameter prototypes and the meaning of old parameter tuples. If i'd bump the SONAME then old applications like Xfburn would need to stay with the old library versions. As it is now, Xfburn made for libisofs-1.4.8 can use the new libisofs and benefit from possible bug fixes of old API functions. Richard W.M. Jones wrote: > Every time you add a new symbol to the library you should version it with > the version where it appears. I will study the given links and try to improve. ------------------------------------------------------------------------- But in any case i advise to let the package manager know about the version demands of libisoburn towards libisofs and libburn. Especially since the code enforces sufficiently new versions at run time even if no symbols are missing. You may generally assume that the needed versions are those which were released together with libisoburn. I.e demand equal or higher than the own version of libisoburn. Caveat: Recompiling with the devel headers of new libburn and libisofs causes in old libisoburn the need for the new libisofs.so and libburn.so. Have a nice day :) Thomas
(In reply to Thomas Schmitt from comment #12) > But in any case i advise to let the package manager know about the version > demands of libisoburn towards libisofs and libburn. Especially since the > code enforces sufficiently new versions at run time even if no symbols > are missing. If you expose the symbols like at libvirt, they'll make it into the RPM, see e.g. https://koji.fedoraproject.org/koji/rpminfo?rpmID=34946998
> If you expose the symbols like at libvirt, they'll make it into the RPM, see e.g. > https://koji.fedoraproject.org/koji/rpminfo?rpmID=34946998 Exactly this, yes. There are still some tricky cases with symbol versioning, but for this case where you're just adding a new API then it will work and RPM will do the right thing.
Hi, i tested the following change in the libisofs/libisofs.ver file of the development version of libisofs. It moves the four new API symbols of release 1.5.6 into a new node "LIBISOFS6_1.5.6". Although i cannot find an explicit statement in https://ftp.gnu.org/old-gnu/Manuals/ld-2.9.1/html_chapter/ld_3.html#SEC25 that old programs can stand such a move, i get no error when running a xorriso binary that was made when all symbols were in node "LIBISOFS6". (I verified by removal that it really wants to link the new experimental libisofs.) Nevertheless i am still reluctant to publish this back-in-time change with the next libisofs release. Unless i see explicit confirmation that it is indeed supposed to work for programs which had seen the library stemming from the old .ver file, i would prefer to begin adding new linker script nodes only with the next release and to keep the four new API symbols of 1.5.6 in the old "LIBISOFS6" node. (If it is indeed specified to work with retroactively changed version nodes, then i would be able to reflect the API history back to version 0.6.2 of 2008. Question is whether this is desirable and worth any risk.) Do you have means to test whether the change to libisofs.ver will indeed cause a resulting libisoburn RPM to demand the installation of the libisofs-1.5.6 RPM ? It works fine: Can you add the change as patch to Fedora ? Next libisofs release is not expected to come soon. Have a nice day :) Thomas --- libisofs/libisofs.ver.C30714 2023-07-14 08:57:18.499926315 +0200 +++ libisofs/libisofs.ver 2023-07-14 09:11:10.591929457 +0200 @@ -21,7 +21,6 @@ el_torito_set_load_seg; el_torito_set_load_size; el_torito_set_no_bootable; el_torito_set_selection_crit; -iso_assess_written_features; iso_conv_name_chars; iso_crc32_gpt; iso_data_source_new_from_file; @@ -230,7 +229,6 @@ iso_node_xinfo_make_clonable; iso_node_zf_by_magic; iso_nowtime; iso_obtain_msgs; -iso_read_image_feature_named; iso_read_image_features_destroy; iso_read_image_features_get_size; iso_read_image_features_has_eltorito; @@ -238,7 +236,6 @@ iso_read_image_features_has_iso1999; iso_read_image_features_has_joliet; iso_read_image_features_has_rockridge; iso_read_image_features_rr_loaded; -iso_read_image_features_text; iso_read_image_features_tree_loaded; iso_read_opts_auto_input_charset; iso_read_opts_free; @@ -350,7 +347,6 @@ iso_write_opts_set_joliet_long_names; iso_write_opts_set_joliet_longer_paths; iso_write_opts_set_joliet_utf16; iso_write_opts_set_max_37_char_filenames; -iso_write_opts_set_max_ce_entries; iso_write_opts_set_ms_block; iso_write_opts_set_no_force_dots; iso_write_opts_set_old_empty; @@ -384,3 +380,12 @@ iso_zisofs_set_params; serial_id; local: *; }; + +LIBISOFS6_1.5.6 { +global: +iso_assess_written_features; +iso_read_image_feature_named; +iso_read_image_features_text; +iso_write_opts_set_max_ce_entries; +} LIBISOFS6; +
(In reply to Thomas Schmitt from comment #15) > Hi, > > i tested the following change in the libisofs/libisofs.ver file of the > development version of libisofs. It moves the four new API symbols of > release 1.5.6 into a new node "LIBISOFS6_1.5.6". > > Although i cannot find an explicit statement in > https://ftp.gnu.org/old-gnu/Manuals/ld-2.9.1/html_chapter/ld_3.html#SEC25 > that old programs can stand such a move, i get no error when running > a xorriso binary that was made when all symbols were in node "LIBISOFS6". Moving symbols between version nodes is *NOT* backwards compatible, and is equivalent to an ABI break. The possible combinations are as follows * Lib has no sym version, app has no sym version -> OK * Lib has no sym version, app has sym version A -> FAIL (can't remove sym versions from an existing library that an app has linked to) * Lib has sym version A, app has no sym version -> OK (this lets you add sym version to a existing library without breaking existing apps) * Lib has sym version A, app has sym version A -> OK (versions match) * Lib has sym version A, app has sym version B -> FAIL (can't change sym versions in a library that an app has linked to) NB, when I say "app" above, it could also just be another library. WRT you testing xorriso binary, while that binary links to libisofs.so, it only does so indirectly via libisoburn.so, and that's what has the versioned symbol references. Picking one arbitrary function 'iso_read_image_features_has_rockridge', we see the exported symbol in libisofs.so: $ eu-readelf -a /usr/lib64/libisofs.so.6 | grep GLOBAL | grep iso_read_image_features_has_rockridge 407: 000000000001d670 12 FUNC GLOBAL DEFAULT 14 iso_read_image_features_has_rockridge@@LIBISOFS6 and see the corresponding usage in libisoburn.so: $ eu-readelf -a /usr/lib64/libisoburn.so.1 | grep UNDEF | grep iso_read_image_features_has_rockridge 10: 0000000000000000 0 FUNC GLOBAL DEFAULT UNDEF iso_read_image_features_has_rockridge@LIBISOFS6 (3) and nothing in xorriso at all $ eu-readelf -a /usr/bin/xorrisofs | grep UNDEF | grep ISOFS Merely running xorrisofs might not show the symbol breakage unless you exercise a code path that uses the symbol in question, as LD will lazy-resolve symbols Setting the env variable 'LD_BIND_NOW=1' will force ld.so to resolve all symbols immediately at startup instead of on-demand. > Nevertheless i am still reluctant to publish this back-in-time change > with the next libisofs release. Unless i see explicit confirmation that > it is indeed supposed to work for programs which had seen the library > stemming from the old .ver file, i would prefer to begin adding new linker > script nodes only with the next release and to keep the four new API > symbols of 1.5.6 in the old "LIBISOFS6" node. Yes that is the correct thing to do. Once a mistake has been made with the symbol addition that has gone into a formal release, it needs to be preserved to maintain ABI compatibility
Hi, Daniel Berrangé wrote: > Moving symbols between version nodes is *NOT* backwards compatible, and > is equivalent to an ABI break. That's not what i see in my experiment of today, but it matches my scruples. > WRT you testing xorriso binary, while that binary links to libisofs.so, it > only does so indirectly via libisoburn.so, and that's what has the versioned > symbol references. Not in my experiment. libisoburn and xorriso were not recompiled after i changed libisofs.ver and installed the resulting library. Either the change did not come into effect (despite new timestamps of libisofs.so.6.92.0 and confirmation that xorriso does not start without that file) or on my Debian the checking is not as strict as supposed. > Setting the env variable 'LD_BIND_NOW=1' will force ld.so to resolve all > symbols immediately at startup instead of on-demand. The error message which triggered this bug report indicates that the symbol iso_write_opts_set_max_ce_entries was attempted to be loaded long before a call to that function was attempted. This astonished me, because i am used to the internal version check reporting an error at startup if libisofs version does not match. Can it be that LD_BIND_NOW=1 was in effect when Richard W.M. Jones encountered the error ? Whatever, your description and my scruples match. I will not publish libisofs.ver with the retroactive node LIBISOFS6_1.5.6 but only change my cheat sheet so that the next new symbol gets into LIBISOFS6_1.5.8. (1.5.7 is a development version not intended to be released.) ----------------------------------------------------------------------- So there remains the Fedora specific problem that the libisoburn-1.5.6 RPM does not demand libisofs-1.5.6 and libburn-1.5.6. I am curious how this can be solved. Further i wonder how i would talk RPM production into demanding the next version libisofs-1.5.8 if no new symbols would be added to 1.5.8, but some backward compatible parameter change would have happened. In libisofs-1.5.6 changelog there is * New iso_write_opts_set_system_area() option bits 16: GPT "Legacy BIOS bootable" and 17: GPT writable and in the API description libisofs.h: * @param options * Can cause manipulations of submitted data before they get written: [...] * bit16= "Legacy BIOS bootable" in GPT * @since 1.5.6 * If this bit is set and a GPT partition for the ISO 9660 * filesystem gets written, then set the GPT partition flags bit 2 * "Legacy BIOS bootable". * bit17= ISO not read-only * @since 1.5.6 * Do not set GPT partition flag bit 60 "read-only" for the * ISO 9660 filesystem partition, if such a partition gets * written. If xorriso sends these bits to libisofs-1.5.4, then the desired effects would silently not happen. To prevent such misconfiguration, the run-time check of libisoburn would refuse to let it start. Example: After changing the softlink libisofs.so.6 to point to the next older version libisofs.so.6.91.0 i get this: $ xorriso -version xorriso 1.5.6 : RockRidge filesystem manipulator, libburnia project. xorriso : FATAL : Cannot initialize libraries. Reason given: libjte-2.0.0 ok, libisofs-1.5.5 - TOO OLD -, need at least libisofs-1.5.7 , libburn-1.5.7 ok, for libisoburn-1.5.6 (libjte is a specialty of Debian and brought in at compile time only when its development header and .so exist.) In the end i still think that the RPM building process needs to know what dependencies are prescribed in the upstream README and enforced in the code rather than to rely on the linker script which seems not able to express all my development habits. Have a nice day :) Thomas
(In reply to Thomas Schmitt from comment #17) > > WRT you testing xorriso binary, while that binary links to libisofs.so, it > > only does so indirectly via libisoburn.so, and that's what has the versioned > > symbol references. > > Not in my experiment. libisoburn and xorriso were not recompiled after > i changed libisofs.ver and installed the resulting library. > Either the change did not come into effect (despite new timestamps of > libisofs.so.6.92.0 and confirmation that xorriso does not start without > that file) or on my Debian the checking is not as strict as supposed. So I've just done a test as follows.. From a 1.5.6 release I applied this change to move a random pile of symbols: diff --git a/libisofs/libisofs.ver b/libisofs/libisofs.ver index 7216da6..0683b29 100644 --- a/libisofs/libisofs.ver +++ b/libisofs/libisofs.ver @@ -170,6 +170,10 @@ iso_local_get_perms_wo_acl; iso_local_set_acl_text; iso_local_set_attrs; iso_local_set_attrs_errno; +local: *; +}; + +LIBISOFS6_FISH { iso_md5_clone; iso_md5_compute; iso_md5_end; @@ -382,5 +386,4 @@ iso_zisofs_get_params; iso_zisofs_get_refcounts; iso_zisofs_set_params; serial_id; -local: *; -}; +} LIBISOFS6; Then built the binary as normal ./configure make We can see a symbol has got a new version "LIBISOFS6_FISH" $ eu-readelf -a libisofs/.libs/libisofs.so | grep GLOBAL | grep iso_read_opts_set_default_gid 183: 000000000001cc30 20 FUNC GLOBAL DEFAULT 13 iso_read_opts_set_default_gid@@LIBISOFS6_FISH and when I try to run xorriso bniary it fails $ LD_LIBRARY_PATH=./libisofs-1.5.6/libisofs/.libs/ xorriso xorriso: symbol lookup error: /lib64/libisoburn.so.1: undefined symbol: iso_read_opts_set_default_gid, version LIBISOFS6 And can see that libisoburn.so wants the old version $ eu-readelf -a /lib64/libisoburn.so.1 | grep iso_read_opts_set_default_gid | grep UNDEF 2: 0000000000000000 0 FUNC GLOBAL DEFAULT UNDEF iso_read_opts_set_default_gid@LIBISOFS6 (3) > > So there remains the Fedora specific problem that the libisoburn-1.5.6 > RPM does not demand libisofs-1.5.6 and libburn-1.5.6. > I am curious how this can be solved. Fedora just needs to put explicit manual versioned deps on the RPMs in question
Hi, Daniel Berrangé wrote: > Fedora just needs to put explicit manual versioned deps on the RPMs in > question Now we only have to convince Robert and Richard. :)) > iso_local_set_attrs_errno; > +local: *; > +}; > + > +LIBISOFS6_FISH { > iso_md5_clone; > [...] > +} LIBISOFS6; This fails here too. A bit differently, probably because of the obviously lazy loading: .../xorriso: relocation error: .../libisoburn.so.1: symbol iso_text_to_sev, version LIBISOFS6 not defined in file libisofs.so.6 with link time reference But if i re-install my experimental change as in comment 15, ./configure, make, make install, then i get a work-willing xorriso. xorriso and libisoburn are still not re-compiled or re-installed since the experiments began. So i assume that the lazy loading creates the illusion of compatibility. And indeed, if i trigger the use of the new function by .../xorriso -compliance max_ce_entries=16 -outdev test.iso -map x /x i get the expected error .../xorriso: relocation error: .../libisoburn.so.1: symbol iso_write_opts_set_max_ce_entries, version LIBISOFS6 not defined in file libisofs.so.6 with link time reference Thanks for enlightening me. Have a nice day :) Thomas
(In reply to Thomas Schmitt from comment #19) > Now we only have to convince Robert and Richard. :)) As the package maintainer of libburnia in Fedora, I do not have an issue to add (run-time) requirements on package versions if its needed for some technical reasons, but I still wonder if soname versioning and symbols etc. shouldn't do the trick on upstream side, like they do for "all" other packages? Maybe I'm too less a developer to understand why it doesn't work here? Could you clarify if the expected requirements between the libburnia packages should be just "equal" or "equal or greater than" (assume the latter)? For the -devel packages, its "equal or greater than".
Hi, Robert Scheck wrote: > I still wonder if soname versioning and symbols etc. shouldn't do > the trick on upstream side Daniel Berrangé explained and demonstrated why it is not advisable to retroactively change the linker script libisofs.ver so that the new symbols of 1.5.6 would appear in an own node. My own experiments were a bit obscured by symbol loading on demand but in the end i got the same load error when asking xorriso to do some real work. (I now addedd LD_BIND_NOW=1 to all my development test runs of xorriso and cdrskin which shall check whether the binaries start up. Luckily i never made a mistake in libisofs.ver which would have slipped through this loophole.) Fedora could decide that libisofs-1.5.6 is fresh enough to make the change of comment 15 in libisofs.ver and to rebuild all packages which depend on libisofs. But this would make libisofs-1.5.6 in Fedora unusable for all programs which were compiled with upstream libisofs-1.5.6. > Could you clarify if the expected requirements between the libburnia > packages should be just "equal" or "equal or greater than" (assume the > latter)? For the -devel packages, its "equal or greater than". Currently the right setting is "equal or greater than 1.5.6" for libisofs and libburn. Quite a safe and surely a convenient bet would be "equal or greater than the own libisoburn version", if that is possible. In general i release libisofs, libburn, and libisoburn as bundle with the same version numbers. In theory it is possible that not a single novelty would be to publish in libisofs or libburn. In that case i would have to ponder whether to omit the release of that library and to keep the dependency demand of libisoburn at the old version number. If i decide so, then the package maintainer of libisoburn would notice when trying to build it. I have to stress again, that libisoburn.so internally stores the version of the libisofs.h and libburn.h headers seen at compile time and will refuse to start with lower versions of the .so libraries even if those lower versions would suffice. See the refusal example in comment 17 where libisoburn-1.5.6 had seen the newest development headers and thus demands version 1.5.7: xorriso : FATAL : Cannot initialize libraries. Reason given: libjte-2.0.0 ok, libisofs-1.5.5 - TOO OLD -, need at least libisofs-1.5.7 , libburn-1.5.7 ok, for libisoburn-1.5.6 (Actually the example was posted to show what happens if a really outdated libisofs is encountered.) Have a nice day :) Thomas
Hi, thinking more about it, my upstream idea of dependencies is best matched by: For the -devel packages of libisofs and libburn: "equal". For the runtime libraries: "equal or greater". Of course the maintainance needs of a distro might prefer "or greater" for recompiling. In that case the runtime demand must be adjusted to the version of the actually used development headers. Have a nice day :) Thomas
This bug appears to have been reported against 'rawhide' during the Fedora Linux 39 development cycle. Changing version to 39.
FEDORA-EPEL-2024-4043d91825 (libisoburn-1.5.6-5.el7) has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-4043d91825
FEDORA-EPEL-2024-0577296243 (libisoburn1-1.5.6-5.el8) has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-0577296243
FEDORA-2024-6f3b8b1d39 (libisoburn-1.5.6-5.fc39) has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2024-6f3b8b1d39
FEDORA-2024-81ce31f2d2 (libisoburn-1.5.6-5.fc38) has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2024-81ce31f2d2
FEDORA-EPEL-2024-4043d91825 has been pushed to the Fedora EPEL 7 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-4043d91825 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2024-0577296243 has been pushed to the Fedora EPEL 8 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-0577296243 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2024-1cf1c2f170 has been pushed to the Fedora 40 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-1cf1c2f170` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-1cf1c2f170 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2024-6f3b8b1d39 has been pushed to the Fedora 39 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-6f3b8b1d39` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-6f3b8b1d39 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2024-81ce31f2d2 has been pushed to the Fedora 38 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-81ce31f2d2` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-81ce31f2d2 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2024-4043d91825 (libisoburn-1.5.6-5.el7) has been pushed to the Fedora EPEL 7 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-EPEL-2024-0577296243 (libisoburn1-1.5.6-5.el8) has been pushed to the Fedora EPEL 8 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2024-6f3b8b1d39 (libisoburn-1.5.6-5.fc39) has been pushed to the Fedora 39 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2024-81ce31f2d2 (libisoburn-1.5.6-5.fc38) has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2024-1cf1c2f170 (libisoburn-1.5.6-5.fc40) has been pushed to the Fedora 40 stable repository. If problem still persists, please make note of it in this bug report.