All, Mock 0.8.9 is sitting in the upstream git repository. I have tested this version on RHEL5, and it appears to work satisfactorily there. I have fixed the last remaining issue that I have seen on RHEL.
There are a few config file changes, as well as a couple differences in command line behaviour from previous releases, detailed in my release announcement to fedora-buildsys-list [1].
What are people's thoughts on upgrading the EPEL5 version of mock to 0.8.9? I would like to upgrade EPEL5 mock to 0.8.9.
Here are the benefits:
Bugfixes: -- There are several outstanding bugs in the existing version of mock on RHEL, including one bug that can result in removal of /dev/ on the host in some circumstances. These are all fixed in 0.8.x.
Speed: -- root cache (formerly called autocache) are much smaller -- yum cache means that you can speed up yum operations without setting up local mirror or squid -- ccache integration -- faster builds
All of the caching improvements result in a pretty significant build-time reduction, especially for people who use mock on a regular basis.
Logging: -- now uses native pythong logging module, for more configurable logging options.
Administration: -- cleanup-after set by default, keeps old mock chroots from accumulating.
New commands: -- mock install and mock installdeps allow easier use of chroot for testing situations.
Easier maintenance: -- mock-helper is now gone, and everything happens in mock.py, making coding of new extensions much easier. There is a setuid-wrapper which elevates permissions before calling mock.py.
And the drawbacks:
-- small change in commandline behaviour: 'rebuild' command used to be implied/option, is now required.
-- method for adding .rpmmacros in the config file has changed over the old version.
-- Michael
[1] https://www.redhat.com/archives/fedora-buildsys-list/2007-October/msg00029.h...
On Tue, Nov 20, 2007 at 01:53:14PM -0600, Michael E Brown wrote:
And the drawbacks:
-- small change in commandline behaviour: 'rebuild' command used to be implied/option, is now required.
-- method for adding .rpmmacros in the config file has changed over the old version.
To me it looks like changes that are too much for a change in EPEL.
-- Pat
On Tue, Nov 20, 2007 at 09:13:24PM +0100, Patrice Dumas wrote:
On Tue, Nov 20, 2007 at 01:53:14PM -0600, Michael E Brown wrote:
And the drawbacks:
-- small change in commandline behaviour: 'rebuild' command used to be implied/option, is now required.
Actually, I just committed a patch to restore backwards-compatibility for this. This should remove this part as a stumbling block.
-- method for adding .rpmmacros in the config file has changed over the old version.
But this still remains. Not sure that a huge number of people use this feature, though.
To me it looks like changes that are too much for a change in EPEL.
Does this change any opinions? -- Michael
On Tue, Nov 20, 2007 at 02:49:01PM -0600, Michael E Brown wrote:
On Tue, Nov 20, 2007 at 09:13:24PM +0100, Patrice Dumas wrote:
On Tue, Nov 20, 2007 at 01:53:14PM -0600, Michael E Brown wrote:
And the drawbacks:
-- small change in commandline behaviour: 'rebuild' command used to be implied/option, is now required.
Actually, I just committed a patch to restore backwards-compatibility for this. This should remove this part as a stumbling block.
-- method for adding .rpmmacros in the config file has changed over the old version.
But this still remains. Not sure that a huge number of people use this feature, though.
If it is really the case, then no real problem. But how can you know?
But why not have just fixed the nasty bug only and leave the old mock?
-- Pat
On Tue, Nov 20, 2007 at 09:53:08PM +0100, Patrice Dumas wrote:
On Tue, Nov 20, 2007 at 02:49:01PM -0600, Michael E Brown wrote:
On Tue, Nov 20, 2007 at 09:13:24PM +0100, Patrice Dumas wrote:
On Tue, Nov 20, 2007 at 01:53:14PM -0600, Michael E Brown wrote:
And the drawbacks:
-- small change in commandline behaviour: 'rebuild' command used to be implied/option, is now required.
Actually, I just committed a patch to restore backwards-compatibility for this. This should remove this part as a stumbling block.
-- method for adding .rpmmacros in the config file has changed over the old version.
But this still remains. Not sure that a huge number of people use this feature, though.
If it is really the case, then no real problem. But how can you know?
Because the config format changed in Fedora and all of 3 people emailed me about it.
But why not have just fixed the nasty bug only and leave the old mock?
Mock in EPEL5 is 0.7.2. I have an *experimental* 0.7.7 patchset that has been verified to *not* fix the problem. The change from 0.7.2 to 0.7.7+patch to fix this is, in itself, a pretty large jump with several new features.
I'd rather not have to support the old branch, as it *truly* is a pain in the neck to maintain due to the mock-helper/mock.py split. -- Michael
On Nov 20, 2007 2:02 PM, Michael E Brown Michael_E_Brown@dell.com wrote:
On Tue, Nov 20, 2007 at 09:53:08PM +0100, Patrice Dumas wrote:
On Tue, Nov 20, 2007 at 02:49:01PM -0600, Michael E Brown wrote:
On Tue, Nov 20, 2007 at 09:13:24PM +0100, Patrice Dumas wrote:
On Tue, Nov 20, 2007 at 01:53:14PM -0600, Michael E Brown wrote:
Ok I am going to ask the harder question :). How does this affect RHEL-4 and such?
On Tue, Nov 20, 2007 at 02:05:46PM -0700, Stephen John Smoogen wrote:
Ok I am going to ask the harder question :). How does this affect RHEL-4 and such?
Does not affect RHEL4. I dont intend to upgrade mock in RHEL4 at this time, as I dont have a box to test this out on. Nor do I think it worth the effort to do so, as I doubt there are any users (or at least *very* few, if any.)
Based on my own cursory look at it, I believe that it would be possible for latest mock in git to run on RHEL4, but I dont see a point in upgrading there.
You can still use mock on any other system to build RPMS for RHEL4, as mock still distributes EL4 chroot configs. For example, from a Fedora-7 or Fedora-8 system, you can:
mock -r fedora-4-i386-epel rebuild my-super-duper.src.rpm
As a matter of fact, I actually use mock to compile lots of EL4 stuff on a regular basis. -- Michael
On 11/20/2007 11:20 PM, Michael E Brown wrote:
On Tue, Nov 20, 2007 at 02:05:46PM -0700, Stephen John Smoogen wrote:
Ok I am going to ask the harder question :). How does this affect RHEL-4 and such?
Does not affect RHEL4. I dont intend to upgrade mock in RHEL4 at this time, as I dont have a box to test this out on. Nor do I think it worth the effort to do so, as I doubt there are any users (or at least *very* few, if any.)
I have to contradict you here. To my knowledge Centos 4 is quite popular and even though lots of people have switched their devel boxes to C5 or Fedora, those still using C4 need love, too. To tell the truth the only reasons I've switched my workstation (which I also use as devel box now) to C5 and later to Fedora were - I could not obtain a decent application for C4 to manage my IPod nano - gaim (aka pidgin) became very difficult to compile due to BRs for versions of libraries not available in C4
On Tue, Nov 20, 2007 at 11:29:29PM +0200, Manuel Wolfshant wrote:
On 11/20/2007 11:20 PM, Michael E Brown wrote:
On Tue, Nov 20, 2007 at 02:05:46PM -0700, Stephen John Smoogen wrote:
Ok I am going to ask the harder question :). How does this affect RHEL-4 and such?
Does not affect RHEL4. I dont intend to upgrade mock in RHEL4 at this time, as I dont have a box to test this out on. Nor do I think it worth the effort to do so, as I doubt there are any users (or at least *very* few, if any.)
I have to contradict you here. To my knowledge Centos 4 is quite popular and even though lots of people have switched their devel boxes to C5 or Fedora, those still using C4 need love, too.
Yes, I know Centos 4 and RHEL4 are popular. My point was that I didnt think that many people actually ran mock on them. I've gotten very little in the way of feedback from people running mock on EL4. The vast majority of people (that I know about) running mock do so on Fedora-<recent>, or RHEL5.
As always, there are a very few people who might actually be running mock there, I just havent heard from them.
If there is a large contingent of people running mock on EL-4, I would be happy to update mock on EL-4 to latest if there is A) demand, and B) somebody who is willing to test and (possibly) submit patches if there are issues. -- Michael
Michael E Brown wrote:
On Tue, Nov 20, 2007 at 11:29:29PM +0200, Manuel Wolfshant wrote:
On 11/20/2007 11:20 PM, Michael E Brown wrote:
On Tue, Nov 20, 2007 at 02:05:46PM -0700, Stephen John Smoogen wrote:
Ok I am going to ask the harder question :). How does this affect RHEL-4 and such?
Does not affect RHEL4. I dont intend to upgrade mock in RHEL4 at this time, as I dont have a box to test this out on. Nor do I think it worth the effort to do so, as I doubt there are any users (or at least *very* few, if any.)
I have to contradict you here. To my knowledge Centos 4 is quite popular and even though lots of people have switched their devel boxes to C5 or Fedora, those still using C4 need love, too.
Yes, I know Centos 4 and RHEL4 are popular. My point was that I didnt think that many people actually ran mock on them. I've gotten very little in the way of feedback from people running mock on EL4. The vast majority of people (that I know about) running mock do so on Fedora-<recent>, or RHEL5.
As always, there are a very few people who might actually be running mock there, I just havent heard from them.
I tried it - I had to hunt through the epel testing repo to find a yum/mock that would actually work on rhel4. However, if I can happily use fedora to build el4 packages with mock, then I would rather do that than actually have to run el4 just to build packages.
So with mock 0.8.x, I can build el4 and el5 packages on fedora?
If there is a large contingent of people running mock on EL-4, I would be happy to update mock on EL-4 to latest if there is A) demand, and B) somebody who is willing to test and (possibly) submit patches if there are issues. -- Michael
epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
On Tue, Nov 20, 2007 at 02:44:39PM -0700, Rich Megginson wrote:
Yes, I know Centos 4 and RHEL4 are popular. My point was that I didnt think that many people actually ran mock on them. I've gotten very little in the way of feedback from people running mock on EL4. The vast majority of people (that I know about) running mock do so on Fedora-<recent>, or RHEL5.
As always, there are a very few people who might actually be running mock there, I just havent heard from them.
I tried it - I had to hunt through the epel testing repo to find a yum/mock that would actually work on rhel4. However, if I can happily use fedora to build el4 packages with mock, then I would rather do that than actually have to run el4 just to build packages.
So with mock 0.8.x, I can build el4 and el5 packages on fedora?
Absolutely. I do it *all the time*, as I distribute several packages for EL4/5 from the dell repository (http://linux.dell.com/repo/software), and mock is what I use to compile them.
I maintain mock very much because it is a dogfood thing for me. :) -- Michael
On 11/20/2007 11:42 PM, Michael E Brown wrote:
If there is a large contingent of people running mock on EL-4, I would be happy to update mock on EL-4 to latest if there is A) demand, and B) somebody who is willing to test and (possibly) submit patches if there are issues.
I do not know how many people run mock in EL-4 / Centos 4, but I will be more than happy to help you testing. Maybe I also learn a bit of python with this occasion...
On Tue, Nov 20, 2007 at 11:45:12PM +0200, Manuel Wolfshant wrote:
On 11/20/2007 11:42 PM, Michael E Brown wrote:
If there is a large contingent of people running mock on EL-4, I would be happy to update mock on EL-4 to latest if there is A) demand, and B) somebody who is willing to test and (possibly) submit patches if there are issues.
I do not know how many people run mock in EL-4 / Centos 4, but I will be more than happy to help you testing. Maybe I also learn a bit of python with this occasion...
So, so save you a bit of work, I went ahead and looked into this.
There is only one major problem with running mock 0.8.x on EL4, and that is decorators. I use the new decorator syntax to instrument most functions for logging and that decorator syntax is not available on python 2.3 in EL4.
There is a way to modify the code to keep the functionality of the decorators and still have backwards compatibility, but it isnt too pretty. (Not that, bad, either...).
If you want to send me a patch, I would accept it, as long as it is sane. -- Michael
On Nov 20, 2007 3:50 PM, Michael E Brown Michael_E_Brown@dell.com wrote:
On Tue, Nov 20, 2007 at 11:45:12PM +0200, Manuel Wolfshant wrote:
On 11/20/2007 11:42 PM, Michael E Brown wrote:
If there is a large contingent of people running mock on EL-4, I would be happy to update mock on EL-4 to latest if there is A) demand, and B) somebody who is willing to test and (possibly) submit patches if there are issues.
I do not know how many people run mock in EL-4 / Centos 4, but I will be more than happy to help you testing. Maybe I also learn a bit of python with this occasion...
So, so save you a bit of work, I went ahead and looked into this.
There is only one major problem with running mock 0.8.x on EL4, and that is decorators. I use the new decorator syntax to instrument most functions for logging and that decorator syntax is not available on python 2.3 in EL4.
There is a way to modify the code to keep the functionality of the decorators and still have backwards compatibility, but it isnt too pretty. (Not that, bad, either...).
I will look at it over Xmas break.. that will be my primary python hacking time.. I need to try and get a couple of things working with EL-3/4 that will need it.
If you want to send me a patch, I would accept it, as long as it is sane. -- Michael
epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
On Nov 20, 2007 2:29 PM, Manuel Wolfshant wolfy@nobugconsulting.ro wrote:
On 11/20/2007 11:20 PM, Michael E Brown wrote:
On Tue, Nov 20, 2007 at 02:05:46PM -0700, Stephen John Smoogen wrote:
Ok I am going to ask the harder question :). How does this affect RHEL-4 and such?
Does not affect RHEL4. I dont intend to upgrade mock in RHEL4 at this time, as I dont have a box to test this out on. Nor do I think it worth the effort to do so, as I doubt there are any users (or at least *very* few, if any.)
I have to contradict you here. To my knowledge Centos 4 is quite popular and even though lots of people have switched their devel boxes to C5 or Fedora, those still using C4 need love, too.
From what I can tell with 3 sites, the numbers are the following:
60%+ EL-3 30%+ EL-4 5% + EL-5 5% other.
The EL-3 is going down and EL-4/5 are going up... 5 with new systems and 4 with 3 systems that have software that is now tested for them. The big thing with Enterprise systems is that they are very slow to make changes. For one government lab, EL-4 is just reaching what they consider stable.. 5 will be after a couple of dot releases so that they know if its going to have big changes like EL-4 did early on.
The EL-3 still has new systems coming up on them. Mostly because it is very stable and they want all the mail-servers running the same OS until they move the next set of hardware/software fixes which will probably go to 4. And a whole large project which uses some of the same software is going on the same cycle but needs stuff that they get from EL-4 and compile to 3.
On 11/20/2007 11:44 PM, Stephen John Smoogen wrote:
On Nov 20, 2007 2:29 PM, Manuel Wolfshant wolfy@nobugconsulting.ro wrote:
On 11/20/2007 11:20 PM, Michael E Brown wrote:
On Tue, Nov 20, 2007 at 02:05:46PM -0700, Stephen John Smoogen wrote:
Ok I am going to ask the harder question :). How does this affect RHEL-4 and such?
Does not affect RHEL4. I dont intend to upgrade mock in RHEL4 at this time, as I dont have a box to test this out on. Nor do I think it worth the effort to do so, as I doubt there are any users (or at least *very* few, if any.)
I have to contradict you here. To my knowledge Centos 4 is quite popular and even though lots of people have switched their devel boxes to C5 or Fedora, those still using C4 need love, too.
From what I can tell with 3 sites, the numbers are the following:
60%+ EL-3 30%+ EL-4 5% + EL-5 5% other.
Stephen, please note that we are not simply speaking about machines _running_ a specific distro but about machines running a distro _and_also_ doing development. As Michael has pointed out, one can very well do development on one distro (i.e. run mock on a Fedora box for instance) and test the compiled stuff on EL-3 / EL-4 / EL-5.
BTW, I think that it would be nice to have a clear reference somewhere in the wiki for configs with the options needed to build for EL-3. (Yes, I know EPEL does not support this distro but a) as pointed above there are quite a lot of machines in use and b) it would not hurt.)
On Nov 20, 2007 2:52 PM, Manuel Wolfshant wolfy@nobugconsulting.ro wrote:
On 11/20/2007 11:44 PM, Stephen John Smoogen wrote:
On Nov 20, 2007 2:29 PM, Manuel Wolfshant wolfy@nobugconsulting.ro wrote:
On 11/20/2007 11:20 PM, Michael E Brown wrote:
On Tue, Nov 20, 2007 at 02:05:46PM -0700, Stephen John Smoogen wrote:
Ok I am going to ask the harder question :). How does this affect RHEL-4 and such?
Does not affect RHEL4. I dont intend to upgrade mock in RHEL4 at this time, as I dont have a box to test this out on. Nor do I think it worth the effort to do so, as I doubt there are any users (or at least *very* few, if any.)
I have to contradict you here. To my knowledge Centos 4 is quite popular and even though lots of people have switched their devel boxes to C5 or Fedora, those still using C4 need love, too.
From what I can tell with 3 sites, the numbers are the following:
60%+ EL-3 30%+ EL-4 5% + EL-5 5% other.
Stephen, please note that we are not simply speaking about machines _running_ a specific distro but about machines running a distro _and_also_ doing development. As Michael has pointed out, one can very well do development on one distro (i.e. run mock on a Fedora box for instance) and test the compiled stuff on EL-3 / EL-4 / EL-5.
Well up until I started working at the University, I was used to a very conservative take on Operating Systems. You couldn't just stick a new distribution on the network. You had to get it 'audited' for security, stability, and trust-worthiness which took usually 3-9 months depending on what it was doing and how high up the approval needed. So the vast amount of development work was done on EL-3/EL-4. Now that I have been at a university for a year now.. I am beginning to loosen up.. a bit.
BTW, I think that it would be nice to have a clear reference somewhere in the wiki for configs with the options needed to build for EL-3. (Yes, I know EPEL does not support this distro but a) as pointed above there are quite a lot of machines in use and b) it would not hurt.)
I support it whether or not EPEL does :).
On Tue, Nov 20, 2007 at 11:52:27PM +0200, Manuel Wolfshant wrote:
Stephen, please note that we are not simply speaking about machines _running_ a specific distro but about machines running a distro _and_also_ doing development. As Michael has pointed out, one can very well do development on one distro (i.e. run mock on a Fedora box for instance) and test the compiled stuff on EL-3 / EL-4 / EL-5.
BTW, I think that it would be nice to have a clear reference somewhere in the wiki for configs with the options needed to build for EL-3. (Yes, I know EPEL does not support this distro but a) as pointed above there are quite a lot of machines in use and b) it would not hurt.)
If somebody wants to add this to the wiki, go ahead.
Here are the configs I personally use to compile packages for RHEL 3 i386 and x86_64. You probably want to point the baseurls at a handy mirror, I have an internal one I maintain. -- Michael
On Tue, Nov 20, 2007 at 03:02:11PM -0600, Michael E Brown wrote:
Because the config format changed in Fedora and all of 3 people emailed me about it.
Looks like enough people to me, but...
But why not have just fixed the nasty bug only and leave the old mock?
Mock in EPEL5 is 0.7.2. I have an *experimental* 0.7.7 patchset that has been verified to *not* fix the problem. The change from 0.7.2 to 0.7.7+patch to fix this is, in itself, a pretty large jump with several new features.
... in that case I guess you'll have to update. It doesn't looks like very EPELish to me, but I understand the issues you are facing, and I withdraw my opposition.
-- Pat
On Tue, Nov 20, 2007 at 10:35:54PM +0100, Patrice Dumas wrote:
On Tue, Nov 20, 2007 at 03:02:11PM -0600, Michael E Brown wrote:
Because the config format changed in Fedora and all of 3 people emailed me about it.
Looks like enough people to me, but...
But why not have just fixed the nasty bug only and leave the old mock?
Mock in EPEL5 is 0.7.2. I have an *experimental* 0.7.7 patchset that has been verified to *not* fix the problem. The change from 0.7.2 to 0.7.7+patch to fix this is, in itself, a pretty large jump with several new features.
... in that case I guess you'll have to update. It doesn't looks like very EPELish to me, but I understand the issues you are facing, and I withdraw my opposition.
Thank you.
Based on the discussion, I will plan on pushing an update into testing this week. I will send out another note once that has been done.
Thank you to everybody who contributed to the discussion, as well. -- Michael
Michael E Brown wrote:
All, Mock 0.8.9 is sitting in the upstream git repository. I have tested this version on RHEL5, and it appears to work satisfactorily there. I have fixed the last remaining issue that I have seen on RHEL.
There are a few config file changes, as well as a couple differencesin command line behaviour from previous releases, detailed in my release announcement to fedora-buildsys-list [1].
What are people's thoughts on upgrading the EPEL5 version of mock to0.8.9? I would like to upgrade EPEL5 mock to 0.8.9.
Here are the benefits:
Bugfixes: -- There are several outstanding bugs in the existing version of mock on RHEL, including one bug that can result in removal of /dev/ on the host in some circumstances. These are all fixed in 0.8.x.
+1 upgrade, please. I've personally had this happen on several occasions. Major suckage.
-- Rex
Michael E Brown wrote:
All, Mock 0.8.9 is sitting in the upstream git repository. I have tested this version on RHEL5, and it appears to work satisfactorily there. I have fixed the last remaining issue that I have seen on RHEL.
There are a few config file changes, as well as a couple differencesin command line behaviour from previous releases, detailed in my release announcement to fedora-buildsys-list [1].
What are people's thoughts on upgrading the EPEL5 version of mock to0.8.9? I would like to upgrade EPEL5 mock to 0.8.9.
Here are the benefits:
Bugfixes: -- There are several outstanding bugs in the existing version of mock on RHEL, including one bug that can result in removal of /dev/ on the host in some circumstances. These are all fixed in 0.8.x.
+1 upgrade, please. I've personally had this happen on several occasions. Major suckage.
+1 I think this trumps the "do-not-update" tendancy EPEL has, due to the severity of the bugs it fixes.
-- Rex
epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
On 11/20/2007 09:53 PM, Michael E Brown wrote:
All, Mock 0.8.9 is sitting in the upstream git repository. I have tested this version on RHEL5, and it appears to work satisfactorily there. I have fixed the last remaining issue that I have seen on RHEL.
[...] I've been using version 0.8.7 in Fedora 7 since released and after being pointed to the new way of adding "-j 3" for parallel make, I am extremely happy with it. The speed difference is noticeable. What I would have liked to see and I think that is worth including is a simple Readme with a couple of common examples on how to add options (the new way) to .conf files. Bottom line, I am very much in favor of including the new version in EPEL. I don't believe the few differences in config are worth forcing 7yrs worth of maintenance of the old (and broken) version.
On Tue, Nov 20, 2007 at 11:22:53PM +0200, Manuel Wolfshant wrote:
On 11/20/2007 09:53 PM, Michael E Brown wrote:
All, Mock 0.8.9 is sitting in the upstream git repository. I have tested this version on RHEL5, and it appears to work satisfactorily there. I have fixed the last remaining issue that I have seen on RHEL.
[...] I've been using version 0.8.7 in Fedora 7 since released and after being pointed to the new way of adding "-j 3" for parallel make, I am extremely happy with it. The speed difference is noticeable.
Thanks. I put a *lot* of work into making it faster.
What I would have liked to see and I think that is worth including is a simple Readme with a couple of common examples on how to add options (the new way) to .conf files.
Good point to bring up: one of the things I've tried to do with mock 0.8.x is to keep the '/etc/mock/defaults.cfg' file up-to-date with the latest config options that are available. So, if you want to know any of the configuration file options that can be set, look in there and you should see examples of how to configure them. All the options are either self-explanatory, or have blurbs.
Also, I have tried very hard to keep the manpage up-to-date as well, documenting all the cmdline switches. So, one of the areas that mock 0.8.x has improved is the documentation.
Bottom line, I am very much in favor of including the new version in EPEL. I don't believe the few differences in config are worth forcing 7yrs worth of maintenance of the old (and broken) version.
Thanks.
-- Michael
On 11/20/2007 11:29 PM, Michael E Brown wrote:
Good point to bring up: one of the things I've tried to do with mock 0.8.x is to keep the '/etc/mock/defaults.cfg' file up-to-date with the latest config options that are available. So, if you want to know any of the configuration file options that can be set, look in there and you should see examples of how to configure them. All the options are either self-explanatory, or have blurbs.
How about adding something along "The included /etc/mock/defaults.cfg describes the new format of options and is also a good example on how to add your own parameters " to the bundled Readme and/or the man?
Also, I have tried very hard to keep the manpage up-to-date as well, documenting all the cmdline switches. So, one of the areas that mock 0.8.x has improved is the documentation.
The man page was the first thing I've read (unlike my usual habit of reading the man pages only as a last resort, when nothing else helps :) ). But since I am ... hum.. parallel to python, I needed the help of ivazquez (thank you, again!) to see the light in config_opts['macros']['%_smp_mflags']= '-j3' Second thought, since testing parallel builds is mandatory for Fedora, I think it would be nice to have the above line included by default (commented out for compatibility with previous versions) in all repo configs.
On Tue, Nov 20, 2007 at 11:42:37PM +0200, Manuel Wolfshant wrote:
On 11/20/2007 11:29 PM, Michael E Brown wrote:
Good point to bring up: one of the things I've tried to do with mock 0.8.x is to keep the '/etc/mock/defaults.cfg' file up-to-date with the latest config options that are available. So, if you want to know any of the configuration file options that can be set, look in there and you should see examples of how to configure them. All the options are either self-explanatory, or have blurbs.
How about adding something along "The included /etc/mock/defaults.cfg describes the new format of options and is also a good example on how to add your own parameters " to the bundled Readme and/or the man?
Done. Thanks for the suggestion.
Also, I have tried very hard to keep the manpage up-to-date as well, documenting all the cmdline switches. So, one of the areas that mock 0.8.x has improved is the documentation.
The man page was the first thing I've read (unlike my usual habit of reading the man pages only as a last resort, when nothing else helps :) ). But since I am ... hum.. parallel to python, I needed the help of ivazquez (thank you, again!) to see the light in config_opts['macros']['%_smp_mflags']= '-j3' Second thought, since testing parallel builds is mandatory for Fedora, I think it would be nice to have the above line included by default (commented out for compatibility with previous versions) in all repo configs.
There is a head-scratcher. I *thought* that it was rpmbuild's responsibility to automatically detect the number of processors in the system and add this flag, if necessary.
I'll ask about it in #fedora-devel. -- Michael
On 11/20/2007 11:54 PM, Rex Dieter wrote:
Michael E Brown wrote:
There is a head-scratcher. I *thought* that it was rpmbuild's responsibility to automatically detect the number of processors in the system and add this flag, if necessary.
Yes, %{_smp_mflags} gets defined automatically
Could it be that the option is defined automatically in koji (plague?) but not on my box? I had a package not compiling with -j3 and I detected it only after adding the said option to mock config.
On Tuesday 20 November 2007 22:00:01 Manuel Wolfshant wrote:
On 11/20/2007 11:54 PM, Rex Dieter wrote:
Michael E Brown wrote:
There is a head-scratcher. I *thought* that it was rpmbuild's responsibility to automatically detect the number of processors in the system and add this flag, if necessary.
Yes, %{_smp_mflags} gets defined automatically
Could it be that the option is defined automatically in koji (plague?) but not on my box? I had a package not compiling with -j3 and I detected it only after adding the said option to mock config.
Notice that unless you have three processors the flag will have the number of processors on your machine. Depending on the package you are building the bottleneck is not the cpu but the disc so it is possible to increase the value and have better build times.
I do it all the time. :-)
José Matos wrote:
On Tuesday 20 November 2007 22:00:01 Manuel Wolfshant wrote:
On 11/20/2007 11:54 PM, Rex Dieter wrote:
Michael E Brown wrote:
There is a head-scratcher. I *thought* that it was rpmbuild's responsibility to automatically detect the number of processors in the system and add this flag, if necessary.
Yes, %{_smp_mflags} gets defined automatically
Could it be that the option is defined automatically in koji (plague?) but not on my box? I had a package not compiling with -j3 and I detected it only after adding the said option to mock config.
Notice that unless you have three processors the flag will have the number of processors on your machine. Depending on the package you are building the bottleneck is not the cpu but the disc so it is possible to increase the value and have better build times.
I do it all the time. :-)
I was not interested in build time but in making sure that the compilation process actually works. There are cases where bugs prevent parallel make.
Manuel
On 11/20/2007 11:54 PM, Rex Dieter wrote:
Michael E Brown wrote:
There is a head-scratcher. I *thought* that it was rpmbuild's responsibility to automatically detect the number of processors in the system and add this flag, if necessary.
Yes, %{_smp_mflags} gets defined automatically
For what is worth, I've just checked: - %{_smp_mflags} is set automatically by mock to the number of processors - it can be overriden by config_opts['macros']['%_smp_mflags'] = '-jN' where N is the desired number of threads
Manuel
epel-devel@lists.fedoraproject.org
-
Jon Ciesla -
José Abílio Matos -
Manuel Wolfshant -
Michael E Brown -
Patrice Dumas -
Rex Dieter -
Rich Megginson -
Stephen John Smoogen