Bug 791032 - repoclosure failure in 17-Alpha.RC2 DVDs (ceph-0.37-2.fc17)
repoclosure failure in 17-Alpha.RC2 DVDs (ceph-0.37-2.fc17)
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: gperftools (Show other bugs)
17
All Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Tom "spot" Callaway
Fedora Extras Quality Assurance
AcceptedBlocker
:
Depends On:
Blocks: F17Alpha/F17AlphaBlocker
  Show dependency treegraph
 
Reported: 2012-02-15 19:12 EST by Andre Robatino
Modified: 2012-02-21 11:06 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-02-21 11:06:31 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
my current .src.rpm (2.24 MB, application/octet-stream)
2012-02-16 20:08 EST, Adam Williamson
no flags Details

  None (edit)
Description Andre Robatino 2012-02-15 19:12:59 EST
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
Comment 1 Adam Williamson 2012-02-15 19:49:57 EST
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
Comment 2 Adam Williamson 2012-02-15 19:52:54 EST
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.
Comment 3 Adam Williamson 2012-02-15 19:54:48 EST
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.
Comment 4 Adam Williamson 2012-02-15 19:55:11 EST
The gperftools update submission is https://admin.fedoraproject.org/updates/gperftools-2.0-3.fc17 .
Comment 5 Adam Williamson 2012-02-16 19:46:11 EST
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
Comment 6 Adam Williamson 2012-02-16 19:58:37 EST
CCing spot for help with the code monkeying.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 7 Adam Williamson 2012-02-16 20:08:09 EST
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.
Comment 8 Tom "spot" Callaway 2012-02-17 10:40:29 EST
This is done, I finished it off last night and updated the updates.
Comment 9 Andre Robatino 2012-02-21 11:06:31 EST
Fixed in 17 Alpha RC3. No repoclosure or fileconflicts problems.

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