-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
All,
I hand-hacked this specfile together using the FC4 buildroots.xml as the starting point. Just wanted to put together a test to see how complicated it would be (it wasn't; witness the fact that I did it :). I've got a start on a small python script that will parse the current buildroots and generate spec files for the various configurations.
I built it like this: rpmbuild --define "_sourcedir $(PWD)" --define "_builddir $(PWD)/buildsys" --define "_srcrpmdir $(PWD)/buildsys" --define "_rpmdir $(PWD)/buildsys" -ba buildsys-minimal.spec
It generates a small binary RPM (and an SRPM) that contains one file, buildsys-minimal.spec and requires all the listed packages. I originally had BuildRequires and then changed to Requires, just because it's easy to query the resulting binary RPM for requires. I suspect to be totally correct we would need to go back to BuildRequires.
Anyway, that's what I thought Seth was talking about with his RPM idea. What do you think?
Clark
Summary: Dependency package for minimal buildroot Name: buildsys-minimal Version: fc5 Release: 1 License: GPL Group: Development/Build Tools Source0: buildsys-minimal.spec BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root Requires: bash Requires: glibc Requires: python Requires: createrepo Requires: rpm Requires: rpm-python Requires: initscripts Requires: chkconfig Requires: fedora-release #Requires: buildsys-macros Requires: coreutils Requires: findutils Requires: openssh-server Requires: which Requires: udev Requires: rpm-build Requires: make Requires: gcc Requires: tar Requires: gzip Requires: patch Requires: unzip Requires: bzip2 Requires: diffutils Requires: cpio Requires: elfutils Requires: intltool Requires: redhat-rpm-config Requires: gcc-c++ Requires: autoconf Requires: gettext Requires: automake Requires: gdb Requires: flex Requires: libtool Requires: strace Requires: bison Requires: binutils Requires: patchutils Requires: byacc Requires: diffstat Requires: perl-XML-Parser Requires: perl-XML-Dumper Requires: perl-XML-SAX Requires: ctags Requires: automake14 Requires: automake15 Requires: automake16 Requires: automake17 Requires: doxygen Requires: indent Requires: pkgconfig
%description
%prep rm -rf %{buildroot} mkdir -p %{buildroot}/var/lib/mock cp %{SOURCE0} %{buildroot}/var/lib/mock
%build
%install
%clean
%files %defattr(-,root,root,-) %doc /var/lib/mock/buildsys-minimal.spec
%changelog * Tue Apr 4 2006 Clark Williams williams@redhat.com - 1.0-1 - Initial build.
On Tue, 2006-04-04 at 14:26 -0500, Clark Williams wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
All,
I hand-hacked this specfile together using the FC4 buildroots.xml as the starting point. Just wanted to put together a test to see how complicated it would be (it wasn't; witness the fact that I did it :). I've got a start on a small python script that will parse the current buildroots and generate spec files for the various configurations.
I built it like this: rpmbuild --define "_sourcedir $(PWD)" --define "_builddir $(PWD)/buildsys" --define "_srcrpmdir $(PWD)/buildsys" --define "_rpmdir $(PWD)/buildsys" -ba buildsys-minimal.spec
It generates a small binary RPM (and an SRPM) that contains one file, buildsys-minimal.spec and requires all the listed packages. I originally had BuildRequires and then changed to Requires, just because it's easy to query the resulting binary RPM for requires. I suspect to be totally correct we would need to go back to BuildRequires.
Requires is definitely better b/c we're not building that package.
We'd just be yum --installroot=/some/place install buildsys-minimal
The req'ing in all those items.
Anyway, that's what I thought Seth was talking about with his RPM idea. What do you think?
#Requires: buildsys-macros
why comment this one out?
-sv
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
seth vidal wrote:
Anyway, that's what I thought Seth was talking about with his RPM idea. What do you think?
#Requires: buildsys-macros
why comment this one out?
Ah, busted... :)
I didn't have it or know where it came from, so I commented it out. I later found it on: http://fedoraproject.org/buildgroups/4/i386/buildsys-macros-4-2.fc4.noarch.r....
Is it a part of FC5 extras?
Clark
On Tue, 2006-04-04 at 16:15 -0500, Clark Williams wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
seth vidal wrote:
Anyway, that's what I thought Seth was talking about with his RPM idea. What do you think?
#Requires: buildsys-macros
why comment this one out?
Ah, busted... :)
I didn't have it or know where it came from, so I commented it out. I later found it on: http://fedoraproject.org/buildgroups/4/i386/buildsys-macros-4-2.fc4.noarch.r....
Is it a part of FC5 extras?
no - it's the thing that makes the %dist tag work.
-sv
On 4/4/06, Clark Williams williams@redhat.com wrote:
It generates a small binary RPM (and an SRPM) that contains one file, buildsys-minimal.spec and requires all the listed packages. I originally had BuildRequires and then changed to Requires, just because it's easy to query the resulting binary RPM for requires. I suspect to be totally correct we would need to go back to BuildRequires.
Anyway, that's what I thought Seth was talking about with his RPM idea. What do you think?
Looks right by me. Not sure it needs to include itself, but why not :) Requires is probably better than BuildRequires, as BuildRequires only means "packages needed to build this rpm" vs Requires' "packages needed to install this rpm", and I don't believe would would actually pull them in when installed.
-Chris
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Chris Weyl wrote:
On 4/4/06, Clark Williams williams@redhat.com wrote:
It generates a small binary RPM (and an SRPM) that contains one file, buildsys-minimal.spec and requires all the listed packages. I originally had BuildRequires and then changed to Requires, just because it's easy to query the resulting binary RPM for requires. I suspect to be totally correct we would need to go back to BuildRequires.
Anyway, that's what I thought Seth was talking about with his RPM idea. What do you think?
Looks right by me. Not sure it needs to include itself, but why not :) Requires is probably better than BuildRequires, as BuildRequires only means "packages needed to build this rpm" vs Requires' "packages needed to install this rpm", and I don't believe would would actually pull them in when installed.
Yeah, I see now that Requires is really what we want. Happy accident on my part :)
The only reason I put the spec file into the payload of the RPM was to be able to have something that indicates what the contents of the chroot will be (besides having to run 'rpm -qp --requires' on the binary package, that is). That and if you want to tweak it for some special purpose, you can just take the spec file, edit it and recreate the RPM.
The main reason I slapped this together was to get people to look at it and see if there are gaping holes in the idea of using an RPM to define the contents of various chroot configuration.
So far, no one has complained too loudly. It's early though...
Clark
williams@redhat.com (Clark Williams) writes:
Requires: openssh-server Requires: udev Requires: intltool Requires: autoconf Requires: gettext Requires: automake Requires: gdb Requires: flex Requires: libtool Requires: strace Requires: bison Requires: byacc Requires: diffstat Requires: perl-XML-Parser Requires: perl-XML-Dumper Requires: perl-XML-SAX Requires: ctags Requires: automake14 Requires: automake15 Requires: automake16 Requires: automake17 Requires: doxygen Requires: indent Requires: pkgconfig
For what are these Requires:? AFAIS, they are not part of the minimal buildroot defined at
http://fedoraproject.org/wiki/Packaging/Guidelines#head-4cadce5e79d38a63cad3...
and will hide packaging errors.
Enrico
Am Mittwoch, den 05.04.2006, 08:03 +0200 schrieb Enrico Scholz:
williams@redhat.com (Clark Williams) writes:
Requires: openssh-server Requires: udev Requires: intltool Requires: autoconf Requires: gettext Requires: automake Requires: gdb Requires: flex Requires: libtool Requires: strace Requires: bison Requires: byacc Requires: diffstat Requires: perl-XML-Parser Requires: perl-XML-Dumper Requires: perl-XML-SAX Requires: ctags Requires: automake14 Requires: automake15 Requires: automake16 Requires: automake17 Requires: doxygen Requires: indent Requires: pkgconfig
For what are these Requires:? AFAIS, they are not part of the minimal buildroot defined at
http://fedoraproject.org/wiki/Packaging/Guidelines#head-4cadce5e79d38a63cad3...
and will hide packaging errors.
Especially all the automake/autoconf stuff -- that shouldn't be needed normally (and lxo for example in IRC multiple time mentioned that running those in a RPM spec file is bad and should be avoided)
CU thl
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Enrico Scholz wrote:
For what are these Requires:? AFAIS, they are not part of the minimal buildroot defined at
http://fedoraproject.org/wiki/Packaging/Guidelines#head-4cadce5e79d38a63cad3...
and will hide packaging errors.
I wondered about those packages myself. What you saw in the specfile I sent to the list was just a mechanical translation of:
http://fedoraproject.org/buildgroups/4/i386/buildroots.xml
I wasn't really trying to apply any thought to the actual contents; I was just trying to prototype a "requires-only" RPM to see how hard it would be to generate/maintain. We can determine the contents later, now I'd like to make sure that the basic concept (rpm to define the contents of a chroot) is sound.
Clark
On Wed, 2006-04-05 at 09:08 -0500, Clark Williams wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Enrico Scholz wrote:
For what are these Requires:? AFAIS, they are not part of the minimal buildroot defined at
http://fedoraproject.org/wiki/Packaging/Guidelines#head-4cadce5e79d38a63cad3...
and will hide packaging errors.
I wondered about those packages myself. What you saw in the specfile I sent to the list was just a mechanical translation of:
http://fedoraproject.org/buildgroups/4/i386/buildroots.xmlI wasn't really trying to apply any thought to the actual contents; I was just trying to prototype a "requires-only" RPM to see how hard it would be to generate/maintain. We can determine the contents later, now I'd like to make sure that the basic concept (rpm to define the contents of a chroot) is sound.
There need to be 3 pkgs, probably:
buildsys-minimal buildsys-base buildsys-build
to match up to the 3 groups in that buildroots.xml file.
the contents of those groups can be re-discussed, if need be, but they were discussed once before, too, iirc. -sv
seth vidal wrote:
There need to be 3 pkgs, probably:
buildsys-minimal buildsys-base buildsys-build
to match up to the 3 groups in that buildroots.xml file.
the contents of those groups can be re-discussed, if need be, but they were discussed once before, too, iirc. -sv
So, buildsys-base is a common group of packages for every environment, buildsys-minimal adds to buildsys-base, and buildsys-build is what's needed to actually compile packages?
I believe I can modify the one specfile to generate three binary RPMS with appropriate names and package requirements. I'll see if I can get something out later today.
Clark
On Wed, 2006-04-05 at 10:34 -0500, Clark Williams wrote:
seth vidal wrote:
There need to be 3 pkgs, probably:
buildsys-minimal buildsys-base buildsys-build
to match up to the 3 groups in that buildroots.xml file.
the contents of those groups can be re-discussed, if need be, but they were discussed once before, too, iirc. -sv
So, buildsys-base is a common group of packages for every environment, buildsys-minimal adds to buildsys-base, and buildsys-build is what's needed to actually compile packages?
I believe I can modify the one specfile to generate three binary RPMS with appropriate names and package requirements. I'll see if I can get something out later today.
Works for me :)
-sv
On Tue, 2006-04-04 at 14:26 -0500, Clark Williams wrote:
All,
I hand-hacked this specfile together using the FC4 buildroots.xml as the starting point.
... stuff deleted ...
Summary: Dependency package for minimal buildroot Name: buildsys-minimal Version: fc5 Release: 1 License: GPL Group: Development/Build Tools Source0: buildsys-minimal.spec BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root
Two thoughts:
1) If you add the following line (to make the package a 'noarch'), you can use the same rpm no matter what arch we're creating a chroot for.
BuildArch: noarch
2) What's the purpose of installing the spec file in the chroot? I'm afraid I don't see the point. You'll never need it there. If you want to see what the requires were that got installed, you could do a "rpm - qRp buildsys-minimal.*.rpm"
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
David Smith wrote:
Summary: Dependency package for minimal buildroot Name: buildsys-minimal Version: fc5 Release: 1 License: GPL Group: Development/Build Tools Source0: buildsys-minimal.spec BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root
Two thoughts:
- If you add the following line (to make the package a 'noarch'), you
can use the same rpm no matter what arch we're creating a chroot for.
BuildArch: noarch
Done.
- What's the purpose of installing the spec file in the chroot? I'm
afraid I don't see the point. You'll never need it there. If you want to see what the requires were that got installed, you could do a "rpm - qRp buildsys-minimal.*.rpm"
Yeah, I had never created an RPM with an empty %files section, so I thought I needed something to go there. Silly me.
Attached is a new specfile that creates three binary RPMs: buildsys-base, buildsys-minimal, and buildsys-build. This one doesn't include the specfile as payload and is somewhat cleaned up.
Comments welcome.
Clark
# # Spec file for mock buildsys configuration # Summary: Dependency package for mock buildsys Name: buildsys-base Version: 1.0 Release: 1 License: GPL Group: Development/Build Tools BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root BuildArch: noarch Requires: coreutils Requires: findutils Requires: openssh-server Requires: which %description The base set of packages that all mock chroots start from
%package -n buildsys-minimal Summary: The minimal set of packages required on top of the base set for a mock chroot Group: Development/Build Tools Requires: bash Requires: glibc Requires: python Requires: createrepo Requires: rpm Requires: rpm-python Requires: initscripts Requires: chkconfig Requires: fedora-release Requires: buildsys-macros %description -n buildsys-minimal The minimal set of packages required on top of the base set for a mock chroot
%package -n buildsys-build Summary: The development tools required for a mock chroot build Group: Development/Build Tools Requires: perl-XML-SAX Requires: tar Requires: diffstat Requires: perl-XML-Parser Requires: perl-XML-Dumper Requires: udev Requires: gdb Requires: automake15 Requires: gcc Requires: intltool Requires: redhat-rpm-config Requires: automake17 Requires: pkgconfig Requires: gettext Requires: automake Requires: automake16 Requires: automake14 Requires: patchutils Requires: ctags Requires: gcc-c++ Requires: flex Requires: unzip Requires: bzip2 Requires: cpio Requires: byacc Requires: doxygen Requires: indent Requires: strace Requires: rpm-build Requires: elfutils Requires: patch Requires: bison Requires: diffutils Requires: gzip Requires: libtool Requires: autoconf Requires: make Requires: binutils %description -n buildsys-build The development tools required for a mock chroot build
%prep %build %install %clean
%files %defattr(-,root,root,-) %doc
%files -n buildsys-minimal %defattr(-,root,root,-) %doc
%files -n buildsys-build %defattr(-,root,root,-) %doc
On Wed, 2006-04-05 at 13:22 -0500, Clark Williams wrote:
- What's the purpose of installing the spec file in the chroot? I'm
afraid I don't see the point. You'll never need it there. If you want to see what the requires were that got installed, you could do a "rpm - qRp buildsys-minimal.*.rpm"
Yeah, I had never created an RPM with an empty %files section, so I thought I needed something to go there. Silly me.
Attached is a new specfile that creates three binary RPMs: buildsys-base, buildsys-minimal, and buildsys-build. This one doesn't include the specfile as payload and is somewhat cleaned up.
I'm just wondering... why does mock need three different sets of packages? I can see mach wants that because it's more than just a "build this package in a chroot for me" but in case of mock, wouldn't simply one set of minimal build requirements be enough?
/me must be missing something :)
Oh btw, Debian has had something similar for ages, only the meta-package is called "build-essential" there.
- Panu -
On Thu, 2006-04-06 at 00:23 +0300, Panu Matilainen wrote:
On Wed, 2006-04-05 at 13:22 -0500, Clark Williams wrote:
- What's the purpose of installing the spec file in the chroot? I'm
afraid I don't see the point. You'll never need it there. If you want to see what the requires were that got installed, you could do a "rpm - qRp buildsys-minimal.*.rpm"
Yeah, I had never created an RPM with an empty %files section, so I thought I needed something to go there. Silly me.
Attached is a new specfile that creates three binary RPMs: buildsys-base, buildsys-minimal, and buildsys-build. This one doesn't include the specfile as payload and is somewhat cleaned up.
I'm just wondering... why does mock need three different sets of packages? I can see mach wants that because it's more than just a "build this package in a chroot for me" but in case of mock, wouldn't simply one set of minimal build requirements be enough? /me must be missing something :)
actually, you're not missing anything. It's a leftover that I had forgotten and that we can, for all intents and purposes, abandon.
-sv
On Wed, 2006-04-05 at 13:22 -0500, Clark Williams wrote:
Attached is a new specfile that creates three binary RPMs: buildsys-base, buildsys-minimal, and buildsys-build. This one doesn't include the specfile as payload and is somewhat cleaned up.
1. okay - as panu was so kind to point out - we don't need 3 packages, really. - just one 2. I made the changes in mock cvs to have it install via a package of the above style - the config option is chroot_dep_package 3. what other patches need to go into mock before we release 0.5? - the one's I know about but wouldn't mind a reference to are: a. /dev/std* patch b. unpackaged-files failures
I'd like to get this part of the fixes for mock out of the way this week so we can go forth into the bright future without worrying about anything we broke :)
-sv
- okay - as panu was so kind to point out - we don't need 3 packages,
really. - just one 2. I made the changes in mock cvs to have it install via a package of the above style - the config option is chroot_dep_package 3. what other patches need to go into mock before we release 0.5?
- the one's I know about but wouldn't mind a reference to are: a. /dev/std* patch
1. the patch submitted to fix this is definitely in mock cvs 2. it is not entirely clear if this patch fixes the problem.
b. unpackaged-files failures
1. the patch to fix this is definitely in cvs 2. it is not entirely clear if this patch fixes the problem completely.
So here's what I think needs to happen:
1. Clark: could you modify your buildsys rpm so that it produces a single package named buildsys-build and could you check that spec file into mock cvs, since it will be handy there? 2. let's make a mock 0.5 release so we don't have any confusion over outstanding problems and test out that release before we deploy to the buildsys.
In order to take advantage of a new mock that does NOT use the groups stuff we will need: 1. the new buildsys-build package on the buildgroups location 2. all the config files updated and tested for the various platforms we are concerned with 3. some not-terribly-complex tests to make sure it is building correctly
Then once we deploy it to the builders we need to test it make sure it resolves: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=163576 and https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179852
Is there anything I'm missing or forgetting about doing for all of this?
Thanks, -sv
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
seth vidal wrote:
- okay - as panu was so kind to point out - we don't need 3 packages,
really. - just one 2. I made the changes in mock cvs to have it install via a package of the above style - the config option is chroot_dep_package 3. what other patches need to go into mock before we release 0.5?
- the one's I know about but wouldn't mind a reference to are: a. /dev/std* patch
1. the patch submitted to fix this is definitely in mock cvs 2. it is not entirely clear if this patch fixes the problem.
Well, it fixed it for me, but I wasn't the one that reported the problem.
- Clark: could you modify your buildsys rpm so that it produces a
single package named buildsys-build and could you check that spec file into mock cvs, since it will be handy there?
Sure.
In my original specfile I was playing kinda fast-n-loose, so I'd like to insure that the values we use for Version and Release make some sense. Should the Version field match our proposed mock version (i.e. 0.5)? Do we want to include the FC release in the release field (e.g. fc5-1) or something like that? Or should Release just be a number relative to the version string?
Clark
On Tue, 2006-04-11 at 10:09 -0500, Clark Williams wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
seth vidal wrote:
- okay - as panu was so kind to point out - we don't need 3 packages,
really. - just one 2. I made the changes in mock cvs to have it install via a package of the above style - the config option is chroot_dep_package 3. what other patches need to go into mock before we release 0.5?
- the one's I know about but wouldn't mind a reference to are: a. /dev/std* patch
1. the patch submitted to fix this is definitely in mock cvs 2. it is not entirely clear if this patch fixes the problem.Well, it fixed it for me, but I wasn't the one that reported the problem.
- Clark: could you modify your buildsys rpm so that it produces a
single package named buildsys-build and could you check that spec file into mock cvs, since it will be handy there?
Sure.
In my original specfile I was playing kinda fast-n-loose, so I'd like to insure that the values we use for Version and Release make some sense. Should the Version field match our proposed mock version (i.e. 0.5)? Do we want to include the FC release in the release field (e.g. fc5-1) or something like that? Or should Release just be a number relative to the version string?
since the packages it depends on will change based on the distro and release the chroot is for we should probably just make a version of it and have the per-distro changes be marked with a dist tag like packages in extras frequently are.
Then for other distros we can do the same:
fc3 fc4 fc5 fc6 el3 el4 el5 suse25 mdv64
etc etc
does that make sense to you?> -sv
On Apr 11, 2006, at 11:09 AM, Clark Williams wrote:
seth vidal wrote:
- what other patches need to go into mock before we release 0.5?
- the one's I know about but wouldn't mind a reference to are: a. /dev/std* patch
1. the patch submitted to fix this is definitely in mock cvs 2. it is not entirely clear if this patch fixes the problem.Well, it fixed it for me, but I wasn't the one that reported the problem.
Can you verify that you can build that package properly under plague (not just mock - it seems to work fine under mock, but not under plague + mock)? Like I reported here, https://bugzilla.redhat.com/ bugzilla/show_bug.cgi?id=179852#c18 I was still unable to build the package under plague using the patch provided, although it did bomb out with a new (and improved?) error message...
-Jeff
On Tue, 2006-04-11 at 04:28 -0400, seth vidal wrote:
- let's make a mock 0.5 release so we don't have any confusion over
outstanding problems and test out that release before we deploy to the buildsys.
Whenever the trigger gets pulled, push the new mock packages through the buildsys and I'll deploy them to the builders.
Dan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Dan Williams wrote:
On Tue, 2006-04-11 at 04:28 -0400, seth vidal wrote:
- let's make a mock 0.5 release so we don't have any confusion over
outstanding problems and test out that release before we deploy to the buildsys.
Whenever the trigger gets pulled, push the new mock packages through the buildsys and I'll deploy them to the builders.
Dan,
What version of mock on the buildsys now? Is it the 0.4.8* that contains the /dev/std{in,out,err}?
I'd kinda like to know if the std* change fixes the build problem before we move to 0.5 mock...
Clark
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
seth vidal wrote:
- Clark: could you modify your buildsys rpm so that it produces a
single package named buildsys-build and could you check that spec file into mock cvs, since it will be handy there?
Done. I checked in buildsys-build.spec, a Makefile target to build the buildsys-build RPM and a small change to the "chroot" command which insures /proc and /sys are mounted and unmounted around the command being run.
Clark
buildsys@lists.fedoraproject.org