Description of problem: Package libmodulemd fails to build from source in Fedora rawhide. Version-Release number of selected component (if applicable): 2.12.0-2.fc34 Steps to Reproduce: koji build --scratch f35 libmodulemd-2.12.0-2.fc34.src.rpm Additional info: This package is tracked by Koschei. See: https://koschei.fedoraproject.org/package/libmodulemd
A difference between failing and passing build root is at <https://koschei.fedoraproject.org/build/10117110>. The failure is specific to an architecture. From the build.log: 16/73 modulemd:ci+c+c_release / compression_release FAIL 0.16s killed by signal 6 SIGABRT >>> MESON_SOURCE_ROOT=/builddir/build/BUILD/modulemd-2.12.0 TEST_DATA_PATH=/builddir/build/BUILD/modulemd-2.12.0/modulemd/tests/test_data LC_ALL=C MESON_BUILD_ROOT=/builddir/build/BUILD/modulemd-2.12.0/x86_64-redhat-linux-gnu MALLOC_PERTURB_=148 /builddir/build/BUILD/modulemd-2.12.0/x86_64-redhat-linux-gnu/modulemd/compression ――――――――――――――――――――――――――――――――――――― ✀ ――――――――――――――――――――――――――――――――――――― stdout: # random seed: R02Se862895bf40fb64592f6bba7ee685b1f 1..4 # Start of modulemd tests # Start of compression tests ok 1 /modulemd/compression/type Bail out! libmodulemd:ERROR:../modulemd/tests/test-modulemd-compression.c:146:test_modulemd_detect_compression: assertion failed (modulemd_detect_compression (filename, fd, &error) == expected_magic[j].type): (-1 == 3) stderr: ** libmodulemd:ERROR:../modulemd/tests/test-modulemd-compression.c:146:test_modulemd_detect_compression: assertion failed (modulemd_detect_compression (filename, fd, &error) == expected_magic[j].type): (-1 == 3) ―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――― It looks like an ABI change of an underlying library.
(In reply to Petr Pisar from comment #1) > A difference between failing and passing build root is at > <https://koschei.fedoraproject.org/build/10117110>. > The failure is specific to an architecture. > Not really. The tests are disabled on ARM.
This is triggered by upgrading "file" package from 5.39-5.fc34.x86_64 to 5.40-1.fc35.x86_64.
This looks like a regression in libmagic. It should be detecting `application/x-xz` but it is now returning `application/octet-stream`. Steps to reproduce: * `echo hello > /tmp/hello.txt` * `xz /tmp/hello.txt` * `file -i /tmp/hello.txt` On file-5.39-5.fc34.x86_64 this returns: hello.txt.xz: application/x-xz; charset=binary On file-5.40-1.fc35.x86_64 this returns: hello.txt.xz: application/octet-stream; charset=binary
(In reply to Stephen Gallagher from comment #4) > This looks like a regression in libmagic. It should be detecting > `application/x-xz` but it is now returning `application/octet-stream`. > > Steps to reproduce: > > * `echo hello > /tmp/hello.txt` > * `xz /tmp/hello.txt` > * `file -i /tmp/hello.txt` > Obviously, that last line should be `file -i /tmp/hello.txt.xz`. Sorry for the typo.
Upstream bug is https://bugs.astron.com/view.php?id=257
Vincent, for the time being, could you revert https://github.com/file/file/commit/3ebd747d in the Fedora build until the upstream ticket is fixed? That should resolve this for now.
Sure, dist-git commit: https://src.fedoraproject.org/rpms/file/c/532851e62eb56cd0376aedfd20c57c39e21dc390
I think moving the !: tags just after the leading magic helps: # http://tukaani.org/xz/xz-file-format.txt 0 ustring \xFD7zXZ\x00 XZ compressed data !:strength * 2 !:mime application/x-xz >7 byte&0xf 0x0 NONE >7 byte&0xf 0x1 CRC32 >7 byte&0xf 0x4 CRC64 >7 byte&0xf 0xa SHA-256 Nevertheless, thanks for the fix.
Upstream agrees with Petr: https://github.com/file/file/commit/9b0459afab309a82aa4e46f73a4e50dd641f3d39 I submitted a PR to replace the reversion patch with the fix: https://src.fedoraproject.org/rpms/file/pull-request/9
Thank you both.