Bug 791032 - repoclosure failure in 17-Alpha.RC2 DVDs (ceph-0.37-2.fc17)
Summary: repoclosure failure in 17-Alpha.RC2 DVDs (ceph-0.37-2.fc17)
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: gperftools
Version: 17
Hardware: All
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Tom "spot" Callaway
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker
Depends On:
Blocks: F17Alpha, F17AlphaBlocker
TreeView+ depends on / blocked
 
Reported: 2012-02-16 00:12 UTC by Andre Robatino
Modified: 2012-02-21 16:06 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-02-21 16:06:31 UTC
Type: ---


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

Description Andre Robatino 2012-02-16 00:12:59 UTC
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-16 00:49:57 UTC
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-16 00:52:54 UTC
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-16 00:54:48 UTC
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-16 00:55:11 UTC
The gperftools update submission is https://admin.fedoraproject.org/updates/gperftools-2.0-3.fc17 .

Comment 5 Adam Williamson 2012-02-17 00:46:11 UTC
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-17 00:58:37 UTC
CCing spot for help with the code monkeying.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 7 Adam Williamson 2012-02-17 01:08:09 UTC
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 15:40:29 UTC
This is done, I finished it off last night and updated the updates.

Comment 9 Andre Robatino 2012-02-21 16:06:31 UTC
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.