Fedora Account System
Red Hat Associate
Red Hat Customer
Releases retrieved: 1.5.8 Upstream release that is considered latest: 1.5.8 Current version/release in rawhide: 1.5.6-9.fc44 URL: https://dev.lovelyhq.com/libburnia/web/wiki Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from Anitya: https://release-monitoring.org/project/1645/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/libisoburn
FEDORA-2026-e0469a1194 (libburn-1.5.8-1.fc45, libisoburn-1.5.8-1.fc45, and 1 more) has been submitted as an update to Fedora 45. https://bodhi.fedoraproject.org/updates/FEDORA-2026-e0469a1194
FEDORA-2026-81ac802e45 (libburn-1.5.8-1.fc44, libisoburn-1.5.8-1.fc44, and 1 more) has been submitted as an update to Fedora 44. https://bodhi.fedoraproject.org/updates/FEDORA-2026-81ac802e45
FEDORA-2026-358116db71 (libburn-1.5.8-1.fc43, libisoburn-1.5.8-1.fc43, and 1 more) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2026-358116db71
FEDORA-2026-43da4aa944 (libburn-1.5.8-1.fc42, libisoburn-1.5.8-1.fc42, and 1 more) has been submitted as an update to Fedora 42. https://bodhi.fedoraproject.org/updates/FEDORA-2026-43da4aa944
FEDORA-2026-e0469a1194 (libburn-1.5.8-1.fc45, libisoburn-1.5.8-1.fc45, and 1 more) has been pushed to the Fedora 45 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2026-43da4aa944 has been pushed to the Fedora 42 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-43da4aa944` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-43da4aa944 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2026-81ac802e45 has been pushed to the Fedora 44 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-81ac802e45` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-81ac802e45 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2026-358116db71 has been pushed to the Fedora 43 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-358116db71` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-358116db71 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
So... this seems to have broken rawhide composes. ;( The server dvd iso no longer builds. See: https://kojipkgs.fedoraproject.org//work/tasks/170/144060170/root.log DEBUG util.py:463: xorriso : NOTE : -return_with SORRY 32 triggered by problem severity SORRY DEBUG util.py:610: Child return code was: 32 I am going to untag it from rawhide for now until we can sort it out.
(In reply to Kevin Fenzi from comment #9) > So... this seems to have broken rawhide composes. ;( > > The server dvd iso no longer builds. > > See: > > https://kojipkgs.fedoraproject.org//work/tasks/170/144060170/root.log > > DEBUG util.py:463: xorriso : NOTE : -return_with SORRY 32 triggered by > problem severity SORRY > DEBUG util.py:610: Child return code was: 32 > > I am going to untag it from rawhide for now until we can sort it out. Thomas, do you see any chance to look at this?
Kevin, I might be wrong, but this could be Fedora-specific compose misconfiguration; passing "-xattr off" might do the trick, given the source files being on NFS. Could you provide a previous successful root.log, please?
https://kojipkgs.fedoraproject.org//work/tasks/4151/143984151/root.log is the previous one that worked. I'd have to look at how to pass that via pungi... or it might take some pungi patching.
Hi, and i invested so much time into testing ... grrr. The ioctl(FS_IOC_FSGETXATTR) tries to fetch the XFS-style project number of a file. See lsattr(1)/chattr(1) option -p. This feature is new in libisofs-1.5.8 and was supposed to be off by default. But there seems to be a logical inversion with the setting of command -projid. A gdb breakpoint in function aaip_get_projid() gets hit if -projid is set to "off" and not hit if "on". I will have to examine the wiring from xorriso setting to libisofs operations in order to find the culprit. It will last a few days until i release a .pl01 either of libisofs-1.5.8 or libisoburn-1.5.8. Remedy idea for compile time: The whole project id feature can be disabled in ./configure of libisofs by option: --disable-projid This seems to be the best solution for now. Not so good remedies at run time instead: The error indication threshold could be raised from -return_with SORRY 32 to -return_with FAILURE 32 This might prevent non-zero exit value for other medium-severe problems too. Setting -projid "on" for the time being would help, too. But this would have to be revoked as soon as the bug is fixed. Have a nice day :) Thomas
Thanks so much for looking at this so quickly! We should be ok for a bit here as I untagged the new build...
(In reply to Thomas Schmitt from comment #13) > I will have to examine the wiring from xorriso setting to libisofs > operations in order to find the culprit. It will last a few days until > i release a .pl01 either of libisofs-1.5.8 or libisoburn-1.5.8. Thank you very much for looking at this so fast! Just send me a "heads up" once there is a .pl01, for the time being the untagging from Kevin should be sufficient.
Hi, the bug is caused by a single "!" too many in libisofs function iso_image_set_ignore_aclea() in libisofs/image.c where image->builder_ignore_projid = !!(what & 64); has to be image->builder_ignore_projid = !(what & 64); A new libisofs-1.5.8.pl01 is uploaded as https://files.libburnia-project.org/releases/libisofs-1.5.8.pl01.tar.gz ----------------------------------------------------------------------- TLDR: The bug was hidden from my tests with -projid "on" by the fact that the getter function iso_image_get_ignore_aclea() has no such surplus negation. During xorriso command -outdev without previous -indev a preliminary libisofs IsoImage object gets the inverted setting "on". When it is replaced by a longer living IsoImage object, the setting is obtained correctly as "on" by the getter from the old object and set negated to the new one. So there is a double negation and the new object has the right setting "off". But an IsoImage object loaded by command -indev causes the subsequent command -outdev not to create a preliminary IsoImage object. So after -outdev has set the negated property, no pair of _get and _set is performed and thus no second negation happens. This different behavior of -outdev after -indev activated the bug in your ISO production run, which used -indev /mnt/koji/.../boot.iso -outdev /mnt/koji/.../Fedora-Server-dvd-x86_64-Rawhide-20260405.n.0.iso My tests either used the -as mkisofs emulation or performed runs in native command mode without -indev before -outdev. To my embarrassment they navigated around the bug when it came to reading project numbers from disk files and restoring them back to disk files. The project id features were tested with an ext4 filesystem which was created with feature "project" and mounted with option "prjquota". I also made tests with an ext4 which was lacking the "project" feature and optimistically concluded that other filesystems would behave gracefully, too. I now added a test for properly ignoring project ids to my cheat sheet. Further i decided that the behavior in case of failed ioctl(FS_IOC_FSGETXATTR) because of no support in the filesystem is very undesirable. Having no NFS, i was able to reproduce it with an ISO filesystem and a FAT filesystem as file sources. For 1.5.8.pl01 the "SORRY" error message about the failed ioctl is completely disabled and a project id of 0 is returned. This imitates the behavior which i experience with ext4 if the "project" feature is not enabled. On the long run i plan to stay silent only about errno 25 "Inappropriate ioctl for device". But the other errors will only cause a "WARNING" message and thus not produce a non-zero exit value. Have a nice day :)
Thanks again for the quick investigation on this. :) Hopefully all will be well next release.
Hi, thanks for the good wishes for the next release. Regrettably the after-release bugs have tradition and seem inavoidable despite any testing effort. The users have more use cases than i am able to foresee. Currently i am very curious whether libisofs-1.5.8.pl01 solves the problem with your ISO production run. Please drop a note in this bug report if it works now. Have a nice day :) Thomas
FEDORA-2026-db6bfcf01e (libisofs-1.5.8-2.fc44) has been submitted as an update to Fedora 44. https://bodhi.fedoraproject.org/updates/FEDORA-2026-db6bfcf01e
FEDORA-2026-52a8116472 (libisofs-1.5.8-2.fc42) has been submitted as an update to Fedora 42. https://bodhi.fedoraproject.org/updates/FEDORA-2026-52a8116472
(In reply to Kevin Fenzi from comment #9) > I am going to untag it from rawhide for now until we can sort it out. https://bodhi.fedoraproject.org/updates/FEDORA-2026-a39b20dd06 reached rawhide. Kevin, could you now please tag libisoburn-1.5.8-1.fc45 to rawhide again?
Sure, done. We will see how rawhide looks tomorrow. ;)
FEDORA-2026-db6bfcf01e has been pushed to the Fedora 44 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-db6bfcf01e` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-db6bfcf01e See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2026-358116db71 (libburn-1.5.8-1.fc43, libisoburn-1.5.8-1.fc43, and 1 more) has been pushed to the Fedora 43 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2026-43da4aa944 (libburn-1.5.8-1.fc42, libisoburn-1.5.8-1.fc42, and 1 more) has been pushed to the Fedora 42 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2026-dabf3e69e3 has been pushed to the Fedora 43 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-dabf3e69e3` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-dabf3e69e3 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2026-52a8116472 has been pushed to the Fedora 42 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-52a8116472` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-52a8116472 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2026-81ac802e45 (libburn-1.5.8-1.fc44, libisoburn-1.5.8-1.fc44, and 1 more) has been pushed to the Fedora 44 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2026-dabf3e69e3 (libisofs-1.5.8-2.fc43) has been pushed to the Fedora 43 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2026-52a8116472 (libisofs-1.5.8-2.fc42) has been pushed to the Fedora 42 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2026-db6bfcf01e (libisofs-1.5.8-2.fc44) has been pushed to the Fedora 44 stable repository. If problem still persists, please make note of it in this bug report.