Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: Trying to update glibc to glibc-2.27.9000-39.fc29 ..... file /usr/bin/ldd conflicts between attempted installs of glibc-2.27.9000-39.fc29.i686 and glibc-2.27.9000-39.fc29.x86_64
Please provide the complete DNF error message.
Its not dnf but rpm -Fhv
Oh, I see. Carlos, your filelist reorganization was incorrect. Did you plan to make this change? You said that The changes were tested by carrying out a file-by-file comparison to ensure no file changed packages or installed location after the patch. but clearly this wasn't the case.
(In reply to Florian Weimer from comment #3) > Oh, I see. > > Carlos, your filelist reorganization was incorrect. Did you plan to make > this change? You said that > > The changes were tested by carrying out a file-by-file comparison > to ensure no file changed packages or installed location after > the patch. > > but clearly this wasn't the case. I'm reviewing this right now.
(In reply to Carlos O'Donell from comment #4) > (In reply to Florian Weimer from comment #3) > > Oh, I see. > > > > Carlos, your filelist reorganization was incorrect. Did you plan to make > > this change? You said that > > > > The changes were tested by carrying out a file-by-file comparison > > to ensure no file changed packages or installed location after > > the patch. > > > > but clearly this wasn't the case. > > I'm reviewing this right now. So, something clearly went wrong, the final rawhide builds shows a file list difference, that is to say my expand-rpms.sh / compare-rpms.sh scripts show a difference. If I'd seen it I wouldn't have pushed a rawhide build. I had what I thought was a minor merge cleanup before I pushed my commits, but clearly I made a mistake somewhere. Sorry for that. I'll fix this up right now.
For the record, this broke today's Rawhide compose as the sudden embiggening of the glibc package caused the ARM minimal disk image package set to be too big for the root filesystem size. https://pagure.io/dusty/failed-composes/issue/532
I had *just* verified everything when I did my git pull --rebase, and ran into a merge conflict. It's a one line fix. -%files -f rpm.filelist +%files -f glibc.filelist Florian's changes to add POWER9 were just at the right place to cause a merge conflict, and I picked Florian's changes without noticing the rpm.filelist->glibc.filelist reversion. The result is that glibc.rpm has *all* the files from all the packages. Teaches me that I should always just change the names of data files if they change their semantic meaning in the build process. After the reorganization the rpm.filelist is the "master" file list but shouldn't get used for any package file lists. So I've renamed 'rpm.filelist' to 'master.filelist' to denote the semantic change and avoid any confusion between earlier versions of the spec file and the current version. This will be fixed in glibc-2.27.9000-40.fc29. Doing a scratch build again just out of paranoia. Sorry for the breakage.
New build in progress: https://koji.fedoraproject.org/koji/taskinfo?taskID=28216160
Scratch build and local mock build all passed comparison tests again.