Bug 1200176 - ppc64/ppc: F20 repo is missing ppc updates directory. Breaks network install & glibc multilib updates
Summary: ppc64/ppc: F20 repo is missing ppc updates directory. Breaks network install...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: distribution
Version: 20
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Peter Robinson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-03-09 22:29 UTC by Al Dunsmuir
Modified: 2015-04-13 20:35 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-04-08 13:22:38 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Yum update dependency errors (1.64 KB, text/plain)
2015-03-09 22:29 UTC, Al Dunsmuir
no flags Details
Problem persists with latest repo update (6.64 KB, text/plain)
2015-04-02 13:48 UTC, Al Dunsmuir
no flags Details

Description Al Dunsmuir 2015-03-09 22:29:48 UTC
Created attachment 999688 [details]
Yum update dependency errors

Description of problem: 
Fedora f20 is last ppc64/ppc multilib release

Recent security update to F20 has updates to 64-bit builds, but is missing updates to 32-bit builds (and at least one 32-bit build).

F20 is the last ppc release that supports both 64-bit (ppc64) and 32-bit
(ppc) packages. 
- The ppc packages are normally used in the 64-bit system via multilib
- On G5 Mac installs, there is an implicit install of 32-bit yaboot, glibc
  and nss.

It appears that the tool used to create the repos incorrectly dropped the
32-bit updates for F20.   

- For F19 (EOL) at http://ppc.koji.fedoraproject.org/tree/updates/19/
  there are ppc, ppc64, and source directories

- For F20 at http://ppc.koji.fedoraproject.org/tree/updates/20/ there is
  ppc64, ppc64le and source.  Note that the ppc directory is absent, which
  prevents any 32-bit updates from being available.  This would be valid 
  for F21, F22 and rawhide but not F20.

This causes two separate problems:

1) Network install of F20 on G5 Mac fails 
   - F20 installs yaboot on G5 Mac as stage 2 boot
   - The yaboot package is an implicit package installed by Anaconda.
     - This depends on the exact glib level, and needs to be rebuilt
       to allow network install to complete
     - Anaconda does not check dependencies of implicitly added 
       packages (bug 1)
   - Problem is fatal because Anaconda does not respect the switch to
     ignore the updates repository (bug 2).
   - I am trying to install F20 on G5 Mac as build system so I can work
     to eliminate yaboot residuals, and get grub2 working for Mac too.

   See https://bugzilla.redhat.com/show_bug.cgi?id=1192824 for previous
   work on getting F20 network install issue resolved (due to Perl 5.18.4
   update).  

2) Update of glibc/nss packages (via yum) fails because of multilib
   dependencies.  See attached file for details. 

I'm hopeful that yaboot rebuild with current glibc (after the basic glibc
& nss multilib issue is fixed) will be sufficient. The yaboot dependencies
are likely incorrect (should allow later glibc), but given that this is last release that needs yaboot (working to replace with grub2 throughout) that
does not seem worth fixing.

Version-Release number of selected component (if applicable):
glibc.ppc64 0:2.18.14.fc20 -> glibc.ppc64. 0:2.18.16.fc20

How reproducible:
100% during network install, and during yum update on previously installed
system.

Steps to Reproduce:
1.
2.
3.

Actual results:
1) Network install on Mac aborts after attempt to install yaboot bootloader
   fails due to ppc 32-bit package dependency errors.

2) yum update fails for glibc & nss packages.  Only 32-bit packages on system 
   are those due to yaboot dependencies. 

Expected results:
1) Network install completes
2) yum update completes

Because F20 is the last muilib release, I believe there is some urgency to fix these problems before this release goes EOL.  Soon is good, as the netinstall
issue means that I have only one F20 build system (all hardware is G5 Macs).

Additional info:

Comment 1 Al Dunsmuir 2015-03-13 11:32:35 UTC
The source for yaboot for f20 is yaboot.1.3.17-6.fc19.src.rpm and verified
that there are no explicit requires for glibc or the nss library.  It is 
likely that the existing yaboot rpm will be happy with the new libraries
once the ppc repo information is available on the shadow's tree again.

There have been a few F20 packages accumulate on the pending queue since
the last run on Feb 25th.  It's likely a good idea to incorporate those,
in case it exposes further dependency issues that need repair.

Thanks in advance,
Al

Comment 2 Peter Robinson 2015-04-01 09:54:27 UTC
Updates pushed and syncing to mirrors

Comment 3 Al Dunsmuir 2015-04-02 13:48:41 UTC
Created attachment 1010193 [details]
Problem persists with latest repo update

Comment 4 Al Dunsmuir 2015-04-02 13:51:32 UTC
Peter,

My first check was to attempt to update my already-installed ppc64 system.  The issue persists there - it still can not see the ppc multilib package updates.

I see that you regenerated both the trees on April 1 at
http://ppc.koji.fedoraproject.org/tree/updates/20/ppc/repodata/
http://ppc.koji.fedoraproject.org/tree/updates/20/ppc64/repodata/

It appears that the yum update on the ppc64 machine still does not see the ppc-specific updates.

Comment 5 Dan Horák 2015-04-02 14:06:32 UTC
Looks as the F-20 updates for ppc64 are not multilibed, only ppc64 (and noarch) rpms were included.

Comment 6 Peter Robinson 2015-04-08 13:22:38 UTC
Third time lucky!

Comment 7 Al Dunsmuir 2015-04-13 20:35:06 UTC
Third time the charm.
- Verified successful update of existing F20 ppc64 installation
- Verified successful dependencies on new F20 ppc64 install (via netinst) on G5
  PowerMac 
  - Selected Mate desktop, and development packages (C, rpm, fedora, services)
  - No issues with explicit ppc64 package dependencies
  - No issues with implicit (from Anaconda) yaboot ppc32 dependencies

Thank you so much Peter and Dan for fixing this!


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