This package has been retired

This update has been unpushed.

@buckaroogeek and I discussed this on Matrix. Thanks! docker-compose already has an Updates Policy exception, and the breaking changes (including my unfounded concern about podman compose build breakage) were found not to be super groundbreaking after local testing. So I will remove my previous strong objection. If you still think it makes sense, this should be okay to push after it's spent the required amount of time in testing as long nobody else complains :).

Test comment

I did some testing with scancode and go-vendor-tools and ensured that nothing breaks.

I'm pushing this now to make sure that the updates to the scancode-toolkit stack all go stable at the same time. In the future, these updates should probably be submited in a side tag and not pushed as separate updates.

I did some testing with scancode and go-vendor-tools and ensured that nothing breaks.

I'm pushing this now to make sure that the updates to the scancode-toolkit stack all go stable at the same time. In the future, these updates should be submited in a side tag and not pushed as separate updates.

This should probably be fixed to explicitly depend on libmagic.so.1, but that can be done later I suppose.

Okay, I guess this was fixed in https://github.com/aboutcode-org/scancode-plugins/commit/82b6a06e4626525e219f7fac321f4c2a557cd4b5 to hardcode libmagic.so.1 now.

I did some testing with scancode and go-vendor-tools and ensured that nothing breaks.

I'm pushing this now to make sure that the updates to the scancode-toolkit stack all go stable at the same time. In the future, these updates should be submited in a side tag and not pushed as separate updates.

I did some testing with scancode and go-vendor-tools and ensured that nothing breaks.

I'm pushing this now to make sure that the updates to the scancode-toolkit stack all go stable at the same time. In the future, these updates should be submited in a side tag and not pushed as separate updates.

I did some testing with scancode and go-vendor-tools and ensured that nothing breaks.

I'm pushing this now to make sure that the updates to the scancode-toolkit stack all go stable at the same time. In the future, these updates should be submited in a side tag and not pushed as separate updates.

This is still wrong, even with https://bodhi.fedoraproject.org/updates/FEDORA-2025-7e4cbfaac3. See https://src.fedoraproject.org/fork/gotmax23/rpms/python-typecode-libmagic/c/3ee7c71d8bb6d1198ac1996c31e6afe50d9dfe4d.

I did some testing with scancode and go-vendor-tools and ensured that nothing breaks.

I'm pushing this now to make sure that the updates to the scancode-toolkit stack all go stable at the same time. In the future, these updates should be submited in a side tag and not pushed as separate updates.

I did some testing with scancode and go-vendor-tools and ensured that nothing breaks.

I'm pushing this now to make sure that the updates to the scancode-toolkit stack all go stable at the same time. In the future, these updates should be submited in a side tag and not pushed as separate updates.

I did some testing with scancode and go-vendor-tools and ensured that nothing breaks.

I'm pushing this now to make sure that the updates to the scancode-toolkit stack all go stable at the same time. In the future, these updates should be submited in a side tag and not pushed as separate updates.