Came across an oddity today and I'm not sure if it's mock or yum that's the problem.
I'm running with these updates from updates-testing (on an FC7 host): mock-0.7.2-1.fc7 yum-3.2.1-1.fc7
My rawhide mock config points to a single baseurl for the fedora repo, and goes through a local squid proxy. I'm also using autocache.
From time to time packages cannot be retrieved over the network, perhaps due to the mirror being in mid-sync, or maybe transient network issues.
Sometimes this results in one or more (but not all) packages not being available to populate a buildroot when running mock. When this happens, mock is not terminating the build during the setup phase, and allows it to continue to the build phase. I noticed this problem because it often results in a failed build due to to some important missing buildreq.
More worrying though is the possibility that a missing buildreq package may be needed only to enhance the functionality of the package being built. In such cases the overall build may succeed but produce a package with reduced functionality, and be different from the same package rebuilt by someone else on their own system.
So is this yum not returning a proper exit code, or mock ignoring it? I'm not sure.
Is this a known issue? I couldn't see anything that looked like this in bugzilla.
Paul.
On Mon, 2007-06-25 at 16:18 +0100, Paul Howarth wrote:
Came across an oddity today and I'm not sure if it's mock or yum that's the problem.
I'm running with these updates from updates-testing (on an FC7 host): mock-0.7.2-1.fc7 yum-3.2.1-1.fc7
My rawhide mock config points to a single baseurl for the fedora repo, and goes through a local squid proxy. I'm also using autocache.
From time to time packages cannot be retrieved over the network, perhaps due to the mirror being in mid-sync, or maybe transient network issues.
Try this as a good test: Make a package with a BuildRequires: something-that-doesn't-exist
If the build doesn't bail, then we have a problem, if it does bail, then we're fine.
Can you test that and let me know?
-sv
seth vidal wrote:
On Mon, 2007-06-25 at 16:18 +0100, Paul Howarth wrote:
Came across an oddity today and I'm not sure if it's mock or yum that's the problem.
I'm running with these updates from updates-testing (on an FC7 host): mock-0.7.2-1.fc7 yum-3.2.1-1.fc7
My rawhide mock config points to a single baseurl for the fedora repo, and goes through a local squid proxy. I'm also using autocache.
From time to time packages cannot be retrieved over the network, perhaps due to the mirror being in mid-sync, or maybe transient network issues.
Try this as a good test: Make a package with a BuildRequires: something-that-doesn't-exist
If the build doesn't bail, then we have a problem, if it does bail, then we're fine.
Can you test that and let me know?
OK, tried this:
* Got a simple perl module package and added a buildreq of perl(No::Such::Module) to it. * Tried building it: mock failed as I'd have expected ("No Package Found for perl(No::Such::Module)")
To more accurately mimic the issue I was seeing, I then:
* Created a dummy perl-No-Such-Module package that provided perl(No::Such::Module) * Added that package to a local repo that's in my mock config * After running createrepo to update the metadata, I then deleted the actual RPM from the repo * Tried building the original perl module package
This reproduced what I was seeing; the dependency seemingly being available from the metadata was sufficient for mock to proceed to the build phase.
The consequences aren't as bad as I'd thought though, as yum doesn't seem to have installed *any* of the buildreqs in the setup phase, which would cause most package builds to fail.
Paul.
Paul Howarth wrote:
seth vidal wrote:
On Mon, 2007-06-25 at 16:18 +0100, Paul Howarth wrote:
Came across an oddity today and I'm not sure if it's mock or yum that's the problem.
I'm running with these updates from updates-testing (on an FC7 host): mock-0.7.2-1.fc7 yum-3.2.1-1.fc7
My rawhide mock config points to a single baseurl for the fedora repo, and goes through a local squid proxy. I'm also using autocache.
From time to time packages cannot be retrieved over the network, perhaps due to the mirror being in mid-sync, or maybe transient network issues.
Try this as a good test: Make a package with a BuildRequires: something-that-doesn't-exist
If the build doesn't bail, then we have a problem, if it does bail, then we're fine.
Can you test that and let me know?
OK, tried this:
- Got a simple perl module package and added a buildreq of
perl(No::Such::Module) to it.
- Tried building it: mock failed as I'd have expected ("No Package Found
for perl(No::Such::Module)")
To more accurately mimic the issue I was seeing, I then:
- Created a dummy perl-No-Such-Module package that provided
perl(No::Such::Module)
- Added that package to a local repo that's in my mock config
- After running createrepo to update the metadata, I then deleted the
actual RPM from the repo
- Tried building the original perl module package
This reproduced what I was seeing; the dependency seemingly being available from the metadata was sufficient for mock to proceed to the build phase.
The consequences aren't as bad as I'd thought though, as yum doesn't seem to have installed *any* of the buildreqs in the setup phase, which would cause most package builds to fail.
Has anyone reproduced this?
Paul.
buildsys@lists.fedoraproject.org
-
Paul Howarth -
seth vidal