Bug 2435063 - retis: FTBFS in Fedora rawhide/f44
Summary: retis: FTBFS in Fedora rawhide/f44
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: retis
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Antoine Tenart
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: F44FTBFS
TreeView+ depends on / blocked
 
Reported: 2026-01-29 06:43 UTC by Fedora Release Engineering
Modified: 2026-01-30 13:30 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2026-01-30 11:17:00 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
build.log (32.00 KB, text/plain)
2026-01-29 06:43 UTC, Fedora Release Engineering
no flags Details
root.log (32.00 KB, text/plain)
2026-01-29 06:43 UTC, Fedora Release Engineering
no flags Details
state.log (1.62 KB, text/plain)
2026-01-29 06:43 UTC, Fedora Release Engineering
no flags Details

Description Fedora Release Engineering 2026-01-29 06:43:23 UTC
retis failed to build from source in Fedora rawhide/f44

https://koji.fedoraproject.org/koji/taskinfo?taskID=141204676


For details on the mass rebuild see:

https://fedoraproject.org/wiki/Fedora_44_Mass_Rebuild
Please fix retis at your earliest convenience and set the bug's status to
ASSIGNED when you start fixing it. If the bug remains in NEW state for 8 weeks,
retis will be orphaned. Before branching of Fedora 45,
retis will be retired, if it still fails to build.

For more details on the FTBFS policy, please visit:
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/

Comment 1 Fedora Release Engineering 2026-01-29 06:43:29 UTC
Created attachment 2126941 [details]
build.log

file build.log too big, will only attach last 32768 bytes

Comment 2 Fedora Release Engineering 2026-01-29 06:43:41 UTC
Created attachment 2126942 [details]
root.log

file root.log too big, will only attach last 32768 bytes

Comment 3 Fedora Release Engineering 2026-01-29 06:43:44 UTC
Created attachment 2126943 [details]
state.log

Comment 4 Antoine Tenart 2026-01-30 09:27:13 UTC
This is actually a libbpf error, https://github.com/libbpf/libbpf/commit/d88ca951338a765bcb28672dc7b1221fde8e4ae4

Retis consumes it as part of libbpf-rs which does from libbpf-sys. This is fixed since https://github.com/libbpf/libbpf-rs/releases/tag/v0.26.0-beta.1 (in Retis https://github.com/retis-org/retis/issues/572).

Fixing this is basically a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=2431444 as the libbpf-rs/sys bump was done in v1.6.3.

@decathorpe you mentioned upgrading libbpf-rs on the other bz. Is that still planned? One thing I'm not sure is if we can actually use the v0.26.0-beta.1 version as it's not a "proper" release? BTW let me know if you need help on that.

Comment 5 Antoine Tenart 2026-01-30 10:50:37 UTC
> Is that still planned?

Seems like you already did upgrade libbpf-rs to 0.25 :)

The question still stands though, we need it to support newer versions of libbpf-sys. One option is upgrading to v0.26.0-beta.1 (see previous comment), another might be to backport the relevant commits to 0.25 (if no  incompatibilities).

Comment 6 Fabio Valentini 2026-01-30 11:17:00 UTC
Actually, it seems like this FTBFS is no longer accurate.

The package no longer fails to build from source in current rawhide (hence also why the CI on my PR to bump the bindgen dependency passed). I've just submitted a new build to koji. It should be possible to also submit a new build for F43 after the libbpf-sys 1.6.2 update lands in "stable" there too.

If you need libbpf-rs v0.26.0-beta.1, that's something I can do (doing pre-releases just involves a bit of additional weirdness due to how cargo chooses versions during dependency resolution).

Comment 7 Antoine Tenart 2026-01-30 13:30:01 UTC
(In reply to Fabio Valentini from comment #6)
> The package no longer fails to build from source in current rawhide (hence
> also why the CI on my PR to bump the bindgen dependency passed). I've just
> submitted a new build to koji. It should be possible to also submit a new
> build for F43 after the libbpf-sys 1.6.2 update lands in "stable" there too.

Thanks!

> If you need libbpf-rs v0.26.0-beta.1, that's something I can do (doing
> pre-releases just involves a bit of additional weirdness due to how cargo
> chooses versions during dependency resolution).

Given the above let me try to use libbpf-rs 0.25 for the Retis 1.6.3 update, if that does not work I'll reach out.


Note You need to log in before you can comment on or make changes to this bug.