Description of problem: Running https://fedoraproject.org/wiki/QA:Testcase_Mediakit_Repoclosure on the 17-Alpha.RC2 DVDs: i386: package: ceph-0.37-2.fc17.i686 from myrepo unresolved deps: libtcmalloc.so.0 x86_64: package: ceph-0.37-2.fc17.x86_64 from myrepo unresolved deps: libtcmalloc.so.0()(64bit) Version-Release number of selected component (if applicable): 17 Alpha RC2
That dep is provided by google-perftools - except it was renamed gperftools yesterday, and spot killed google-perftools. So now we're stuck in a netherland where the compose didn't pull in google-perftools because it's 'dead' but also didn't pull in gperftools because it was built post-freeze and so hasn't been pushed stable. I guess the easiest thing to do to fix this is just push gperftools stable. +1 blocker, marking accepted blocker as repoclosure bugs just *are* blockers, there's no room for debate. Criterion is "There must be no file conflicts (cases where the files in some packages conflict but the packages have explicit Conflicts: tags are acceptable) or unresolved package dependencies during a media-based (DVD) install". -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Looks like ceph is a dep for qemu, which I think is part of an optional group on the DVD, so looks like this shouldn't affect default installs or live composes, which means RC2 is at least generally testable.
actually, gperftools has had an soname bump, so if we 'fix' this by taking the newer gperftools, we'll also have to rebuild ceph. if we 'fix' this by forcing the older google-perftools package into the RC compose, we don't have to rebuild ceph.
The gperftools update submission is https://admin.fedoraproject.org/updates/gperftools-2.0-3.fc17 .
So, ceph turns out to be a bitch to rebuild - it's never been built with GCC 4.7 and it has all sorts of issues that prevent it compiling, which don't seem to have upstream fixes. So far I've backported an upstream fix for a recent autotools change and implemented a trivial fix for one case of "Detection of redeclared variable names in nested scopes" (http://gcc.gnu.org/gcc-4.7/porting_to.html), but now I'm at: ./common/safe_io.h:29:3: error: 'ssize_t' does not name a type ./common/safe_io.h:31:3: error: 'ssize_t' does not name a type ./common/safe_io.h:33:3: error: 'ssize_t' does not name a type ./common/safe_io.h:35:3: error: 'ssize_t' does not name a type ./common/safe_io.h:42:3: error: 'ssize_t' does not name a type ./common/safe_io.h:44:3: error: 'ssize_t' does not name a type common/admin_socket_client.cc:113:78: error: 'safe_write' was not declared in this scope common/admin_socket_client.cc:144:24: error: 'safe_read_exact' was not declared in this scope common/admin_socket_client.cc:188:29: error: 'safe_read_exact' was not declared in this scope and sinking rapidly. As noted, I don't see any relevant upstream commits or patches submitted to the upstream ML. This is likely going to need someone who actually knows what the hell the code means, not someone like me blindly cargo-culting stuff in from the GCC 4.7 porting guide. Will attach my patches so far. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
CCing spot for help with the code monkeying. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Created attachment 563783 [details] my current .src.rpm my current .src.rpm. if you do 0.39 it's pretty much the same result, you have to backport one additional fix from upstream.
This is done, I finished it off last night and updated the updates.
Fixed in 17 Alpha RC3. No repoclosure or fileconflicts problems.