1:53 p.m.
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/msg0002...
2:13 p.m.
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
2:49 p.m.
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
2:53 p.m.
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
3:02 p.m.
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
3:05 p.m.
On Nov 20, 2007 2:02 PM, Michael E Brown <Michael_E_Brown(a)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?
--
Stephen J Smoogen. -- CSIRT/Linux System Administrator
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"
3:20 p.m.
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
3:29 p.m.
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
3:42 p.m.
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
3:44 p.m.
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(a)redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
3:49 p.m.
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
3:45 p.m.
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...
4:50 p.m.
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
5:25 p.m.
On Nov 20, 2007 3:50 PM, Michael E Brown <Michael_E_Brown(a)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(a)redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
--
Stephen J Smoogen. -- CSIRT/Linux System Administrator
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"
3:44 p.m.
On Nov 20, 2007 2:29 PM, Manuel Wolfshant <wolfy(a)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.
--
Stephen J Smoogen. -- CSIRT/Linux System Administrator
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"
3:52 p.m.
On 11/20/2007 11:44 PM, Stephen John Smoogen wrote:
On Nov 20, 2007 2:29 PM, Manuel Wolfshant
<wolfy(a)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.)
4:15 p.m.
On Nov 20, 2007 2:52 PM, Manuel Wolfshant <wolfy(a)nobugconsulting.ro> wrote:
On 11/20/2007 11:44 PM, Stephen John Smoogen wrote:
> On Nov 20, 2007 2:29 PM, Manuel Wolfshant <wolfy(a)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 :).
--
Stephen J Smoogen. -- CSIRT/Linux System Administrator
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"
4:55 p.m.
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
3:35 p.m.
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
3:44 p.m.
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
2:24 p.m.
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 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.
+1 upgrade, please. I've personally had this happen on several occasions.
Major suckage.
-- Rex
2:49 p.m.
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 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.
+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(a)redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
--
novus ordo absurdum
3:22 p.m.
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.
3:29 p.m.
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
3:42 p.m.
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.
3:46 p.m.
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
4 p.m.
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.
2:30 a.m.
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é Abílio
5:07 a.m.
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
6:25 a.m.
> 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
5994
days inactive
5995
days old
epel-devel@lists.fedoraproject.org
30 comments
8 participants
participants (8)
-
Jon Ciesla -
José Abílio Matos -
Manuel Wolfshant -
Michael E Brown -
Patrice Dumas -
Rex Dieter -
Rich Megginson -
Stephen John Smoogen