koji-devel

koji-devel@lists.fedorahosted.org

2 participants
320 discussions

Koji 1.35.2 release
by Tomas Kopecek 11 Mar '25

11 Mar '25

Koji 1.35.2 is out. Another minor update. So, the update should be straightforward (no db schema changes) and safe for everybody. If you've installed 1.35 or 1.35.1, an update is recommended as it contains few minor regression fixes and improvements to the repo-on-demand mechanism introduced in 1.35. As it is a longer time from latest minor release, this one included more fixed issues than it is standard (30 issues). Thanks to everyone who contributed! You can read full release notes here: https://docs.pagure.org/koji/release_notes/release_notes_1.35.2/ A few more important changes are part of this release: #4228 - wait-repo behaves more compatible by default #4207 - always preserve latest repo symlink #4277 - separate thread for repo requests, so they are handled faster You can view the 1.35.2 roadmap at https://pagure.io/koji/roadmap/1.35.2/ For the current roadmap, see https://pagure.io/koji/roadmap You can download this and other releases at https://pagure.io/koji/releases or PyPi. See you again with major release 1.36 in a few months! -- Tomas Kopecek <tkopecek(a)redhat.com> RHEL Build Development, RedHat

3 3

How to use module packages compiled through MBS in conjunction with Koji channels？
by houlifei＠uniontech.com 16 Dec '24

16 Dec '24

How to integrate module packages compiled through MBS with Koji channels? I bound the target and channel in hub.conf, but MBS automatically generates tags during the build process and cannot be bound to the specified channel. Can we use other conditional restrictions to achieve the goal of binding to the channel? I tried to restrict the conditions through the organization to which the repository belongs, but I was unsuccessful. I sought help

1 0

Koji CVE-2024-9427 releases
by Michael McLean 08 Oct '24

08 Oct '24

Today we have released security updates for Koji to address CVE-2024-9427, an xss vulnerability in the Koji web ui. These updates cover Koji releases from the past year. They are: 1.35.1 1.34.3 1.33.2 You can download these and other releases at https://pagure.io/koji/releases While we do not believe that this vulnerability can be used to submit an action or make a change in Koji, it is still a serious issue and we recommend applying this update promptly. For further information see: https://docs.pagure.org/koji/CVEs/CVE-2024-9427/ https://pagure.io/koji/issue/4204 Many thanks to all those that helped find and address this issue!

1 0

Koji 1.35.0 release
by Tomas Kopecek 17 Sep '24

17 Sep '24

Koji 1.35.0 is out. As usual - Thanks to everyone who contributed! Once again it was a longer time from the last release as developers are busy with other projects. Anyway, this release brings a performance boost in the form of rewritten repo regeneration mechanism which is now more on-demand than brute-force repo regeneration it was before. Most regeneration logic was moved from kojira to hub which provided a lot of versatility. Especially big deployments which are running thousands of repo regenerations daily will benefit from this. Even smaller deployments should see better waiting times e.g. for sidetag repos. Separate documentation of new mechanism is at https://docs.pagure.org/koji/repo_generation/ For details of these features check release notes: https://docs.pagure.org/koji/release_notes/release_notes_1.35 Other highlights: * #3944 Backup signature headers in delete_rpm_sig * #3974 dnf5 builder compatibility * #3969 SCMPolicy plugin for more granular policies related to (git) source * Multiple Kiwi updates for Fedora 41 image builds 55 pull requests You can view the 1.36 roadmap at https://pagure.io/koji/roadmap/1.36 For the current roadmap, see https://pagure.io/koji/roadmap You can download this and other releases at https://pagure.io/koji/releases Tomas Kopecek <tkopecek(a)redhat.com> -- Tomas Kopecek <tkopecek(a)redhat.com> RHEL Build Development, RedHat

1 0

Re: Customizing '--target' Option for 'rpmbuild -bb' per Tag in Koji
by Michael McLean 09 Jul '24

09 Jul '24

Koji does not run rpmbuild directly. It runs mock. Koji passes --target $arch to the mock command. The arch value is the arch that koji is currently building for. The list of arches to build for is primarily determined by the archlist for the build tag. E.g. `koji edit-tag --arches="arch1 arch2"`. Mock should be forwarding this target value through to rpmbuild. On Thu, Jun 6, 2024 at 6:58 AM Joe (Jun-Yan) Chen <jychena(a)ambarella.com> wrote: > Hi koji-devel team, > > > I hope everything is going well with you. > > Is there a way to customize the '--target' option for the 'rpmbuild -bb' > command specifically per tag in Koji? > > The 'mockbuild/backend.py' says 'rpmbuild_arch' is assigned to > '--target'. I've tried tuning Mock's behavior per tag in Koji, but the > available options seem insufficient. > Also, I attempted to use "koji edit-tag cortex-a53 -x > mock.forcearch='cortexa53'", but it affects multiple values, which is not > desired. > > Do you have any recommendations on how to achieve this more precisely? > > > > 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.fedorahosted.… > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue >

2 3

Customizing '--target' Option for 'rpmbuild -bb' per Tag in Koji
by Joe (Jun-Yan) Chen 06 Jun '24

06 Jun '24

Hi koji-devel team, I hope everything is going well with you. Is there a way to customize the '--target' option for the 'rpmbuild -bb' command specifically per tag in Koji? The 'mockbuild/backend.py' says 'rpmbuild_arch' is assigned to '--target'. I've tried tuning Mock's behavior per tag in Koji, but the available options seem insufficient. Also, I attempted to use "koji edit-tag cortex-a53 -x mock.forcearch='cortexa53'", but it affects multiple values, which is not desired. Do you have any recommendations on how to achieve this more precisely? 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.

1 0

Koji 1.34.1 release
by Tomas Kopecek 30 May '24

30 May '24

Koji 1.34.1 is out. Another minor update. So, the update should be straightforward (no db schema changes) and safe for everybody. If you've installed 1.34, an update is recommended as it contains few minor regression fixes and improvements to the scheduler introduced in 1.34. Thanks to everyone who contributed! You can read full release notes here: https://docs.pagure.org/koji/release_notes/release_notes_1.34.1/ A few small changes are part of this release: #4032 - Improving scheduler planning capability especially for noarch/exclusivearch packages. #4056 - Fix for scheduler deadlock issues. They are not critical, but polluting kojid’s log. #4043 - List only limited set of records in scheduler-info CLI command #4012 - Better handling of content removal #4037 - Fixing 1.34 problem with CG imports with error logs. You can view the 1.34.1 roadmap at https://pagure.io/koji/roadmap/1.34.1/ For the current roadmap, see https://pagure.io/koji/roadmap You can download this and other releases at https://pagure.io/koji/releases or PyPi. See you again with major release 1.35 in ~two months! -- Tomas Kopecek <tkopecek(a)redhat.com> RHEL Build Development, RedHat

1 0

Koji 1.34.0 release
by Tomas Kopecek 24 Jan '24

24 Jan '24

Koji 1.34.0 is out. As usual - Thanks to everyone who contributed! There was a bigger gap between releases in this cycle, but we hope we will return to regular cadency with the next release. On the other hand, there is a good reason for this, so we can introduce two big changes. First one is that we've restructured the scheduler and moved its logic to the hub from the builders. It should be mostly invisible to the users. Probably the only place where you can hit it are large queues which will not impact the whole koji performance. But that was probably the most tricky part before we can incrementally introduce further enhancements such as policies with multiple outcomes and starting to dismantle the channel/pool system for the builders. In the future build could request specific resources instead of being started in the predefined channel. Second big thing which is way more visible are Draft builds. This is the concept which fills the gap between scratch and regular builds. Draft builds ARE regular builds which have NVRs (their release part) slightly modified, so it is possible to have multiple builds from one spec file version. When It is decided which of these variants is valid (passes tests, release policies, etc.) it will be "promoted" to NVR with unmodified release and will become the only valid build for the NVR. For details of these features check release notes: https://docs.pagure.org/koji/release_notes/release_notes_1.34 Other highlights: * #3846 - full json support for CLI "call" command * #3836 - support for sw_64 and loongarch64 * #3842 - improve performance for newRepo tasks (sometimes createrepo is not needed) * #3843, #3920 - schema migration scripts were moved to better location * #3850 - group permission inheritance * #3841 - trigger newRepo for new sidetags immediately 58 pull requests You can view the 1.35 roadmap at https://pagure.io/koji/roadmap/1.35 For the current roadmap, see https://pagure.io/koji/roadmap You can download this and other releases at https://pagure.io/koji/releases -- Tomas Kopecek <tkopecek(a)redhat.com> RHEL Build Development, RedHat

2 1

Koji container-based dev environment
by Tomas Kopecek 30 Oct '23

30 Oct '23

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 0

Set a nonstandard target architecture in Koji
by Joe (Jun-Yan) Chen 26 Oct '23

26 Oct '23

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 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

koji-devel