Freeze Break Request: update libtaskotorn on taskotron production systems

[Tim Flink]

On Tue, 4 Nov 2014 18:34:14 +0100
Pierre-Yves Chibon <pingou at pingoured.fr> wrote:

<snip>

> > +import os
> > +
> > +class Arches():
> > +    '''
> > +    Helper class for working with supported arches inside taskotron
> > +    '''
> > +
> > +    #: all supported architectures
> > +    all = ['i386', 'i486', 'i586', 'i686',
> > +           'x86_64',
> > +           'armhfp', 'arm7hl',
> > +           'noarch', 'src']
> > +
> > +    #: base architectures
> > +    base = ['i386', 'x86_64', 'armhfp']
> > +
> > +    #: meta architectures
> > +    meta = ['noarch', 'src']
> > +
> > +def basearch(arch=None):
> > +    '''
> > +    This returns the 'base' architecture identifier for a
> > specified architecture
> > +    (e.g. ``i386`` for ``i[3-6]86``), to be used by YUM etc.
> > +
> > +    :param str arch: an architecture to be converted to a
> > basearch. If ``None``,
> > +                     then the arch of the current machine is used.
> > +    :return: basearch, or ``arch`` if no basearch was found for it
> > +    :rtype: str
> > +    '''
> > +    if arch is None:
> > +        arch = os.uname()[4]
> > +    if arch in ['i386', 'i486', 'i586', 'i686']:
> > +        arch = 'i386'
> > +    if arch in ['armhfp', 'arm7hl']:
> > +        arch = 'armhfp'
> > +    return arch
> 
> Not at all related to the freeze-break, but have you consider putting
> the info used by basearch/Arches() into the config file?
> It would allow adding a new arch w/o making a new release.

This is mostly a stopgap - we have other arch handling issues that we
want to fix but haven't gotten to it yet.

https://phab.qadevel.cloud.fedoraproject.org/T227

> >          return (build2update, failures)
> > diff --git a/libtaskotron/config_defaults.py
> > b/libtaskotron/config_defaults.py index fc05abd..fb77a7c 100644
> > --- a/libtaskotron/config_defaults.py
> > +++ b/libtaskotron/config_defaults.py
> > @@ -46,13 +46,13 @@ class Config(object):
> >      koji_url =
> > 'http://koji.fedoraproject.org/kojihub'                      #:
> > pkg_url =
> > 'http://kojipkgs.fedoraproject.org/packages'                  #:
> > bodhi_server =
> > 'https://admin.fedoraproject.org/updates/'               #:
> > -    resultsdb_server = \
> > -
> > 'http://resultsdb.qa.fedoraproject.org/resultsdb/api/v1.0/'
> > #:
> > -    taskotron_master =
> > 'http://taskotron.qa.fedoraproject.org/taskmaster/'  #:
> > +    resultsdb_server =
> > 'http://127.0.0.1/resultsdb/api/v1.0/'               #:
> > +    taskotron_master =
> > 'http://127.0.0.1/taskmaster/'                       #:
> > buildbot_task_step =
> > 'runtask'                                          #:
> 
> Was this meant?

Yes, it was. We intend to have folks install libtaskotron in order to
run stuff locally, so pointing them at the production instances by
default isn't a great idea. Also, those values aren't aren't even valid
internal or external hostnames so it's not as big of a change as it
looks :)

https://phab.qadevel.cloud.fedoraproject.org/T344


> Assuming the answer to the question just above is: yes, then I am +1
> as well :)

Thanks

Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/infrastructure/attachments/20141104/892fa444/attachment.sig>