Extras i386 rawhide rebuild in mock status 2006-05-29

Paul Howarth paul at city-fan.org
Tue May 30 11:55:50 UTC 2006


Michael Schwendt wrote:
> On Tue, 30 May 2006 11:53:58 +0100, Paul Howarth wrote:
> 
>> Michael Schwendt wrote:
>>> On Mon, 29 May 2006 23:19:01 -0500, Matt Domsch wrote:
>>>
>>>> extras Rawhide-in-Mock Build Results for i386 Mon May 29 23:00:43 CDT 2006
>>>> Number failed to build: 176
>>>> Number expected to fail due to ExclusiveArch or ExcludeArch: 1
>>>> Leaving:  175
>>>> (there may be some duplicates if rawhide has 2 versions of a package)
>>>>
>>>> Of those expected to have worked...
>>>> Without a bug filed: 173
>>>> ----------------------------------
>>>> abe
>>>> alacarte
>>>> amaya
>>>> anjuta-gdl
>>>> balsa
>>> -snip-
>>>
>>> Note sure what the goal of this rebuild attempt is. Extras buildsys uses
>>> mock for a long time. So every package in Extras has built successfully in
>>> mock before. Most (if not all) of the rebuild failures you've caught here
>>> are due to updates in Rawhide, such as compiler updates or API changes.
>>> This report is misleading.
>> No, it's because he's building the packages with the reduced build 
>> environment that closely matches the exceptions list in the packaging 
>> guidelines rather than default mock configuration that pulls in lots of 
>> extra packages. So these build failures are mostly due to missing 
>> buildreqs of things like perl(XML::Parser), gettext, flex, etc.
> 
> That is not the impression I got after looking at probably two dozen
> builds reports. Only a few were due to missing BR.

You've looked at more than I have then. I've only looked at my own 
packages, two of which had missing buildreqss that I fixed in cvs before 
Matt's first "Extras" email, and one that had a missing buildreq that 
didn't actually cause a build failure. Having been through my own 
packages, I then looked at Matt's list and submitted bugs for the two 
listed packages that I'd done the original reviews for. Those were 
missing buildreqs too.

> Is this modified version of mock ready and available in Extras?

There's a new version in CVS that I believe behaves this way. Seth 
doesn't go for the "release early, release often" mantra though.

The current Extras mock can quite easily be configured to use a minimal 
buildroot though. You just need to create a local "groups" repo.

  * In some convenient location, download the buildsys-macros packages 
from http://fedoraproject.org/buildgroups/development/YOURARCH/

  * Create a minimal.xml file in the same directory, containing:

<?xml version="1.0"?>
<!DOCTYPE comps PUBLIC "-//Red Hat, Inc.//DTD Comps info//EN" "comps.dtd">

<comps>
   <group>
    <id>build</id>
    <uservisible>true</uservisible>
    <name>Minimal Install</name>
    <packagelist>
      <packagereq type="mandatory">bash</packagereq>
      <packagereq type="mandatory">bzip2</packagereq>
      <packagereq type="mandatory">coreutils</packagereq>
      <packagereq type="mandatory">cpio</packagereq>
      <packagereq type="mandatory">diffutils</packagereq>
      <packagereq type="mandatory">fedora-release</packagereq>
      <packagereq type="mandatory">gcc</packagereq>
      <packagereq type="mandatory">gcc-c++</packagereq>
      <packagereq type="mandatory">gzip</packagereq>
      <packagereq type="mandatory">make</packagereq>
      <packagereq type="mandatory">patch</packagereq>
      <packagereq type="mandatory">perl</packagereq>
      <packagereq type="mandatory">rpm-build</packagereq>
      <packagereq type="mandatory">redhat-rpm-config</packagereq>
      <packagereq type="mandatory">sed</packagereq>
      <packagereq type="mandatory">tar</packagereq>
      <packagereq type="mandatory">unzip</packagereq>
      <packagereq type="mandatory">buildsys-macros</packagereq>
    </packagelist>
   </group>
</comps>

  * Create the repo:
    $ createrepo -g minimal.xml .

  * Point your mock config at the local repo:

[groups]
name=groups
#baseurl=http://fedoraproject.org/buildgroups/development/i386/
baseurl=file:///path/to/local/repo/YOURARCH/

That should do it.

Paul.




More information about the fedora-devel-list mailing list