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.
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.
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.
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-22.214.171.12420804-1.aa2dc0cc7.fc37.i686
libvpx-126.96.36.19920812-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” ***
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.