Description of problem: The configuration as being used by /etc/mock/redhat-73-i386.cfg presumes buildsys-build*.rpm to be available on http://fedoraproject.org/buildgroups/rh73/i386 This does not apply. fedoraproject.org/buildgroups/rh73/i386 still lacks this file and presumes "groupinstall" style setup. Version-Release number of selected component (if applicable): mock-0.6.8-4.fc6 How reproducible: Always Steps to Reproduce: 1. mock --debug -r redhat-73-i386 init Actual results: ... DEBUG: yum: command /usr/sbin/mock-helper yum --installroot /var/lib/mock/redhat-73-i386/root install buildsys-build DEBUG: Executing /usr/sbin/mock-helper yum --installroot /var/lib/mock/redhat-73-i386/root install buildsys-build No Match for argument: buildsys-build ... Expected results: Function. Additional info: 2 ways to fix this: 1) Let fedoraproject.org/buildgroups/rh73/i386 provide buildsys-build 2) Add config_opts['chroot_setup_cmd'] = 'groupinstall build-base build-minimal build' to redhat-73-i386.cfg
Hrm, the right answer here might just be to remove the stock 7.3 config file. We aren't using a buildsysbuild anywhere anymore, and there is no interest in maintianing one. We provide a spec file in the mock package for a template to create your own for configs we don't ship with. I think its time to drop the 7.3 config. Clark?
(In reply to comment #1) > Hrm, the right answer here might just be to remove the stock 7.3 config file. > We aren't using a buildsysbuild anywhere anymore, But we do, because building for rh7 in mock is an easy escape to circumvent incompatiblities of binary rpms targetting older RH/Fedora distros and non-RH based distros (We currently build rpms for rh7, fc5 and fc6 - more distros would be beyond the scope of our resources) > and there is no interest in maintianing one. OK, then the next step for us would be to completely fork away from RH supplied rh7-mock-support files, and to package them on our own. This is not a biggy, as we already partially do this, and because fedoralegacy's death end of this year would make this step inevitable, anyway.
Who is the 'we' here? My use of 'we' was the Fedora project. So yeah, instead of forking I think its best if we just stop packaging the config file so that end users could supply their own without worry of package stompage.
(In reply to comment #3) > Who is the 'we' here? I was referring to RTEMS (www.rtems.com, www.rtems.org, www.oarcorp.com). We are building and distributing various GCC cross-toolchains, our users (Which don't necessarily run Fedora or RH-Linux) need. So far OAR had kept a rh7 machine around to build them. Recently. I persuaded them to building in mock, which had allowed OAR to retire this particular machine. c.f. ftp://ftp.rtems.org/pub/rtems/linux
So the real solution here is to provide an rhl7 buildsys-build rpm? Clark
I've discussed this with folks on the #fedora-devel channel and the consensus is we're not going to supply buildsys-build RPMS for RHL-*. The specfile for the buildsys-build rpm is included in the binary RPMs for mock, so all the elements of maintaining a private repo are there. If the OAR guys need help maintaining a private RHL73 repo for mock builds, I'm two doors down from them. Clark
(In reply to comment #6) > I've discussed this with folks on the #fedora-devel channel and the consensus is > we're not going to supply buildsys-build RPMS for RHL-*. I realize, mock is a RH/Fedora-centric/proprietary script lacking generality, which causes it to be not of much use outside of the Fedora buildsystem. So be it, your and RH's fault - I can not avoid forking away from official upstream and using a hacked up version because of this.