Hi,
I thinking that the answer is that it is not currently possible but is there any arrangement of configuration to allow a build on say centos4 and centos5 concurrently.
A build tartget that has a fork to two buildroots and destination tags. Both would need to work for the overall task to work.
Steve
Steve Traylen wrote:
Hi,
I thinking that the answer is that it is not currently possible but is there any arrangement of configuration to allow a build on say centos4 and centos5 concurrently.
A build tartget that has a fork to two buildroots and destination tags. Both would need to work for the overall task to work.
If you mean one "koji build" results in two builds being created in Koji, then no that is not currently possible.
This sounds like something that could easily be handled with a Makefile target though.
Create your separate dist-centos4 and dist-centos5 build/dest tags and targets. Have a "make build" generate the appropriate SCM URL and call:
koji build --nowait dist-centos4 $SCMURL koji build --nowait dist-centos5 $SCMURL
Assuming you're using %{?dist} in your specfiles and have the buildsys-macros defined correctly (and uniquely) in the -build tags, this will create 2 separate builds in different tags from the same sources.
On Thu, May 14, 2009 at 8:08 PM, Mike Bonnet mikeb@redhat.com wrote:
Steve Traylen wrote:
Hi,
I thinking that the answer is that it is not currently possible but is there any arrangement of configuration to allow a build on say centos4 and centos5 concurrently.
A build tartget that has a fork to two buildroots and destination tags. Both would need to work for the overall task to work.
If you mean one "koji build" results in two builds being created in Koji, then no that is not currently possible.
This sounds like something that could easily be handled with a Makefile target though.
Create your separate dist-centos4 and dist-centos5 build/dest tags and targets. Have a "make build" generate the appropriate SCM URL and call:
koji build --nowait dist-centos4 $SCMURL koji build --nowait dist-centos5 $SCMURL
This works of course. I was hoping to force the dists to stay in step though. builds are only tagged for el5 and el4 or not at all. Rather like currently both i386 and x86_64 must both work to get either. I can force the submitters to build on fc10 as well el4 and 5 to future proof ourself.
Assuming you're using %{?dist} in your specfiles and have the buildsys-macros defined correctly (and uniquely) in the -build tags, this will create 2 separate builds in different tags from the same sources.
An item relevant to this. When building say a -el4.src.rpm on el5
koji build dist-centos5 foobar-1.5.2.el4.src.rpm
will always fail because the resulting foobar-1.5.2.el5.src.rpm does not name match foobar-1.5.2.el4.src.rpm
Is this check useful? It requires one to create to src.rpms before they can be submitted to dist-centos4 and 5. I can't for instance just grab a src.rpm package from fc10 and submit it.
(a cheeky p.s, did you get the slides I sent. no comment is just fine)
-- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Steve Traylen wrote:
On Thu, May 14, 2009 at 8:08 PM, Mike Bonnet mikeb@redhat.com wrote:
Steve Traylen wrote:
Hi,
I thinking that the answer is that it is not currently possible but is there any arrangement of configuration to allow a build on say centos4 and centos5 concurrently.
A build tartget that has a fork to two buildroots and destination tags. Both would need to work for the overall task to work.
If you mean one "koji build" results in two builds being created in Koji, then no that is not currently possible.
This sounds like something that could easily be handled with a Makefile target though.
Create your separate dist-centos4 and dist-centos5 build/dest tags and targets. Have a "make build" generate the appropriate SCM URL and call:
koji build --nowait dist-centos4 $SCMURL koji build --nowait dist-centos5 $SCMURL
This works of course. I was hoping to force the dists to stay in step though. builds are only tagged for el5 and el4 or not at all. Rather like currently both i386 and x86_64 must both work to get either. I can force the submitters to build on fc10 as well el4 and 5 to future proof ourself.
This could be accomplished with "koji build --skip-tag". Then "koji watch-task" on the two taskIDs, and if that returns 0 you can then "koji tag-pkg" the two builds into their dest tags. It would probably be more robust to code this up by using the xmlrpc api directly, so you can check task success/failure and get the build NVR from the task ID directly, rather than parsing the output of "koji taskinfo".
Assuming you're using %{?dist} in your specfiles and have the buildsys-macros defined correctly (and uniquely) in the -build tags, this will create 2 separate builds in different tags from the same sources.
An item relevant to this. When building say a -el4.src.rpm on el5
koji build dist-centos5 foobar-1.5.2.el4.src.rpm
will always fail because the resulting foobar-1.5.2.el5.src.rpm does not name match foobar-1.5.2.el4.src.rpm
Is this check useful? It requires one to create to src.rpms before they can be submitted to dist-centos4 and 5. I can't for instance just grab a src.rpm package from fc10 and submit it.
We only do this check for real (non --scratch) builds, and yes it is useful. The NVR of the "build" object in the database comes from that srpm. It would be very confusing if a build called "foo-1.0-1.el4" generated an rpm named "foo-1.0-1.el5".
(a cheeky p.s, did you get the slides I sent. no comment is just fine)
Yes, haven't had a change to look them over yet though, I'll do that today.
Steve Traylen wrote:
Is this check useful? It requires one to create to src.rpms before they can be submitted to dist-centos4 and 5. I can't for instance just grab a src.rpm package from fc10 and submit it.
Koji likes to know the NVR it is building before it starts building it. This allows Koji to mark the build as in progress. It also allows Koji to detect nvr conflicts early (rather than at the end of the build).
If the resulting build does not match this NVR then that is pretty big consistency problem
I too have run into this quirk. It is not that difficult to remake the srpm with the right dist tag before submitting.
On Thu, May 14, 2009 at 10:30 PM, Mike McLean mikem@redhat.com wrote:
Steve Traylen wrote:
Is this check useful? It requires one to create to src.rpms before they can be submitted to dist-centos4 and 5. I can't for instance just grab a src.rpm package from fc10 and submit it.
Koji likes to know the NVR it is building before it starts building it. This allows Koji to mark the build as in progress. It also allows Koji to detect nvr conflicts early (rather than at the end of the build).
If the resulting build does not match this NVR then that is pretty big consistency problem
I too have run into this quirk. It is not that difficult to remake the srpm with the right dist tag before submitting.
Indeed if there is a reason which there clearly is then its fine. As you say a quick rpm -Uvh && rpmbuild -bs --define 'dist .el5' to the rescue.
Steve
-- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
buildsys@lists.fedoraproject.org
-
Mike Bonnet -
Mike McLean -
Steve Traylen