Koji container-based dev environment
by Tomas Kopecek
I've finally been pushed to clean up the codebase and publish it. It is a
very lightweight dev environment for debugging koji. It can spawn
hub/builder/kojira and have CLI tied to that. Most image-related tasks
can't be run in this setup and require a separate more-privileged builder.
But for most development tasks it is quite sufficient. Nevertheless, it is
not a production-ready environment - treat it really as a dev one.
https://github.com/tkopecek/koji-container-dev
--
Tomas Kopecek <tkopecek(a)redhat.com>
RHEL Build Development, RedHat
1 month, 1 week
Set a nonstandard target architecture in Koji
by Joe (Jun-Yan) Chen
Dear Koji development team,
Is it possible to set a nonstandard target architecture in Koji while using a standard architecture repository for bootstrapping?
Our purpose is to native build src.rpm in several architectures such as "cortexa76", "cortexa78ae", and want to distinguish them, instead of all in category of "aarch64".
By modifying 'redhat-rpm-config'. Now, when we run "rpmbuild -ba --target=cortexa76", the "buildroot" name, package names, and "optflags" can be customized successfully.
We would like to bring these changes to the Koji build system by adding our 'redhat-rpm-config' package to the build groups and editing Koji's "build tag", "build host", and "external-repo" with '--arches=cortexa76'.
The first difficulty we encountered is that there are currently no RPMs built with the macro 'cortexa76', so there is no repository to bootstrap the chroot environment. To address this, I hacked in "koji/__init__.py" with
urls[0] = urls[0].replace("cortexa76", "aarch64")
This ensures that the repository URL in the mock config file, which is automatically generated by Koji, remains as "aarch64". Meanwhile, the options "_target_arch" and "host_cpu" can still be set as "cortexa76", and it works.
However, followed with a series of errors in subsequent functions of the mock process, such as "check rpm list", etc. These errors are caused by the complex logic between several variables related to "arch". It has occurred to me that this hacking method may be unstable, and may cause compatibility issues.
Therefore, I would greatly appreciate it if there were any functions within Koji or if there were any methods available that could address the need to set a nonstandard architecture in Koji while using a standard architecture repository for bootstrapping?
Best,
Junyan Chen
**********************************************************************
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.
1 month, 2 weeks
Switching from IRC to Matrix?
by Neal Gompa
Hey folks,
Fedora has been generally moving from IRC to Matrix for the past
couple of years and we've seen a lot more engagement and interest in
our channels since that transition started.
I created a Matrix room for people to talk about Koji stuff on the
Fedora server: https://matrix.to/#/#koji:fedora.im
At the very least, it makes sense to have a room there for people to
talk to Koji folks. I recently moved Pagure from IRC to Matrix for
similar reasons:
https://pagure.io/pagure/c/9762a035ed9bbe19317294e76fbae9f2e6b1e6bf
Our IRC channel is pretty dead right now, so I figure it wouldn't be
that bad to do an announcement and a cutover. Alternatively, it can
just be another chat channel.
What do y'all think?
--
真実はいつも一つ！/ Always, there's only one truth!
1 month, 2 weeks
