I'm able to build aarch64 packages for Rawhide using Koji in the usual way, but what do I need to do to build aarch64 packages for F24 using Koji?
Thanks! Eric
On 2016-09-23 16:42, Eric Smith wrote:
I'm able to build aarch64 packages for Rawhide using Koji in the usual way, but what do I need to do to build aarch64 packages for F24 using Koji?
A scratch build can be started with:
arm-koji build --scratch f24 ....
Normal builds are not launched manually specifically for AArch64; just launch the normal build and koji-shadow will handle the rest.
On Fri, Sep 23, 2016 at 5:00 PM, Jeremy Linton jeremy.linton@arm.com wrote:
The usual way being just koji, or arm-koji? To use the secondary builders I think you need arm-koji. Maybe there is more to it..
On Fri, Sep 23, 2016 at 5:08 PM, Yaakov Selkowitz yselkowi@redhat.com wrote:
Normal builds are not launched manually specifically for AArch64; just launch the normal build and koji-shadow will handle the rest.
It appears that 'arm-koji' is what I needed. For rawhide, just using normal koji will build for aarch64, but for f24, it doesn't build for aarch64, even if --arch-override=aarch64 is given.
Thanks!
Normally I build release packages and push updates using "fedpkg build" and "fedpkg update". I've already done that for a few packages for f24, but those didn't get aarch64. Is there a simple way to build them and push updates for aarch64 as well?
Thanks! Eric
On Fri, 23 Sep 2016 20:49:25 -0600 Eric Smith spacewar@gmail.com wrote:
Normally I build release packages and push updates using "fedpkg build" and "fedpkg update". I've already done that for a few packages for f24, but those didn't get aarch64. Is there a simple way to build them and push updates for aarch64 as well?
it's a semi-automatic process that follows the exact build order in primary koji and no action is needed from the maintainer. Which packages/builds should be missing in aarch64?
Dan
I wrote:
Normally I build release packages and push updates using "fedpkg build" and "fedpkg update". I've already done that for a few packages for f24, but those didn't get aarch64. Is there a simple way to build them and push updates for aarch64 as well?
On Sat, Sep 24, 2016 at 12:54 AM, Dan Horák dan@danny.cz wrote:
it's a semi-automatic process that follows the exact build order in primary koji and no action is needed from the maintainer. Which packages/builds should be missing in aarch64?
For instance, I recently pushed an update for abc, abc-1.01-9.hg20160905, to f24, f25, and epel7. While "fedpkg build" in the rawhide branch built it just fine for aarch64, running "fedpkg build" in the f24 and f25 branches only built packages for i686, x86_64, and armv7hl, so only those architectures got the update.
I wouldn't normally worry about getting an update to abc into existing Fedora branches, but in this case it's necessary to build the yosys Verilog synthesizer (pending package review #1375765), and I'd like to push yosys and related FPGA tools to f24 and f25 (obviously depending on when the package review happens).
Thanks, Eric
On Sat, 24 Sep 2016 02:01:11 -0600 Eric Smith spacewar@gmail.com wrote:
I wrote:
Normally I build release packages and push updates using "fedpkg build" and "fedpkg update". I've already done that for a few packages for f24, but those didn't get aarch64. Is there a simple way to build them and push updates for aarch64 as well?
On Sat, Sep 24, 2016 at 12:54 AM, Dan Horák dan@danny.cz wrote:
it's a semi-automatic process that follows the exact build order in primary koji and no action is needed from the maintainer. Which packages/builds should be missing in aarch64?
For instance, I recently pushed an update for abc, abc-1.01-9.hg20160905, to f24, f25, and epel7. While "fedpkg build" in the rawhide branch built it just fine for aarch64, running "fedpkg build" in the f24 and f25 branches only built packages for i686, x86_64, and armv7hl, so only those architectures got the update.
I wouldn't normally worry about getting an update to abc into existing Fedora branches, but in this case it's necessary to build the yosys Verilog synthesizer (pending package review #1375765), and I'd like to push yosys and related FPGA tools to f24 and f25 (obviously depending on when the package review happens).
that's correct, only F-26/rawhide has aarch64 as part of primary koji instance, F<=25 are still built in http://arm.koji.fedoraproject.org
for abc builds see http://arm.koji.fedoraproject.org/koji/packageinfo?packageID=19281
Dan
On Sat, Sep 24, 2016 at 2:14 AM, Dan Horák dan@danny.cz wrote:
that's correct, only F-26/rawhide has aarch64 as part of primary koji instance, F<=25 are still built in http://arm.koji.fedoraproject.org
That's my point exactly. Now that I know to use arm-koji I can do an aarch64 scratch build for f24 or f25, but despite reading a lot of documentation, I haven't a clue as to how to start a non-scratch f2[45] aarch64 build or push an f2[45] aarch64 update. I suppose this must be documented somewhere, but I haven't been able to find it.
On Sat, 24 Sep 2016 02:35:56 -0600 Eric Smith spacewar@gmail.com wrote:
On Sat, Sep 24, 2016 at 2:14 AM, Dan Horák dan@danny.cz wrote:
that's correct, only F-26/rawhide has aarch64 as part of primary koji instance, F<=25 are still built in http://arm.koji.fedoraproject.org
That's my point exactly. Now that I know to use arm-koji I can do an aarch64 scratch build for f24 or f25, but despite reading a lot of documentation, I haven't a clue as to how to start a non-scratch f2[45] aarch64 build or push an f2[45] aarch64 update. I suppose this must be documented somewhere, but I haven't been able to find it.
As I wrote earlier package maintainers shouldn't (must not) initiate any non-scratch builds in the secondary build systems, the koji-shadow semi-automated system (and other tools) managed by release engineering take care of that.
Dan
On Sat, Sep 24, 2016 at 2:50 AM, Dan Horák dan@danny.cz wrote:
As I wrote earlier package maintainers shouldn't (must not) initiate any non-scratch builds in the secondary build systems, the koji-shadow semi-automated system (and other tools) managed by release engineering take care of that.
Sorry, but that just leaves me even more baffled. How does koji-shadow know whether and when it should package up an f2[45] aarch64 package update? Are you saying that the abc package update I already pushed to f2[45] for the primary arches is going to at some mysterious point in the future get built and pushed to aarch64 f2[45]? How long does that take?
With a primary arch, I can set up a buildroot override once a package is built, so that I can then build a dependent package. Is that possible for a secondary arch?
On Sat, 24 Sep 2016 02:58:45 -0600 Eric Smith spacewar@gmail.com wrote:
On Sat, Sep 24, 2016 at 2:50 AM, Dan Horák dan@danny.cz wrote:
As I wrote earlier package maintainers shouldn't (must not) initiate any non-scratch builds in the secondary build systems, the koji-shadow semi-automated system (and other tools) managed by release engineering take care of that.
Sorry, but that just leaves me even more baffled. How does koji-shadow know whether and when it should package up an f2[45] aarch64 package update? Are you saying that the abc package update I already pushed to f2[45] for the primary arches is going to at some mysterious point in the future get built and pushed to aarch64 f2[45]? How long does that take?
With a primary arch, I can set up a buildroot override once a package is built, so that I can then build a dependent package. Is that possible for a secondary arch?
the maintainer doesn't need to care about builds in secondary kojis, the koji-shadow script (started periodically from cron or manually) takes a list of finished builds from primary koji and builds them in the same order using the same buildroots as were used in primary koji. Using recursion it first builds any of the missing builds in buildroots. The delay is between couple minutes and lets say a day when no breakage occurs in the buildroot chain.
Dan
On Sat, Sep 24, 2016 at 9:58 AM, Eric Smith spacewar@gmail.com wrote:
On Sat, Sep 24, 2016 at 2:50 AM, Dan Horák dan@danny.cz wrote:
As I wrote earlier package maintainers shouldn't (must not) initiate any non-scratch builds in the secondary build systems, the koji-shadow semi-automated system (and other tools) managed by release engineering take care of that.
Sorry, but that just leaves me even more baffled. How does koji-shadow know whether and when it should package up an f2[45] aarch64 package update? Are you saying that the abc package update I already pushed to f2[45] for the primary arches is going to at some mysterious point in the future get built and pushed to aarch64 f2[45]? How long does that take?
It takes the information from the primary koji instance and sorts it out based on information from the API
With a primary arch, I can set up a buildroot override once a package is built, so that I can then build a dependent package. Is that possible for a secondary arch?
No, it's not for an end user, but the shadow process already mentioned recreates the details of those overrides based on the information about the build stored in the primary database so the shadow process will automatically generate the overrides and all needed bits when it mirrors the builds over.
Basically just leave anything to do with < F-26 alone and it'll be sorted out.
Peter
On Sat, Sep 24, 2016 at 3:10 AM, Dan Horák dan@danny.cz wrote:
the maintainer doesn't need to care about builds in secondary kojis, the koji-shadow script (started periodically from cron or manually) takes a list of finished builds from primary koji and builds them in the same order using the same buildroots as were used in primary koji.
On Sat, Sep 24, 2016 at 8:06 AM, Peter Robinson pbrobinson@gmail.com wrote:
No, it's not for an end user, but the shadow process already mentioned recreates the details of those overrides based on the information about the build stored in the primary database so the shadow process will automatically generate the overrides and all needed bits when it mirrors the builds over.
Basically just leave anything to do with < F-26 alone and it'll be sorted out.
Thanks to both of you for explaining. It looks like what you described happened fine for my packages, but dnf in my F24 aarch64 install isn't finding the package updates. Must be a local configuration problem.
On Mon, Sep 26, 2016 at 8:56 PM, Eric Smith spacewar@gmail.com wrote:
On Sat, Sep 24, 2016 at 3:10 AM, Dan Horák dan@danny.cz wrote:
the maintainer doesn't need to care about builds in secondary kojis, the koji-shadow script (started periodically from cron or manually) takes a list of finished builds from primary koji and builds them in the same order using the same buildroots as were used in primary koji.
On Sat, Sep 24, 2016 at 8:06 AM, Peter Robinson pbrobinson@gmail.com wrote:
No, it's not for an end user, but the shadow process already mentioned recreates the details of those overrides based on the information about the build stored in the primary database so the shadow process will automatically generate the overrides and all needed bits when it mirrors the builds over.
Basically just leave anything to do with < F-26 alone and it'll be sorted out.
Thanks to both of you for explaining. It looks like what you described happened fine for my packages, but dnf in my F24 aarch64 install isn't finding the package updates. Must be a local configuration problem.
The updates do come a little later, if you mention the actual package with an issue I can see where in the pipeline it is.
Peter
-
Dan Horák -
Eric Smith -
Peter Robinson -
Yaakov Selkowitz