Mock/COPR create different release versions for i686 vs x86_64

Ask Fedora
,
1

Hello, all!

I have been trying to build some packages locally with mock and online with Copr.
These packages have built successfully in the past.
When using the “fedora-rawhide-*” chroot , the i686 packages are generated to be “fc38” while the x86_64 packages are “fc37”. This then creates the problem of “inferior architecture” when attempting dnf update.

Any thoughts?

Thanks!

1 Like
2

It looks like Fedora 37 was just branched from rawhide a few days ago. I’m not sure how it explains the difference in Arch, but it might make sense if the x86_64 was created on or before August 9th and i686 was added since then.

It would be helpful to provide a link to your copr repo so we can see the buildroots and logs.

1 Like
3

Hello and thanks for the reply.
I assumed it had to do with branching. There usually is an “adjustment period” for things to settle down a bit. I often have issues with gpg-keys around the branching time.

As an example of the current issue, please check out a recent build of libvpx:
https://copr.fedorainfracloud.org/coprs/dturner/codecs/build/4730490/

Note that the x86_64 builds are “fc37” while the i686 builds are “fc38”

Since my system requires both x86_64 and i686 versions of libvpx, a dnf update gives this error:
Problem: cannot install the best update candidate for package libvpx-1.12.0.20220804-1.aa2dc0cc7.fc37.i686

  • libvpx-1.12.0.20220812-1.c082f0ca1.fc38.i686 has inferior architecture

I could force a local mock build with “–root fedora-37-i386”, but it seems to me it should be automatic.

Locally with mock if I use:
–root fedora-37-i386 → “fc37”
–root fedora-rawhide-i386 → “fc38”
–root fedora-37-x86_64 → “fc37”
–root fedora-rawhide-x86_64 → “fc37” ***

Thanks!

1 Like
4

For my $.02 as a fellow copr maintainer, I tend to assume rawhide won’t have the same consistency as release branches, including version tagging, and especially close to a branch date. I usually let the dust settle around the alpha/beta period before I start paying attention to things like this. I suggest that if you desire that specificity, then you should probably specify it. To be clear, I don’t believe your assumption is unreasonable in any way, but the initial branch period can be a bit chaotic and I imagine that updating the automatic release tagging on a secondary architecture might not be the imminent top priority in the moment, even if it’s a legitimate thing to be solved.

So, you’re right, IMO, but I would still suggest specificity if you’re working around rawhide/pre-beta stuff.

1 Like
5

I agree!

I just don’t recall having “this” problem in the past.
BTW, I am SUPER AMATEUR with this stuff. It’s fun, though!

Thanks for your time. It is appreciated.

1 Like