From thomas at apestaart.org Tue Apr 4 09:12:03 2006 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Tue, 04 Apr 2006 11:12:03 +0200 Subject: mock buildroot definitions In-Reply-To: <1143558341.29933.13.camel@cutter> References: <1143558341.29933.13.camel@cutter> Message-ID: <1144141924.20837.98.camel@otto.amantes> On Tue, 2006-03-28 at 10:05 -0500, seth vidal wrote: > Hey, > So it was brought up a while ago that due to the changing nature of the > comps.xml format that we should not rely on it for the buildroot > installations in mock. The idea a while back was to just have a > 'buildroot' rpm that required all the stuff that would normally be in > the comps.xml group. Then we could just install that rpm and it pulls in > the rest of the buildroot components. I think it's wrong to pollute the rpm collection with an rpm that only ever is useful for one specific program. In the past people have already objected to more generally useful umbrella packages, and those at least served an end user purpose. This probably won't come as a surprise, but I think that a build tool's idea of what it needs to pull in should be maintained in the build tool, and not outside of it. It's not like it's hard work :) Thomas From skvidal at linux.duke.edu Tue Apr 4 11:38:53 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 04 Apr 2006 07:38:53 -0400 Subject: mock buildroot definitions In-Reply-To: <1144141924.20837.98.camel@otto.amantes> References: <1143558341.29933.13.camel@cutter> <1144141924.20837.98.camel@otto.amantes> Message-ID: <1144150734.8136.26.camel@cutter> On Tue, 2006-04-04 at 11:12 +0200, Thomas Vander Stichele wrote: > On Tue, 2006-03-28 at 10:05 -0500, seth vidal wrote: > > Hey, > > So it was brought up a while ago that due to the changing nature of the > > comps.xml format that we should not rely on it for the buildroot > > installations in mock. The idea a while back was to just have a > > 'buildroot' rpm that required all the stuff that would normally be in > > the comps.xml group. Then we could just install that rpm and it pulls in > > the rest of the buildroot components. > > I think it's wrong to pollute the rpm collection with an rpm that only > ever is useful for one specific program. In the past people have > already objected to more generally useful umbrella packages, and those > at least served an end user purpose. > > This probably won't come as a surprise, but I think that a build tool's > idea of what it needs to pull in should be maintained in the build tool, > and not outside of it. It's not like it's hard work :) it is if you want to be able to cleanly propagate changes to hundreds of users of the build tool. mock is used by extras developers to test builds on their own systems. If we change the build root contents we need to make sure that those changes are distributed out. -sv From williams at redhat.com Tue Apr 4 15:03:39 2006 From: williams at redhat.com (Clark Williams) Date: Tue, 04 Apr 2006 10:03:39 -0500 Subject: mock buildroot definitions In-Reply-To: <1144141924.20837.98.camel@otto.amantes> References: <1143558341.29933.13.camel@cutter> <1144141924.20837.98.camel@otto.amantes> Message-ID: <44328ACB.2030606@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thomas Vander Stichele wrote: >On Tue, 2006-03-28 at 10:05 -0500, seth vidal wrote: > >>Hey, >> So it was brought up a while ago that due to the changing nature of the >>comps.xml format that we should not rely on it for the buildroot >>installations in mock. The idea a while back was to just have a >>'buildroot' rpm that required all the stuff that would normally be in >>the comps.xml group. Then we could just install that rpm and it pulls in >>the rest of the buildroot components. > > >I think it's wrong to pollute the rpm collection with an rpm that only >ever is useful for one specific program. In the past people have >already objected to more generally useful umbrella packages, and those >at least served an end user purpose. I'm not sure I understand your objection. I don't believe you'd see these rpms in general circulation (I would guess they would be delivered as a component of the mock package, right Seth?). The only place they'd be installed is a chroot that is being managed by mock. The only purpose behind them would be to provide BuildDeps to tell rpm what needs to be installed in the chroot. If I understand the basic idea, the RPM would be the only thing mock/yum/rpm would be told to install, then the builddeps from the rpm would cause the chroot to be populated. > >This probably won't come as a surprise, but I think that a build tool's >idea of what it needs to pull in should be maintained in the build tool, >and not outside of it. It's not like it's hard work :) Why not just use a spec file as the format? While I know it's not a nicely formed, easily parsed format, it's well known and familiar to most of us. Yeah, I know that mock's "unit of operation" is a chroot configuration (as opposed to yum's unit of operation: rpms), but I'd rather not invent a new configuration file. I like the idea of centralizing the contents of a chroot configuration and a spec file seems as easy as anything else. One thing I like about the idea is that I could customize my chroot's by modifying one of the supplied specfiles. The mock package could manage two or three packages (buildsys-base, buildsys-max, buildsys-min) and if I wanted something in between I could grab one, change the name and modify the builddeps to my hearts content. Just my $0.02 worth. Clark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEMorKHyuj/+TTEp0RAsBdAJ9qyIwKWLlGbunJzcth1ubSdWi0eACfdN40 OFL2lScwDxqYaTlNAS4MzQQ= =YKjx -----END PGP SIGNATURE----- From cweyl at alumni.drew.edu Tue Apr 4 17:05:06 2006 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Tue, 4 Apr 2006 10:05:06 -0700 Subject: mock buildroot definitions In-Reply-To: <44328ACB.2030606@redhat.com> References: <1143558341.29933.13.camel@cutter> <1144141924.20837.98.camel@otto.amantes> <44328ACB.2030606@redhat.com> Message-ID: <7dd7ab490604041005n7e430e9fg7cf680e06530a5c5@mail.gmail.com> On 4/4/06, Clark Williams wrote: > I'm not sure I understand your objection. I don't believe you'd see > these rpms in general circulation (I would guess they would be > delivered as a component of the mock package, right Seth?). The only > place they'd be installed is a chroot that is being managed by mock. > The only purpose behind them would be to provide BuildDeps to tell rpm > what needs to be installed in the chroot. If I understand the basic > idea, the RPM would be the only thing mock/yum/rpm would be told to > install, then the builddeps from the rpm would cause the chroot to be > populated. Yah. I'd expect these rpms would live in the builders-only repo that currently holds the buildgroups definitions. I can't imagine they'd ever want to be in a more general use repos. Thinking about this too, the upgrade path is nice, as I don't believe there's anything that would require dropping buildgroups support as we go forward and implement this. -Chris From williams at redhat.com Tue Apr 4 19:26:45 2006 From: williams at redhat.com (Clark Williams) Date: Tue, 04 Apr 2006 14:26:45 -0500 Subject: example of buildsys rpm Message-ID: <4432C875.9020807@redhat.com> -----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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEMsh0Hyuj/+TTEp0RAqLxAKDeNQr71ObH68KB/8cUeDC/IwnTBACdEZWP zCVlr03vYsHKh5VBNzOwN7Q= =sdkS -----END PGP SIGNATURE----- -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: buildsys-minimal.spec URL: From skvidal at linux.duke.edu Tue Apr 4 21:02:47 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 04 Apr 2006 17:02:47 -0400 Subject: example of buildsys rpm In-Reply-To: <4432C875.9020807@redhat.com> References: <4432C875.9020807@redhat.com> Message-ID: <1144184567.11415.34.camel@cutter> 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 From williams at redhat.com Tue Apr 4 21:15:12 2006 From: williams at redhat.com (Clark Williams) Date: Tue, 04 Apr 2006 16:15:12 -0500 Subject: example of buildsys rpm In-Reply-To: <1144184567.11415.34.camel@cutter> References: <4432C875.9020807@redhat.com> <1144184567.11415.34.camel@cutter> Message-ID: <4432E1E0.2060408@redhat.com> -----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.rpm. Is it a part of FC5 extras? Clark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEMuHgHyuj/+TTEp0RAv9KAJ0QlNgAusEPlp6mrt7l6+IqjEGrBACfYse/ qxahHBnKE4/UftGtdCnBKNI= =Ys8R -----END PGP SIGNATURE----- From skvidal at linux.duke.edu Tue Apr 4 21:19:36 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 04 Apr 2006 17:19:36 -0400 Subject: example of buildsys rpm In-Reply-To: <4432E1E0.2060408@redhat.com> References: <4432C875.9020807@redhat.com> <1144184567.11415.34.camel@cutter> <4432E1E0.2060408@redhat.com> Message-ID: <1144185577.11415.43.camel@cutter> 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.rpm. > > > Is it a part of FC5 extras? > no - it's the thing that makes the %dist tag work. -sv From cweyl at alumni.drew.edu Tue Apr 4 22:05:17 2006 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Tue, 4 Apr 2006 15:05:17 -0700 Subject: example of buildsys rpm In-Reply-To: <4432C875.9020807@redhat.com> References: <4432C875.9020807@redhat.com> Message-ID: <7dd7ab490604041505k3210f07el300512038551c277@mail.gmail.com> On 4/4/06, Clark Williams 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 From williams at redhat.com Tue Apr 4 22:54:12 2006 From: williams at redhat.com (Clark Williams) Date: Tue, 04 Apr 2006 17:54:12 -0500 Subject: example of buildsys rpm In-Reply-To: <7dd7ab490604041505k3210f07el300512038551c277@mail.gmail.com> References: <4432C875.9020807@redhat.com> <7dd7ab490604041505k3210f07el300512038551c277@mail.gmail.com> Message-ID: <4432F914.9050600@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chris Weyl wrote: >On 4/4/06, Clark Williams 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEMvkUHyuj/+TTEp0RAsspAJ93o+Mlk5RW9HPg6b/Z4wB8tZJbngCfRuPN uoufXGcsozHUTDmZkpQXhh8= =DVmq -----END PGP SIGNATURE----- From enrico.scholz at informatik.tu-chemnitz.de Wed Apr 5 06:03:46 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 05 Apr 2006 08:03:46 +0200 Subject: example of buildsys rpm In-Reply-To: <4432C875.9020807@redhat.com> (Clark Williams's message of "Tue, 04 Apr 2006 14:26:45 -0500") References: <4432C875.9020807@redhat.com> Message-ID: <87vetoo8xp.fsf@kosh.bigo.ensc.de> williams at 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-4cadce5e79d38a63cad3941de1dadc9d25d67d30 and will hide packaging errors. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 482 bytes Desc: not available URL: From fedora at leemhuis.info Wed Apr 5 06:25:00 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 05 Apr 2006 08:25:00 +0200 Subject: example of buildsys rpm In-Reply-To: <87vetoo8xp.fsf@kosh.bigo.ensc.de> References: <4432C875.9020807@redhat.com> <87vetoo8xp.fsf@kosh.bigo.ensc.de> Message-ID: <1144218300.13854.23.camel@thl.ct.heise.de> Am Mittwoch, den 05.04.2006, 08:03 +0200 schrieb Enrico Scholz: > williams at 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-4cadce5e79d38a63cad3941de1dadc9d25d67d30 > > 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 From williams at redhat.com Wed Apr 5 14:08:44 2006 From: williams at redhat.com (Clark Williams) Date: Wed, 05 Apr 2006 09:08:44 -0500 Subject: example of buildsys rpm In-Reply-To: <87vetoo8xp.fsf@kosh.bigo.ensc.de> References: <4432C875.9020807@redhat.com> <87vetoo8xp.fsf@kosh.bigo.ensc.de> Message-ID: <4433CF6C.9050601@redhat.com> -----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-4cadce5e79d38a63cad3941de1dadc9d25d67d30 > >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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEM89rHyuj/+TTEp0RAjVlAKCmhUi5DVoc636NndaEGvsjrTEzNACgs7PK 1x+8q91j46zMKZcwdhcpvE8= =os7h -----END PGP SIGNATURE----- From skvidal at linux.duke.edu Wed Apr 5 14:50:25 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 05 Apr 2006 10:50:25 -0400 Subject: example of buildsys rpm In-Reply-To: <4433CF6C.9050601@redhat.com> References: <4432C875.9020807@redhat.com> <87vetoo8xp.fsf@kosh.bigo.ensc.de> <4433CF6C.9050601@redhat.com> Message-ID: <1144248625.15925.48.camel@cutter> 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-4cadce5e79d38a63cad3941de1dadc9d25d67d30 > > > >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. 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 From williams at redhat.com Wed Apr 5 15:34:01 2006 From: williams at redhat.com (Clark Williams) Date: Wed, 05 Apr 2006 10:34:01 -0500 Subject: example of buildsys rpm In-Reply-To: <1144248625.15925.48.camel@cutter> References: <4432C875.9020807@redhat.com> <87vetoo8xp.fsf@kosh.bigo.ensc.de> <4433CF6C.9050601@redhat.com> <1144248625.15925.48.camel@cutter> Message-ID: <4433E369.2080300@redhat.com> 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 From skvidal at linux.duke.edu Wed Apr 5 15:35:39 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 05 Apr 2006 11:35:39 -0400 Subject: example of buildsys rpm In-Reply-To: <4433E369.2080300@redhat.com> References: <4432C875.9020807@redhat.com> <87vetoo8xp.fsf@kosh.bigo.ensc.de> <4433CF6C.9050601@redhat.com> <1144248625.15925.48.camel@cutter> <4433E369.2080300@redhat.com> Message-ID: <1144251339.15925.61.camel@cutter> 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 From dsmith at redhat.com Wed Apr 5 16:44:31 2006 From: dsmith at redhat.com (David Smith) Date: Wed, 05 Apr 2006 11:44:31 -0500 Subject: example of buildsys rpm In-Reply-To: <4432C875.9020807@redhat.com> References: <4432C875.9020807@redhat.com> Message-ID: <1144255471.22383.76.camel@dhcp-2.hsv.redhat.com> 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" -- David Smith dsmith at redhat.com Red Hat, Inc. http://www.redhat.com 256.217.0141 (direct) 256.837.0057 (fax) From williams at redhat.com Wed Apr 5 18:22:11 2006 From: williams at redhat.com (Clark Williams) Date: Wed, 05 Apr 2006 13:22:11 -0500 Subject: example of buildsys rpm In-Reply-To: <1144255471.22383.76.camel@dhcp-2.hsv.redhat.com> References: <4432C875.9020807@redhat.com> <1144255471.22383.76.camel@dhcp-2.hsv.redhat.com> Message-ID: <44340AD3.3060507@redhat.com> -----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: > >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 Done. > >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" > 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFENArTHyuj/+TTEp0RAvi6AKDA2TutiDkYV4imzinSm5+uD6vpLgCgon3F cgne8JhXzn8E3P57L3YmTM4= =z90o -----END PGP SIGNATURE----- -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: buildsys.spec URL: From pmatilai at laiskiainen.org Wed Apr 5 21:23:22 2006 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Thu, 06 Apr 2006 00:23:22 +0300 Subject: example of buildsys rpm In-Reply-To: <44340AD3.3060507@redhat.com> References: <4432C875.9020807@redhat.com> <1144255471.22383.76.camel@dhcp-2.hsv.redhat.com> <44340AD3.3060507@redhat.com> Message-ID: <1144272202.15501.13.camel@dhcppc0> On Wed, 2006-04-05 at 13:22 -0500, Clark Williams wrote: > >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" > > > 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 - From skvidal at linux.duke.edu Tue Apr 11 07:55:49 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 11 Apr 2006 03:55:49 -0400 Subject: example of buildsys rpm In-Reply-To: <1144272202.15501.13.camel@dhcppc0> References: <4432C875.9020807@redhat.com> <1144255471.22383.76.camel@dhcp-2.hsv.redhat.com> <44340AD3.3060507@redhat.com> <1144272202.15501.13.camel@dhcppc0> Message-ID: <1144742149.22430.87.camel@cutter> On Thu, 2006-04-06 at 00:23 +0300, Panu Matilainen wrote: > On Wed, 2006-04-05 at 13:22 -0500, Clark Williams wrote: > > > >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" > > > > > 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 From skvidal at linux.duke.edu Tue Apr 11 08:07:34 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 11 Apr 2006 04:07:34 -0400 Subject: example of buildsys rpm In-Reply-To: <44340AD3.3060507@redhat.com> References: <4432C875.9020807@redhat.com> <1144255471.22383.76.camel@dhcp-2.hsv.redhat.com> <44340AD3.3060507@redhat.com> Message-ID: <1144742854.22430.92.camel@cutter> 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 From skvidal at linux.duke.edu Tue Apr 11 08:28:31 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 11 Apr 2006 04:28:31 -0400 Subject: example of buildsys rpm In-Reply-To: <1144742854.22430.92.camel@cutter> References: <4432C875.9020807@redhat.com> <1144255471.22383.76.camel@dhcp-2.hsv.redhat.com> <44340AD3.3060507@redhat.com> <1144742854.22430.92.camel@cutter> Message-ID: <1144744111.22430.100.camel@cutter> > 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 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 From williams at redhat.com Tue Apr 11 15:09:09 2006 From: williams at redhat.com (Clark Williams) Date: Tue, 11 Apr 2006 10:09:09 -0500 Subject: example of buildsys rpm In-Reply-To: <1144744111.22430.100.camel@cutter> References: <4432C875.9020807@redhat.com> <1144255471.22383.76.camel@dhcp-2.hsv.redhat.com> <44340AD3.3060507@redhat.com> <1144742854.22430.92.camel@cutter> <1144744111.22430.100.camel@cutter> Message-ID: <443BC695.9050804@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 seth vidal wrote: >> 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 > > 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. > 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? 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEO8aUHyuj/+TTEp0RAghsAJ9RhsSQN2DU7tDNOHAVEL+I376MLACgu3SI jwt3MGKrZb6lzvJuzcbWnaM= =UNGV -----END PGP SIGNATURE----- From skvidal at linux.duke.edu Tue Apr 11 15:29:54 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 11 Apr 2006 11:29:54 -0400 Subject: example of buildsys rpm In-Reply-To: <443BC695.9050804@redhat.com> References: <4432C875.9020807@redhat.com> <1144255471.22383.76.camel@dhcp-2.hsv.redhat.com> <44340AD3.3060507@redhat.com> <1144742854.22430.92.camel@cutter> <1144744111.22430.100.camel@cutter> <443BC695.9050804@redhat.com> Message-ID: <1144769394.27456.4.camel@cutter> On Tue, 2006-04-11 at 10:09 -0500, Clark Williams wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > seth vidal wrote: > >> 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 > > > > 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. > > > 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? > 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 From sheltren at cs.ucsb.edu Tue Apr 11 18:51:30 2006 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Tue, 11 Apr 2006 14:51:30 -0400 Subject: example of buildsys rpm In-Reply-To: <443BC695.9050804@redhat.com> References: <4432C875.9020807@redhat.com> <1144255471.22383.76.camel@dhcp-2.hsv.redhat.com> <44340AD3.3060507@redhat.com> <1144742854.22430.92.camel@cutter> <1144744111.22430.100.camel@cutter> <443BC695.9050804@redhat.com> Message-ID: On Apr 11, 2006, at 11:09 AM, Clark Williams wrote: > > seth vidal wrote: >>> 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. > 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 From dcbw at redhat.com Tue Apr 11 20:56:38 2006 From: dcbw at redhat.com (Dan Williams) Date: Tue, 11 Apr 2006 16:56:38 -0400 Subject: example of buildsys rpm In-Reply-To: <1144744111.22430.100.camel@cutter> References: <4432C875.9020807@redhat.com> <1144255471.22383.76.camel@dhcp-2.hsv.redhat.com> <44340AD3.3060507@redhat.com> <1144742854.22430.92.camel@cutter> <1144744111.22430.100.camel@cutter> Message-ID: <1144788998.3079.6.camel@localhost.localdomain> On Tue, 2006-04-11 at 04:28 -0400, seth vidal wrote: > 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. Whenever the trigger gets pulled, push the new mock packages through the buildsys and I'll deploy them to the builders. Dan From williams at redhat.com Wed Apr 12 14:26:50 2006 From: williams at redhat.com (Clark Williams) Date: Wed, 12 Apr 2006 09:26:50 -0500 Subject: example of buildsys rpm In-Reply-To: <1144744111.22430.100.camel@cutter> References: <4432C875.9020807@redhat.com> <1144255471.22383.76.camel@dhcp-2.hsv.redhat.com> <44340AD3.3060507@redhat.com> <1144742854.22430.92.camel@cutter> <1144744111.22430.100.camel@cutter> Message-ID: <443D0E2A.7060103@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 seth vidal wrote: > > 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? 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEPQ4qHyuj/+TTEp0RAmrRAJ9Ful2I50qtc03l1qdAzrOOAGeIfwCgsjk4 42Ixt3vDg1DFxDUbzugNOfo= =AHat -----END PGP SIGNATURE----- From williams at redhat.com Thu Apr 13 21:32:22 2006 From: williams at redhat.com (Clark Williams) Date: Thu, 13 Apr 2006 16:32:22 -0500 Subject: example of buildsys rpm In-Reply-To: <1144788998.3079.6.camel@localhost.localdomain> References: <4432C875.9020807@redhat.com> <1144255471.22383.76.camel@dhcp-2.hsv.redhat.com> <44340AD3.3060507@redhat.com> <1144742854.22430.92.camel@cutter> <1144744111.22430.100.camel@cutter> <1144788998.3079.6.camel@localhost.localdomain> Message-ID: <443EC366.8030606@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dan Williams wrote: > On Tue, 2006-04-11 at 04:28 -0400, seth vidal wrote: >> 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. > > 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 SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEPsNmHyuj/+TTEp0RAk8vAKDAY1NoNLZ4I4EFBLVvr4RcgDxWDACg2+zY l+aw23GMp2RBbPCe0IeSvfM= =Ruk+ -----END PGP SIGNATURE-----