Re: [EXT] Re: Associating "Target" with "Host(builder)" in Koji
by Tomas Kopecek
Ok, add another rule (before all :: use default) to inherit channel from
parent task:
is_child_task :: parent
On Mon, Aug 21, 2023 at 2:09 PM Joe (Jun-Yan) Chen <jychena(a)ambarella.com>
wrote:
> Tomas,
>
>
> Expression:
> "method build && bool target && match target <build-target> :: use
> cortex-a78ae"
> works well for determining the channel ''cortex-a78ae" for the task
> 'build'.
>
>
> However, the Subsequent task 'rebuildSRPM' and 'buildARCH' still in
> channel 'default', I tried using expression
> "method rebuildSRPM && bool tag && match tag <dest-tag> :: use cortex-a78a
> e"
> "method buildARCH && bool tag && match tag <dest-tag> :: use cortex-a78ae"
> ,
> but didn't work.
>
>
> Is there an expression that can be written in 'hub.conf ' which put tasks 'rebuildSRPM'
> and 'buildARCH' in specific channel? Since seems there's no information
> related to 'target' in these two tasks.
>
>
> Best Regards,
> Junyan CHEN
>
> [image: Ambarella AI Envisioned] <https://www.ambarella.com>
>
> *Junyan(Joe) CHEN*
>
> Software Engineer | SDK Team
>
> *Phone: *+86-021-60880608-265
>
> *Email: *jychena(a)ambarella.com <ypchang(a)ambarella.com>
>
> ------------------------------
> *From:* Tomas Kopecek <tkopecek(a)redhat.com>
> *Sent:* Tuesday, August 15, 2023 3:14 PM
> *To:* Koji development <koji-devel(a)lists.fedorahosted.org>
> *Cc:* Yu-Peng Chang <ypchang(a)ambarella.com>
> *Subject:* [EXT] Re: Associating "Target" with "Host(builder)" in Koji
>
> Yes, you have to use "channels" and corresponding hub policy. So, in this
> case do something like:
> - koji add-host-to-channel --new cortex-a78ae <a78a builder name>
> - koji add-host-to-channel --new cortex-a76 <a76 builder name>
> - edit hub policy (e.g. add section [policy] to /etc/koji-hub/hub.conf or
> create (suggested) separate file in /etc/koji-hub/hub.conf.d/policy.conf
> with this section only for easier maintenance) and add following rules
> there:
>
> [policy]
> channel =
> method build && bool target && match target <your_a78ae_target> :: use
> cortex-a78ae
> method build && bool target && match target <your_a76_target> :: use
> cortex-a76
> all :: use default
>
>
> For other actions/rules consult
> https://docs.pagure.org/koji/defining_hub_policies/
> <https://urldefense.com/v3/__https://docs.pagure.org/koji/defining_hub_pol...>
>
> On Tue, Aug 15, 2023 at 6:15 AM Joe (Jun-Yan) Chen <jychena(a)ambarella.com>
> wrote:
>
> Dear Koji Team,
>
>
> I hope this message finds you well. I am currently seeking guidance on how
> to associate a specific "Target" with its corresponding "Host(builder)".
>
> I have two hosts (builders) with distinct aarch64 architectures:
> Cortex-a78ae and Cortex-a76. I'm aiming for native compilation, where Cortex-a76's
> Target tasks can be exclusive to its host. I've tried editing the tag and
> host's "arch" argument from "aarch64" to "cortex-a76," but faced issues
> during mock's dnf install, fetching merely 'noarch' RPMs from build repo. I
> suspect it's because the RPM's 'Arch' written in the spec file is still
> 'aarch64' not matching 'Cortex-a76'?
>
> Currently, I manually use "assign-task" to designated host, post "koji
> build" for native compilation purpose.
>
> Is there a simpler way or something I'm missing?
>
>
> Your insights are greatly appreciated. Eagerly awaiting your guidance.
>
>
> Best Regards,
> Junyan CHEN
>
> [image: Ambarella AI Envisioned] <https://www.ambarella.com>
>
> *Junyan(Joe) CHEN*
>
> Software Engineer | SDK Team
>
> *Phone: *+86-021-60880608-265
>
> *Email: *jychena(a)ambarella.com <ypchang(a)ambarella.com>
>
> ------------------------------
> This email and attachments contain Ambarella Proprietary and/or
> Confidential Information and is intended solely for the use of the
> individual(s) to whom it is addressed. Any unauthorized review, use,
> disclosure, distribute, copy, or print is prohibited. If you are not an
> intended recipient, please contact the sender by reply email and destroy
> all copies of the original message. Thank you.
> _______________________________________________
> koji-devel mailing list -- koji-devel(a)lists.fedorahosted.org
> To unsubscribe send an email to koji-devel-leave(a)lists.fedorahosted.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> <https://urldefense.com/v3/__https://docs.fedoraproject.org/en-US/project/...>
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> <https://urldefense.com/v3/__https://fedoraproject.org/wiki/Mailing_list_g...>
> List Archives:
> https://lists.fedorahosted.org/archives/list/koji-devel@lists.fedorahoste...
> <https://urldefense.com/v3/__https://lists.fedorahosted.org/archives/list/...>
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
> <https://urldefense.com/v3/__https://pagure.io/fedora-infrastructure/new_i...>
>
>
>
> --
>
> Tomas Kopecek <tkopecek(a)redhat.com>
> RHEL Build Development, RedHat
> ------------------------------
> This EXTERNAL email has been scanned by Proofpoint Email Protect service.
> _______________________________________________
> koji-devel mailing list -- koji-devel(a)lists.fedorahosted.org
> To unsubscribe send an email to koji-devel-leave(a)lists.fedorahosted.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/koji-devel@lists.fedorahoste...
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
--
Tomas Kopecek <tkopecek(a)redhat.com>
RHEL Build Development, RedHat
8 months, 1 week
Re: Associating "Target" with "Host(builder)" in Koji
by Tomas Kopecek
Yes, you have to use "channels" and corresponding hub policy. So, in this
case do something like:
- koji add-host-to-channel --new cortex-a78ae <a78a builder name>
- koji add-host-to-channel --new cortex-a76 <a76 builder name>
- edit hub policy (e.g. add section [policy] to /etc/koji-hub/hub.conf or
create (suggested) separate file in /etc/koji-hub/hub.conf.d/policy.conf
with this section only for easier maintenance) and add following rules
there:
[policy]
channel =
method build && bool target && match target <your_a78ae_target> :: use
cortex-a78ae
method build && bool target && match target <your_a76_target> :: use
cortex-a76
all :: use default
For other actions/rules consult
https://docs.pagure.org/koji/defining_hub_policies/
On Tue, Aug 15, 2023 at 6:15 AM Joe (Jun-Yan) Chen <jychena(a)ambarella.com>
wrote:
> Dear Koji Team,
>
>
> I hope this message finds you well. I am currently seeking guidance on how
> to associate a specific "Target" with its corresponding "Host(builder)".
>
> I have two hosts (builders) with distinct aarch64 architectures:
> Cortex-a78ae and Cortex-a76. I'm aiming for native compilation, where Cortex-a76's
> Target tasks can be exclusive to its host. I've tried editing the tag and
> host's "arch" argument from "aarch64" to "cortex-a76," but faced issues
> during mock's dnf install, fetching merely 'noarch' RPMs from build repo. I
> suspect it's because the RPM's 'Arch' written in the spec file is still
> 'aarch64' not matching 'Cortex-a76'?
>
> Currently, I manually use "assign-task" to designated host, post "koji
> build" for native compilation purpose.
>
> Is there a simpler way or something I'm missing?
>
>
> Your insights are greatly appreciated. Eagerly awaiting your guidance.
>
>
> Best Regards,
> Junyan CHEN
>
> [image: Ambarella AI Envisioned] <https://www.ambarella.com>
>
> *Junyan(Joe) CHEN*
>
> Software Engineer | SDK Team
>
> *Phone: *+86-021-60880608-265
>
> *Email: *jychena(a)ambarella.com <ypchang(a)ambarella.com>
>
> ------------------------------
> This email and attachments contain Ambarella Proprietary and/or
> Confidential Information and is intended solely for the use of the
> individual(s) to whom it is addressed. Any unauthorized review, use,
> disclosure, distribute, copy, or print is prohibited. If you are not an
> intended recipient, please contact the sender by reply email and destroy
> all copies of the original message. Thank you.
> _______________________________________________
> koji-devel mailing list -- koji-devel(a)lists.fedorahosted.org
> To unsubscribe send an email to koji-devel-leave(a)lists.fedorahosted.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/koji-devel@lists.fedorahoste...
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
--
Tomas Kopecek <tkopecek(a)redhat.com>
RHEL Build Development, RedHat
8 months, 1 week
A Koji plugin for building Flatpaks
by Owen Taylor
Over the last few months I've been working on a Koji plugin to build
Flatpaks directly on the Koji builder nodes, and have that working pretty
well now:
https://pagure.io/koji-flatpak
I've submitted a review request to get it in Fedora and hope to move
forward to getting it deployed on Fedora Koji. By removing OSBS from the
Flatpak building process, we can hopefully improve reliability and make the
build process more friendly to contributors.
A few notes:
* Most of the heavy lifting of building a Flatpak is done by using
flatpak-module-tools[1] installed *inside* a buildroot, but it also
directly imports flatpak-module-tools to avoid duplicating code for parsing
container.yaml files.
* The code style is more modern than koji - I targeted a minimum Python
version of 3.8. Type annotations are used liberally.
* I hit a problem that it's impossible to set "extra" information for an
image build using host.completeImageBuild(), but only with CGImport. I
didn't want to add the complexity of pretending to be a content generator,
so I hacked around it by including a pseudo-host method in the plugin to
add this information after the fact (
https://pagure.io/koji-flatpak/blob/main/f/koji_flatpak/plugins/flatpak_h...).
A Koji enhancement in this area would be nice.
* Builds end up with a pretty confusing set of log files - there's a new
flatpak.log which logs the actual Flatpak build process, but also all the
traditional mock_output.log, root.log, build.log, hw_info.log, etc, which
are *not* typically useful. Maybe some configurability in the
log-file-monitoring in BuildRoot.mock() would be useful.
[1] https://pagure.io/flatpak-module-tools/
8 months, 1 week
Associating "Target" with "Host(builder)" in Koji
by Joe (Jun-Yan) Chen
Dear Koji Team,
I hope this message finds you well. I am currently seeking guidance on how to associate a specific "Target" with its corresponding "Host(builder)".
I have two hosts (builders) with distinct aarch64 architectures: Cortex-a78ae and Cortex-a76. I'm aiming for native compilation, where Cortex-a76's Target tasks can be exclusive to its host. I've tried editing the tag and host's "arch" argument from "aarch64" to "cortex-a76," but faced issues during mock's dnf install, fetching merely 'noarch' RPMs from build repo. I suspect it's because the RPM's 'Arch' written in the spec file is still 'aarch64' not matching 'Cortex-a76'?
Currently, I manually use "assign-task" to designated host, post "koji build" for native compilation purpose.
Is there a simpler way or something I'm missing?
Your insights are greatly appreciated. Eagerly awaiting your guidance.
Best Regards,
Junyan CHEN
[Ambarella AI Envisioned]<https://www.ambarella.com>
Junyan(Joe) CHEN
Software Engineer | SDK Team
Phone: +86-021-60880608-265
Email: jychena(a)ambarella.com<mailto:ypchang@ambarella.com>
**********************************************************************
This email and attachments contain Ambarella Proprietary and/or Confidential Information and is intended solely for the use of the individual(s) to whom it is addressed. Any unauthorized review, use, disclosure, distribute, copy, or print is prohibited. If you are not an intended recipient, please contact the sender by reply email and destroy all copies of the original message. Thank you.
8 months, 2 weeks