Learn more about these different git repos.
Other Git URLs
glibc-headers-2.29-9.fc30.i686 glibc-headers-2.29-9.fc30.x86_64
Both exist in the x86_64 repo for the 'fedora' repo, but the first glibc update released to the 'updates' repo is missing the i686 package.
Bodhi update: https://bodhi.fedoraproject.org/updates/FEDORA-2019-f82f6f0c87
The i686 package is not needed, but since it was in the F30 GA compose, some people may have installed it.
Ideally, the package would not be there, but if it is consistently included, this is also fine.
Previous issue: releng#7071 Bugzilla bug: https://bugzilla.redhat.com/show_bug.cgi?id=1652872
Hm, yeah... this is messy. It requires manual intervention to fix. Thanks for the pointer to the bug, but releng may still need to be involved to fix the repos unless you want to add an Obsoletes: i686 headers package to the x86_64 headers package. I've updated this ticket title.
Metadata Update from @syeghiay: - Issue assigned to mohanboddu
ok, so I would love to fix this once and for all.
I guess the two options are:
glibc-devel-0:2.31.9000-4.fc33.i686 glibc-devel-0:2.31.9000-4.fc33.x86_64 libattr-devel-0:2.4.48-8.fc32.i686 libattr-devel-0:2.4.48-8.fc32.x86_64 libecb-devel-0:0.20190722-3.fc32.i686 librichacl-devel-0:1.12-9.fc32.i686 vcglib-0:1.0.1-2.fc32.i686 vcglib-0:1.0.1-2.fc32.x86_64
Can we fix those to only requre glibc-headers.%{isa}?
Or
@fweimer do you have a pref? Do you think the packages can be fixed? Or is there some reason it should get pulled in?
@kevin Not sure how you determined the list of affected packages. We cannot change glibc-devel. There is a necessary variance here: the i686 buildroot pulls in glibc-devel.i686 and glibc-headers.i686, but on an x86_64 compose-based installation, it should be glibc-devel.i686 and glibc-headers.x86_64.
glibc-devel
glibc-devel.i686
glibc-headers.i686
glibc-headers.x86_64
The other packages simply should not have a dependency on glibc-headers. That part can be fixed.
glibc-headers
We could perhaps rename glibc-headers to glibc-headers-x86 on x86_64 and i686 and make that package noarch. Would that help?
glibc-headers-x86
@kevin Not sure how you determined the list of affected packages. We cannot change glibc-devel.
Just dnf repoquery on a x86_64 machine...
There is a necessary variance here: the i686 buildroot pulls in glibc-devel.i686 and glibc-headers.i686, but on an x86_64 compose-based installation, it should be glibc-devel.i686 and glibc-headers.x86_64.
? Should that second one be glibc-devel.x86_64 and glibc_headers.x86_64?
yeah.
So the desired state is:
a) no glibc-headers.i686 in the base repo or in updates/updates-testing
or
b) glibc-headers.i686 is in the base repo and always updates/updates-testing (if there is a glibc update in there).
either one right?
I think this might work. Since there would no longer be a .i686 and .x86_64 versions of that subpackage it would just use it (once)
We could also do 'b' above in pungi by telling it to always include glibc-headers.i686 in the updates composes.
Do you want to try your idea and we can see if it works? if not, we can just revert it and go with the pungi hammer?
I'm not sure if these repoquery results are accurate.
If you install the 32-bit C/C++ development on an x86_64 machine, you are expected to get glibc-devel.i686 and glibc-headers.x86_64 (in addition to glibc-devel.x86_64 for the 64-bit environment). I think I got that part right …
glibc-devel.x86_64
(a) or (b) should work, yes. (a) is better for alignment with downstream, I guess.
Yes, I can try the noarch approach in rawhide (and fix up the packages that are not compatible with it).
I implemented this locally and it seems to work (still ironing out a few issues). I've submitted a Change proposal: https://fedoraproject.org/wiki/Changes/RemoveGlibcHeaders
A new glibc package is now built with the proposed changes
https://koji.fedoraproject.org/koji/buildinfo?buildID=1499075
We will verify it tomorrow and close this ticket if its fixed.
Metadata Update from @cverna: - Assignee reset
This is fixed. Please re-open if you see anything further to do here.
Metadata Update from @kevin: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
@kevin You mean, the issue is worked around in glibc, right?
The noarch hack unfortunately has its own set of bad side effects, but they seem to impact end users less and are at least 100% predictable, so unless the infrastructure issue has been identified & fixed, I guess we have to stick to it. 8-(
Well, if there's bad side effects to that, we can do it on the infra side.
I think it just needs us blocking glibc-headers from being multilib on x86_64 in both pungi-fedora (for rawhide) and infrastructure ansible (for updates).
Would you like us to try that in rawhide?
Metadata Update from @kevin: - Issue status updated to: Open (was: Closed)
rawhide doesn't have an updates repository, so we don't know if things are fixed if it works there.
We implemented the noarch hack after years of occasional breakage. If you are confident that you can make the glibc-headers problem go away on the infrastructure side, then please do so. No one else has been able to. I'm very much in favor of removing the noarch hack if we can.
I think we can... but perhaps I could get @lsedlar to chime in here?
Would it work to put glibc-headers in multilib blacklist for rawhide/branched and bodhi pungi config? ie, never ship glibc-headers.i686 in the x86_64 repos at all?
I would think it would, but I might be missing something now.
ok, so where are we here?
Would you like us to try the blocklist? Or is the workaround sufficent that we can just stay with it?
@kevin Is this question directed at me? 8-)
I would still very much like to get rid of the noarch packages. Filtering glibc-headers.i686 from the x86_64 compose should work as a stop-gap, I assume, even if the underlying tooling issue has not been addressed.
Actually it was more addressed to @lsedlar I guess, but you input is welcome too. :)
In the previous ticket we were looking at ways to always ship glibc-headers.i686 in x86_64 repos, but it seems like we would prefer to not ship it anywhere ?
I am not sure what the underlying tooling issue is here. I think pungi is doing what we tell it to do, and we just need to tell it to do the right thing. ;)
So, can we just add this to multilib_blacklist and be done? I think it's too late to do this for f37, but could we start in rawhide and carry that into f38 after branching?
I can add this to pungi for rawhide and then you can undo the noarch thing, then we can confirm it's not shipping there anymore?
Then we will need to make sure to also adjust config when we branch.
I think we should make these changes for rawhide/f38 as you propose, and see how it goes.
Sorry for the stale here, is this something that is required? If so we can implement the plan from the previous comment by nirik for the current rawhide.
Login to comment on this ticket.