Multiarch support for mock
by Andreas Thienemann
Hello,
I noticed some problems with mock, when building tools such as valgrind,
syslinux etc. on x86_64.
The default mock config says to exclude i386 and similar packages.
However, these programs depend on stubs-32.h from the i386 glibc-devel
package.
The x86_64 glibc-devel only brings stubs-64.h, which makes the compilation
of these tools stop, because stubs-32.h could not be found.
What would be the correct way of fixing this?
regards,
andreas
16 years, 10 months
[PATCH] autocache patch for mock
by Michael E Brown
Here is what I would consider to be a patch ready to check-in to
implement automatic caching of the mock buildroot. This feature is
disabled by default but can be turned on by the "--autocache" cli option
or the "use_cache" config file option.
The only feature not implmented is selectable compression. This
can be implemented by changing mock-helper.c to check the file extension
and only compress if end is .bz2 or .gz. I have not implemented this,
after looking at the speed difference between compressed and
uncompressed. It turns out that uncompressed is slower, probably due to
disk IO bandwidth. (compressed tarball for fc5 is ~200MB. Uncompressed
tarball is ~500MB)
Feedback appreciated.
--
Michael
<<mock-autocache.patch>>
16 years, 10 months
[PATCH] Fix PS1 prompt for shell
by Michael E Brown
Not quite a brown-paper-bag bug, but I broke the PS1 prompt for the
shell command. Not all that earth shattering, but the following trivial
patch fixes it.
It was due to using an old mock-helper which didn't have the PS1 in
ALLOWED_ENVS and the fact that I didn't notice that os.system() doesn't
pass along changes to os.environ.
--
Michael
<<mock-fixps1.patch>>
16 years, 10 months
rfc -- multibuild script
by Michael E Brown
Hi all. skvidal asked me to send a copy of my multibuild script to the
list. Here it is, in all its customized for my environment glory. If
there is interest, I could clean it up a bit more and add more cmdline
options instead of hardcoding some of the options.
The main advantage of this script is:
A) speed: runs a configurable number of builds in parallel.
B) auto repository creation: creates yum repo as output.
C) multi config build: builds a set of rpms for multiple configs
Note that this script assumes mock config files named like this:
fcX-ARCH.cfg
rhelX-ARCH.cfg
slesX-ARCH.cfg
That is because it outputs a yum repository structured like this:
/repo/fcX/{RPMS,SRPMS,repodata}
/repo/rhelX/{RPMS,SRPMS,repodata}
/repo/slesX/{RPMS,SRPMS,repodata}
Usage: multibuild.sh file1.src.rpm file2.src.rpm ...
Options:
p: http_proxy
c: config list (override builtin)
e: mock uniqueext
d debug
o: output directory (override automatically-deleted tempdir)
For now, I have a few variables hardcoded in the script. These could
probably be made cli options. See the CHANGEME entries. For testing, I
would recommend using the "-o /output/dir" option so you can examine the
output directory structure.
--
Michael
16 years, 10 months
[PATCH] plague server Repo.py
by Michael Schwendt
The file glob for debuginfo packages should be "*-debuginfo-*" since
the debuginfo rpms are called
%{name}-debuginfo-%{version}-%{release}.%{arch}.rpm
and not:
*.debuginfo.rpm
16 years, 10 months
RE: [RFC] in progress: autocache patch
by Michael E Brown
A couple of notes:
Credit should be given to Jochen Schmitt for his original patch:
http://www.redhat.com/archives/fedora-extras-list/2005-November/msg00169
.html
My mock-helper changes are straight from Jochen Schmitt's patch.
All mock.py changes are mine, with inspiration from Jochen's patch.
New Config options:
There are several new config options that can be placed in the mock
config file to control caching. See the additions to
setup_default_config_opts() for details, they should be relatively
self-explanatory. Note that "cache_topdir" is concatenated with
"basedir" with os.path.join(). This means that if cache_topdir begins
with a /, it will completely override basedir.
--
Michael
________________________________
From: fedora-buildsys-list-bounces(a)redhat.com
[mailto:fedora-buildsys-list-bounces@redhat.com] On Behalf Of
Michael_E_Brown(a)Dell.com
Sent: Tuesday, May 16, 2006 2:53 PM
To: fedora-buildsys-list(a)redhat.com
Subject: [RFC] in progress: autocache patch
Here is my current autocache patch for comments. I have
two features left to implement: 1) permissions on tarballs, and 2)
ability to select compressed/uncompressed tarballs.
Usage:
There are two added command line options. First is
"--autocache". You should be able to just add this command line option
to all mock invocations to automatically and transparently speed up
operations. It will automatically build cache the first time it is
invoked. It will automatically use the cache if it exists. It will
automatically expire the cache and rebuild it on a periodic basis. The
second option is "--rebuildcache". This option is for the rare occasions
when you would like to force a rebuild of the cache.
Theory:
The theory behind this patch is that it will
automatically untar the buildroot from a tarball, if the tarball exists.
It will automatically create the tarball if it does not exist (only when
--autocache is specified). The tarball has an expiration date, default
is 15 days. After the tarball is older than this, it will automatically
be rebuilt.
Test results:
Initial testing with FC5 yum repo mirror on local
network and squid proxy running on local machine resulted in a "init" of
the build root at 2:20. Using an already-cached build root takes this
time down to 0:13.
--
Michael
<<mock-autocache.patch>>
16 years, 10 months
[RFC] in progress: autocache patch
by Michael E Brown
Here is my current autocache patch for comments. I have two
features left to implement: 1) permissions on tarballs, and 2) ability
to select compressed/uncompressed tarballs.
Usage:
There are two added command line options. First is
"--autocache". You should be able to just add this command line option
to all mock invocations to automatically and transparently speed up
operations. It will automatically build cache the first time it is
invoked. It will automatically use the cache if it exists. It will
automatically expire the cache and rebuild it on a periodic basis. The
second option is "--rebuildcache". This option is for the rare occasions
when you would like to force a rebuild of the cache.
Theory:
The theory behind this patch is that it will automatically untar
the buildroot from a tarball, if the tarball exists. It will
automatically create the tarball if it does not exist (only when
--autocache is specified). The tarball has an expiration date, default
is 15 days. After the tarball is older than this, it will automatically
be rebuilt.
Test results:
Initial testing with FC5 yum repo mirror on local network and
squid proxy running on local machine resulted in a "init" of the build
root at 2:20. Using an already-cached build root takes this time down to
0:13.
--
Michael
<<mock-autocache.patch>>
16 years, 10 months
RE: Multiarch support for mock
by Michael E Brown
> -----Original Message-----
> From: fedora-buildsys-list-bounces(a)redhat.com
> [mailto:fedora-buildsys-list-bounces@redhat.com] On Behalf Of
> seth vidal
> Sent: Tuesday, May 16, 2006 1:27 PM
> To: Discussion of Fedora build system
> Subject: RE: Multiarch support for mock
>
> On Tue, 2006-05-16 at 11:08 -0500, Michael_E_Brown(a)Dell.com wrote:
> > Wouldn't a "BuildRequires: glibc.i686" work ok? Or am I missing
> > something?
>
> it would work to pull in the package in mock - b/c it would
> be passed directly to yum which understands that string.
> However, it won't work otherwise b/c rpm doesn't know about
> archs in Requires or BuildRequires.
SUSE build.rpm has a format that it uses for buildrequires, which I
thought was somewhat 'special' (short-bus type): it uses
specially-formatted comments in the spec file to embed build requires
lines. Does it make sense to add this as a workaround for this
special-case? Ie. Add a special "# mock-build-requires: glibc.i386" for
this RPM so that we do not break RPM, but still work with mock? This
probably isn't optimal, but a better solution eludes me atm.
--
Michael
16 years, 10 months
[PATCH - RFC] unify config parsing
by Michael E Brown
The recent changes to add default.cfg processing bumped the number of
lines in main(). The following patch unifies all config file parsing
into one small loop, removing about a dozen redundant lines of code. It
also removes an unnecessary variable, config_path and uses
options.configdir directly.
This is an RFC because it changes mock behaviour in the following way,
which requres discussion: The "-r" option is no longer required. You
will not get an error message for a missing "-r" option.
I think this might be useful for the case where somebody sets up their
'default.cfg' to be a full config.
Comments?
--
Michael
<<mock-cfgunify.patch>>
16 years, 10 months
RE: Multiarch support for mock
by Michael E Brown
> -----Original Message-----
> From: fedora-buildsys-list-bounces(a)redhat.com
> [mailto:fedora-buildsys-list-bounces@redhat.com] On Behalf Of
> seth vidal
> On Tue, 2006-05-16 at 11:33 +0200, Florian La Roche wrote:
> > On Tue, May 16, 2006 at 11:25:43AM +0200, Andreas Thienemann wrote:
> > > Hello,
> > >
> > > I noticed some problems with mock, when building tools such as
> > > valgrind, syslinux etc. on x86_64.
> > >
> > > The default mock config says to exclude i386 and similar packages.
> > >
> > > However, these programs depend on stubs-32.h from the i386
> > > glibc-devel package.
> > > The x86_64 glibc-devel only brings stubs-64.h, which makes the
> > > compilation of these tools stop, because stubs-32.h could
> not be found.
> > >
> > > What would be the correct way of fixing this?
> >
> > You should still keep the 32bit glibc rpm packages.
> >
> > I've had this running at some point with the following yum repo:
> > [devel-x86_64]
> > name=Fedora Core Development for x86_64
> > baseurl=file:/mnt/raid/fedora/development/x86_64
> > exclude=*-debuginfo-* [!g]*.i686 [!g]*.i386 g[!l]*.i386 glib.i386
> > glib2.i386
> >
> >
> > Not sure the above still works or if there are nicer ways
> now todo the
> > same within mock via other mechanisms. It should be something like
> > "exclude all *.i686/*.i386 packages, but still keep
> glibc*.i686 installed".
> >
> >
>
> So you're saying that in order to build 64bit packages we
> REQUIRE glibc*.i686?
>
> Are you serious? So there's no way to build x86_64 w/o i386
> first being built?
Wouldn't a "BuildRequires: glibc.i686" work ok? Or am I missing
something?
--
Michael
16 years, 10 months
