The speedups in building RPM's with "mock" from the EPEL packages for RHEL 6 are *profound*, especially if your environment is like mine and you have thousands of user id's. The issue seems to be the handling of "/var/log/lastlog" and similar files, which are otherwise quite large and take significant time to compress and uncompress when laying out new mock environments.
Karabhir, what are the odds of encouragng a switch to http://mirrors.kernel.org/fedora-epel/6/mock-1.1.8-1.el6.src.rpm, and backporting it to centos/5/5/extras ? It's working very well for me, and I think it would be a helpful improvement in RPM building for both the CentOs 5.6 and CentOS 6 efforts.
On 02/02/2011 01:01 PM, Nico Kadel-Garcia wrote:
Karabhir, what are the odds of encouragng a switch to http://mirrors.kernel.org/fedora-epel/6/mock-1.1.8-1.el6.src.rpm, and backporting it to centos/5/5/extras ? It's working very well for me, and I think it would be a helpful improvement in RPM building for both the CentOs 5.6 and CentOS 6 efforts.
Performance isnt really a problem we need to solve on the centos-buildsys side of things; however keeping things consistent is an issue. Because of the way things have changed in mock >= 0.8 I'm hesitant to change what we have in production for c3/4/5 since we know it works and it works across the entire distro tree from 4.0 to 5.6
So having the choice of the newer mock in epel isnt a bad thing as such, its just that the newer ver of mock isnt what is used internally within centos.
Having said that, for centos6 we will almost certainly end up with a newer mock, at the moment its 1.1.3 ( slightly modified and has a few patches from 1.1.3+ ); but once we are ready to release we can bring in a newer mock, do a few tests and have that in c6/extras.
- KB
On Wed, 2011-02-02 at 13:13 +0000, Karanbir Singh wrote:
On 02/02/2011 01:01 PM, Nico Kadel-Garcia wrote:
Karabhir, what are the odds of encouragng a switch to http://mirrors.kernel.org/fedora-epel/6/mock-1.1.8-1.el6.src.rpm, and backporting it to centos/5/5/extras ? It's working very well for me, and I think it would be a helpful improvement in RPM building for both the CentOs 5.6 and CentOS 6 efforts.
Hmmm: Nico
The requested URL /fedora-epel/6/mock-1.1.8-1.el6.src.rpm was not found on this server.
Maybe this:
http://mirrors.kernel.org/fedora-epel/6/SRPMS/mock-1.1.8-1.el6.src.rpm ?
How many SRPMS have you built with it? Do you use it under EL5?
John
On Fri, Feb 4, 2011 at 3:39 AM, JohnS jses27@gmail.com wrote:
On Wed, 2011-02-02 at 13:13 +0000, Karanbir Singh wrote:
On 02/02/2011 01:01 PM, Nico Kadel-Garcia wrote:
Karabhir, what are the odds of encouragng a switch to http://mirrors.kernel.org/fedora-epel/6/mock-1.1.8-1.el6.src.rpm, and backporting it to centos/5/5/extras ? It's working very well for me, and I think it would be a helpful improvement in RPM building for both the CentOs 5.6 and CentOS 6 efforts.
Hmmm: Nico
The requested URL /fedora-epel/6/mock-1.1.8-1.el6.src.rpm was not found on this server.
Maybe this:
http://mirrors.kernel.org/fedora-epel/6/SRPMS/mock-1.1.8-1.el6.src.rpm ?
How many SRPMS have you built with it? Do you use it under EL5?
John
I just found a nasty bug. Hold off on using that.
On Sat, Feb 5, 2011 at 9:17 AM, JohnS jses27@gmail.com wrote:
On Fri, 2011-02-04 at 17:44 -0500, Nico Kadel-Garcia wrote:
I just found a nasty bug. Hold off on using that.
Share it a bz #?
John
EPEL has a *nasty* habit of upgrading packages and not leaving the old one behind for reversion or regression testing. It makes for leaner distributions, but makes rolling back the upgrades more awkward, and tracing back where the error was introduced more awkard. It's just failing completely in my CentOS 5.5 instance, even with the the "epel-5-x86_64.cfg" configuration. The problem seems to have crept in with the most recent releases in epel-testing and the EPEL packages for RHEL 6.
I'm also laughing pretty hard that the EPEL versions of mock point to CentOS, not to the yum-rhn-plugin based access to RHEL repositories.
On Sat, 2011-02-05 at 15:49 -0500, Nico Kadel-Garcia wrote:
EPEL has a *nasty* habit of upgrading packages and not leaving the old one behind for reversion or regression testing. ......
All the more reason to introduce a 'local' repository where packages can accumulate and gracefully grow old. When I get time I must set up my Internet accessible repo for multiple machines.