----- Original Message -----
> From: "Dan Kenigsberg" <danken(a)redhat.com>
> To: "Alon Bar-Lev" <alonbl(a)redhat.com>, "Yaniv Bronheim"
<ybronhei(a)redhat.com>
> Cc: "Itamar Heim" <iheim(a)redhat.com>, "infra"
<infra(a)ovirt.org>, "Moran Goldboim" <mgoldboi(a)redhat.com>,
"Eyal Edri"
> <eedri(a)redhat.com>
> Sent: Thursday, November 29, 2012 12:02:58 PM
> Subject: Re: fedora 18 builds on
jenkins.ovirt.org
>
> On Thu, Nov 29, 2012 at 02:57:20AM -0500, Alon Bar-Lev wrote:
> >
> >
> > ----- Original Message -----
> > > From: "Itamar Heim" <iheim(a)redhat.com>
> > > To: "Eyal Edri" <eedri(a)redhat.com>
> > > Cc: "infra" <infra(a)ovirt.org>, "Moran Goldboim"
> > > <mgoldboi(a)redhat.com>, "Dan Kenigsberg"
<danken(a)redhat.com>,
> > > "Alon
> > > Bar-Lev" <alonbl(a)redhat.com>
> > > Sent: Thursday, November 29, 2012 9:53:28 AM
> > > Subject: Re: fedora 18 builds on
jenkins.ovirt.org
> > >
> > > On 11/29/2012 02:08 AM, Eyal Edri wrote:
> > > >
> > > >
> > > > ----- Original Message -----
> > > >> From: "Itamar Heim" <iheim(a)redhat.com>
> > > >> To: "Eyal Edri" <eedri(a)redhat.com>
> > > >> Cc: "infra" <infra(a)ovirt.org>, "Moran
Goldboim"
> > > >> <mgoldboi(a)redhat.com>
> > > >> Sent: Thursday, November 29, 2012 2:26:21 AM
> > > >> Subject: Re: fedora 18 builds on
jenkins.ovirt.org
> > > >>
> > > >> On 11/28/2012 02:02 PM, Eyal Edri wrote:
> > > >>> fyi,
> > > >>>
> > > >>> i've done some changes to allow f18 builds:
> > > >>>
> > > >>> 1. upgraded fedora17-slave-vm01 to fedora18-slave-vm01. (new
> > > >>> label
> > > >>> fedora18)
> > > >>> 2. created new matrix jobs [1] to create rpms per project
for
> > > >>> each
> > > >>> operating system,
> > > >>> so only one job will create rpms for all operating
> > > >>> systems
> > > >>> (currently f17,f18).
> > > >>> 3. publish rpms job will copy all artifacts from the matrix
> > > >>> jobs
> > > >>> into sub-folder on
ovirt.org.
> > > >>> 4. we need to update publish script that runs on
ovirt.org
to
> > > >>> take
> > > >>> fedora 18 files as well.
> > > >>>
> > > >>> so far i've created the following matrix jobs:
> > > >>>
> > > >>>
http://jenkins.ovirt.org/view/rpms/job/ovirt-host-deploy_create_rpms_fedora/
> > > >>>
http://jenkins.ovirt.org/view/rpms/job/otopi_create_rpms_fedora/
> > > >>>
http://jenkins.ovirt.org/view/rpms/job/ovirt-engine_create_rpms_fedora/
> > > >>>
> > > >>> let me know when the publish cronjob on linode is updated,
so
> > > >>> i'll
> > > >>> create the projects for other jobs also.
> > > >>>
> > > >>> example f18 rpms:
> > > >>>
> > > >>>
http://jenkins.ovirt.org/view/rpms/job/ovirt-engine_create_rpms_fedora/jd...
> > > >>>
> > > >>> [1]
> > > >>>
http://jenkins.ovirt.org/view/rpms/job/ovirt-host-deploy_create_rpms_fedora/
> > > >>>
> > > >>>
> > > >>> Eyal.
> > > >>>
> > > >>
> > > >> where are they published under
http://www.ovirt.org/releases?
> > > >>
> > > >
> > > > OK, just found the cronjob that fetch them and creates the
> > > > repos.
> > > > i updated it to take f18 as well (didn't know what to do with
> > > > ovirt-release:
> > > >
> > > > /bin/find /home/jenkins/ovirt-nightly/artifacts/ -name
> > > > "*ovirt-release-fedora-*" -exec mv {}
> > > > /var/www/html/releases/nightly/rpm/Fedora/17/noarch \;
> > > >
> > > > it doesn't have a distinguish naming per fedora rel...
> > > >
> > > > publish script is running now, we should have f18 rpms soon on
> > > >
ovirt.org/releases/nightly/rpm/Fedora/18
> > > >
> > > >>
> > >
> > > thanks.
> > > can you please chase all relevant package owner for versions to
> > > change
> > > to 3.2?
> > > danken - is there a reason all the hooks are in the noarch, but
> > > vdsm
> > > is
> > > in the x86_64?
> >
> >
http://gerrit.ovirt.org/#/c/6098/
>
> Yeah, we should handle this some day. CCing ybronhei.
>
> I much prefer to take betterPopen out of vdsm completely, or at least
> into an x86_64 subpackage. Same should happen to safelease.
> I'd like the package separation to be based on functionality and not
> python-nativeness.
You are free to suggest any other method, however, I don't think the effort is worth
it.
betterPopen will not go anywhere else in the near future... nor other components, so I
would have done this as simplest as I can.
Splitting out vdsm-cpopen.x86_64 and vdsm-safelease.x86_64 would make
vdsm.noarch.
I do not think it is more complex than your suggestion.
Dan.