Red Hat Bugzilla – Bug 1267530
needs rebuild for new GCC
Last modified: 2015-11-16 04:51:33 EST
i would like to test the new GCC builds but libtoll neeeds to be rebuilt
[root@testserver:/data]$ dnf update *.rpm
Last metadata expiration check performed 0:15:16 ago on Wed Sep 30 12:14:02 2015.
Error: package libtool-2.4.2-34.fc22.x86_64 requires gcc = 5.1.1, but none of the providers can be installed.
package gcc-5.1.1-4.fc22.x86_64 requires cpp = 5.1.1-4.fc22, but none of the providers can be installed.
package gcc-c++-5.2.1-3.fc22.x86_64 requires gcc = 5.2.1-3.fc22, but none of the providers can be installed.
package gcc-5.1.1-4.fc22.x86_64 requires libgomp = 5.1.1-4.fc22, but none of the providers can be installed.
package libtool-2.4.2-34.fc22.x86_64 requires gcc = 5.1.1, but none of the providers can be installed
(try to add '--allowerasing' to command line to replace conflicting packages)
Thanks for the report, Harald, but this looks like the problem is somewhere
else. In my F22 mock:
$ rpm -q libtool gcc cpp libgomp
no, yum reports the same dependency
Processing Dependency: gcc = 5.1.1 for package: libtool-2.4.2-34.fc22.x86_64
maybe your mock build is newer then https://koji.fedoraproject.org/koji/buildinfo?buildID=630482 from Thu, 23 Apr 2015 23:45:37 UTC and what counts for us users are the deps in the packages from the repos and builds we face
[root@testserver:/data]$ yum-deprecated update *.rpm
Yum command has been deprecated, use dnf instead.
See 'man dnf' and 'man yum2dnf' for more information.
Examining cpp-5.2.1-3.fc22.x86_64.rpm: cpp-5.2.1-3.fc22.x86_64
Marking cpp-5.2.1-3.fc22.x86_64.rpm as an update to cpp-5.1.1-4.fc22.x86_64
Examining gcc-5.2.1-3.fc22.x86_64.rpm: gcc-5.2.1-3.fc22.x86_64
Marking gcc-5.2.1-3.fc22.x86_64.rpm as an update to gcc-5.1.1-4.fc22.x86_64
Examining gcc-c++-5.2.1-3.fc22.x86_64.rpm: gcc-c++-5.2.1-3.fc22.x86_64
Marking gcc-c++-5.2.1-3.fc22.x86_64.rpm as an update to gcc-c++-5.1.1-4.fc22.x86_64
Examining libatomic-5.2.1-3.fc22.x86_64.rpm: libatomic-5.2.1-3.fc22.x86_64
Marking libatomic-5.2.1-3.fc22.x86_64.rpm as an update to libatomic-5.1.1-4.fc22.x86_64
Examining libgcc-5.2.1-3.fc22.x86_64.rpm: libgcc-5.2.1-3.fc22.x86_64
Marking libgcc-5.2.1-3.fc22.x86_64.rpm as an update to libgcc-5.1.1-4.fc22.x86_64
Examining libgomp-5.2.1-3.fc22.x86_64.rpm: libgomp-5.2.1-3.fc22.x86_64
Marking libgomp-5.2.1-3.fc22.x86_64.rpm as an update to libgomp-5.1.1-4.fc22.x86_64
Examining libstdc++-5.2.1-3.fc22.x86_64.rpm: libstdc++-5.2.1-3.fc22.x86_64
Marking libstdc++-5.2.1-3.fc22.x86_64.rpm as an update to libstdc++-5.1.1-4.fc22.x86_64
Examining libstdc++-devel-5.2.1-3.fc22.x86_64.rpm: libstdc++-devel-5.2.1-3.fc22.x86_64
Marking libstdc++-devel-5.2.1-3.fc22.x86_64.rpm as an update to libstdc++-devel-5.1.1-4.fc22.x86_64
--> Running transaction check
---> Package cpp.x86_64 0:5.1.1-4.fc22 will be updated
---> Package cpp.x86_64 0:5.2.1-3.fc22 will be an update
---> Package gcc.x86_64 0:5.1.1-4.fc22 will be updated
--> Processing Dependency: gcc = 5.1.1 for package: libtool-2.4.2-34.fc22.x86_64
Hmm, which channel are you getting gcc 5.2.X from? I can't see any
gcc update in bodhi:
I spinned new f22 scratch build and there is still gcc-5.1.1 only in buildroot:
How can I help here?
direct download from koji as you can see the localupdate
that's my testbuildserver and so i liked to rebuild local packages and report errors before it hits updates-testing or give karma from the pre-testing
Harald, I'm afraid I should not spin new build of libtool now. Until there is
build-override with new gcc, its probably not very wise to build new libtool
requiring newer gcc.
I would have to revert the 4b64b2d23cfee0e3bbaa01a57963457bc443ad45 commit and
specify gcc version manually again -- that wouldn't be that big issue, but we
would have different build-time and run-time versions of gcc and I don't think
this is desired.
Its perfect testing workflow, thanks for that -- but isn't it better to
build your local libtool then? Once there is bodhi update of GCC,
also libtool gets it's new build.
(In reply to Pavel Raiskup from comment #6)
> Harald, I'm afraid I should not spin new build of libtool now. Until there
> is build-override with new gcc, its probably not very wise to build new
> libtool requiring newer gcc.
It is also not possible -- you can see that /usr/bin/libtool contains
generated paths (auto-detected): `cat /usr/bin/libtool | grep -F 5.1.1`
I'll be happy to help you on irc if you wanted.
well, so i keep the downloads and wait until and new libtool package arrives, guess it will be coordinated by the GCC maintainers which likely want to bring out the update soon looking at the changelog