Fedora rawhide FTBFS status 2010-02-10 x86_64
jskarvad at redhat.com
Mon Feb 15 10:00:59 UTC 2010
Following the steps from deltarpm example (http://fedoraproject.org/wiki/UnderstandingDSOLinkChange#Example_deltarpm) helps me to reproduce the DSO issue in local mock.
----- Original Message -----
From: "Ralf Corsepius" <rc040203 at freenet.de>
To: "Development discussions related to Fedora" <devel at lists.fedoraproject.org>
Sent: Monday, February 15, 2010 8:55:03 AM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna
Subject: Re: Fedora rawhide FTBFS status 2010-02-10 x86_64
On 02/13/2010 04:50 PM, Matt Domsch wrote:
> Fedora Fails To Build From Source Results for x86_64
> using rawhide from 2010-02-10
> This run includes the new default linker feature --no-add-needed.
> This is responsible for 446 failures noted below. See
> http://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking for
> further details.
> Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/
> SoQt-1.4.1-14.fc13 (build/make) corsepiu
I can't reproduce this issue in a local mock using "released
rawhide". Scratch-building using Fedora's infrastructure, however
exposes this issue.
This renders investigating this issue quite difficult and imposes
problems in fixing it
What is required to be able to locally reproduce Matt's results?
- Is "released rawhide" different from what Matt rsp. "Fedora" is using?
- Is "released rawhide" outdated/Do I happen to be using outdated
- Are there some special settings required to trigger these DSO issues?
 Standard "fedora-rawhide-*" mock setup on FC12 without any modification.
 I meanwhile have a "hack" which lets this package build again, but
without being able to reproduce the issues in a local mock, I hardly can
verify my "hack"'s correctness (This breakdown could easily be a
side-effect of other bugs).
devel mailing list
devel at lists.fedoraproject.org
More information about the devel