mock 0.8.9 for EPEL-5
 

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 :).


--
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"

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

mock 0.8.9 for EPEL-5
 

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

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

mock 0.8.9 for EPEL-5
 

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
config_opts['root'] = 'rhel3-i386'
config_opts['target_arch'] = 'i386'
config_opts['dist'] = 'el3'
config_opts['macros']['%dist'] = ".el3"
config_opts['macros']['%rhel'] = "3"
config_opts['macros']['%el3'] = "1"
#config_opts['macros']['%__arch_install_post'] = "/usr/lib/rpm/check-buildroot"
config_opts['chroot_setup_cmd'] = 'install bash bzip2 cpio diffutils gcc gcc-c++ gzip make patch perl rpm-build sed tar unzip which redhat-release coreutils elfutils redhat-rpm-config '

# ccache not available on el3
config_opts['plugin_conf']['ccache_enable'] = False

config_opts['yum.conf'] = """
[main]
cachedir=/var/cache/yum
debuglevel=1
logfile=/var/log/yum.log
reposdir=/dev/null
retries=20
obsoletes=1
gpgcheck=0
assumeyes=1

# repos

[core]
name=base
baseurl=http://your.mirror.server.here/pub/yum/rhel3/base/i386/
"""


config_opts['root'] = 'rhel3-x86_64'
config_opts['target_arch'] = 'x86_64'
config_opts['dist'] = 'el3'
config_opts['macros']['%dist'] = ".el3"
config_opts['macros']['%rhel'] = "3"
config_opts['macros']['%el3'] = "1"
config_opts['chroot_setup_cmd'] = 'install bash bzip2 cpio diffutils gcc gcc-c++ gzip make patch perl rpm-build sed tar unzip which redhat-release coreutils elfutils redhat-rpm-config '

# ccache not available on el3
config_opts['plugin_conf']['ccache_enable'] = False

config_opts['yum.conf'] = """
[main]
cachedir=/var/cache/yum
debuglevel=1
logfile=/var/log/yum.log
reposdir=/dev/null
retries=20
obsoletes=1
gpgcheck=0
assumeyes=1
# grub/syslinux on x86_64 need glibc-devel.i386 which pulls in glibc.i386, need to exclude all
# .i?86 packages except these.
exclude=[A-Za-fh-z]*.i*86 g[a-km-z]*.i?86 glib2.i?86 glib.i?86 glib-devel.i?86 glib2-devel.i?86

# repos

[core]
name=base
baseurl=http://your.mirror.server.here/pub/yum/rhel3/base/x86_64/
"""


_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

mock 0.8.9 for EPEL-5
 

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
>



--
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"

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

mock 0.8.9 for EPEL-5
 

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

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

mock 0.8.9 for EPEL-5
 

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


_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

mock 0.8.9 for EPEL-5
 

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-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list