Bug 1631250

Summary: distribution: i686 packages sporadically missing in the updates-testing compose
Product: [Fedora] Fedora Reporter: Ali Akcaagac <aliakc>
Component: distributionAssignee: Josh Boyer <jwboyer>
Status: CLOSED CANTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 29CC: aliakc, aoliva, arjun, codonell, dj, fweimer, kevin, law, mfabian, pfrankli, rth, siddhesh
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-09-20 10:47:01 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
repolist.txt none

Description Ali Akcaagac 2018-09-20 10:03:23 UTC 
I have the following situation:

I maintain a buildscript that builds AROS (Amiga Research Operating System) 32bit and 64bit. The system that builds AROS is Fedora 29.

The buildscript is written by me a couple of weeks ago. To compile AROS I install the glibc 32bit and 64bit (which as we know should work on a 64bit architecture to ensure that other stuff works e.g. wine and co.). I also need to install glibc-static along with glibc-headers for 32bit and 64bit. Because libc.a needs to be linked for a specific architecture as well as some headers ending with *-32.h and *-64.h needs to be used. The headers usually come from the devel packages installed for a certain version.

The buildscript used to handle this correctly since around 1-2 weeks or so (I can't narrow it down any more because I haven't used that script over that period).

Now for a couple of days I've been getting this output as shown below.

When Installing the dependencies DNF wants to dongrade glibc to 2.28-6 rather than staying with the 2.28-9 version. Something along the chain wants to enforce a downgrade.

I know I can apply --best and --allowerasing to DNF but this shouldn't be the correct way. I don't want to downgrade glibc so some dependency feel happy along the chain. I want to keep glibc at the version it is and only have the necessary stuff installed with it.

The buildscript (aros.sh) can be found at the link below and the option to install the dependencies is "aros.sh -d" as root (you may disable the --assumeyes inside the script).

http://aros-exec.org/modules/newbb/viewtopic.php?post_id=109710#forumpost109710

I also verified whether glibc 2.28-9 might have been pulled off from the repositories but a "dnf download glibc*" ensures that glibc 2.28-9 is latest and not glibc-2.28-6 (which some dependency wants to downgrade).

Can this issue be solved ?

Dependencies resolved.

 Problem 1: glibc-headers-2.28-6.fc29.i686 has inferior architecture
  - package libxcrypt-devel-4.1.2-1.fc29.i686 requires glibc-headers(x86-32) >= 2.26.9000-46, but none of the providers can be installed
  - cannot install both glibc-headers-2.28-6.fc29.x86_64 and glibc-headers-2.28-9.fc29.x86_64
  - package glibc-devel-2.28-9.fc29.i686 requires libxcrypt-devel(x86-32) >= 4.0.0, but none of the providers can be installed
  - package glibc-devel-2.28-9.fc29.x86_64 requires glibc-headers = 2.28-9.fc29, but none of the providers can be installed
  - cannot install the best candidate for the job
 Problem 2: package glibc-static-2.28-9.fc29.x86_64 requires glibc-devel = 2.28-9.fc29, but none of the providers can be installed
  - package glibc-devel-2.28-9.fc29.x86_64 requires glibc = 2.28-9.fc29, but none of the providers can be installed
  - package glibc-devel-2.28-9.fc29.i686 requires glibc = 2.28-9.fc29, but none of the providers can be installed
  - glibc-2.28-9.fc29.i686 has inferior architecture
  - cannot install both glibc-2.28-6.fc29.x86_64 and glibc-2.28-9.fc29.x86_64
  - glibc-2.28-6.fc29.i686 has inferior architecture
  - package glibc-headers-2.28-6.fc29.i686 requires glibc = 2.28-6.fc29, but none of the providers can be installed
  - package libxcrypt-devel-4.1.2-1.fc29.i686 requires glibc-headers(x86-32) >= 2.26.9000-46, but none of the providers can be installed
  - package libxcrypt-static-4.1.2-1.fc29.i686 requires libxcrypt-devel(x86-32) = 4.1.2-1.fc29, but none of the providers can be installed
  - package glibc-static-2.28-9.fc29.i686 requires libxcrypt-static(x86-32) >= 4.0.0, but none of the providers can be installed
  - cannot install the best candidate for the job
Comment 1 Florian Weimer 2018-09-20 10:06:51 UTC 
Please show us the output of “dnf repolist -v”.  Thanks.
Comment 2 Ali Akcaagac 2018-09-20 10:10:26 UTC 
Created attachment 1485089 [details]
repolist.txt

Here the repolist.txt as asked.
Comment 3 Florian Weimer 2018-09-20 10:47:01 UTC 
Sorry.  This is a problem with the updates-testing compose:

$ rsync rsync://ftp-stud.hs-esslingen.de/fedora/linux/updates/testing/29/Everything/x86_64/Packages/g/ | grep glibc-headers
-rw-r--r--        470,608 2018/08/29 21:26:40 glibc-headers-2.28-9.fc29.x86_64.rpm

This is not something we can fix in the glibc package.  ALso see: https://pagure.io/releng/issue/7071
Comment 4 Ali Akcaagac 2018-09-20 11:27:05 UTC 
Ok if I understand it correctly:

1) updates or regular fedora repo has -6 while updates-testing has -9
2) updates-testing somehow can't handle resolving the packages or maybe packages missing - whatever
3) this means:

dnf install whatever-glibc --best --allowerasing would be the (temporarely) best option. This will downgrade all glibc related packages (and whatever along the chain) to the versions that are *not* yet pushed from updates-testing to updates or/and fedora. So basicly it downgrades the entire chain to what it believes to be the latest packages in the stable repo. Even risking that newer libraries and tools need to downgrade as well...

I can add these two options to DNF and even mark a hint to both bugreports and the pagure one together with a comment that the script (aros.sh) should better be run in a virtual machine or a workhorse machine but not on the production computer...