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 libtool-2.4.2-34.fc22.x86_64 gcc-5.1.1-4.fc22.x86_64 cpp-5.1.1-4.fc22.x86_64 libgomp-5.1.1-4.fc22.x86_64
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 Resolving Dependencies --> 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: https://bodhi.fedoraproject.org/updates/?packages=gcc
I spinned new f22 scratch build and there is still gcc-5.1.1 only in buildroot: https://kojipkgs.fedoraproject.org//work/tasks/6484/11276484/root.log 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 https://koji.fedoraproject.org/koji/buildinfo?buildID=688565
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