koji-devel October 2015

koji-devel@lists.fedorahosted.org

13 participants
10 discussions

[PATCH] set keepcache=1 in the mock config so that dnf matches yum's behaviour
by Dennis Gilmore 30 Oct '15

30 Oct '15

supermin needs access to the pristine RPMs from which the buildroot is installed, in order to grab the /etc (configuration) files into the libguestfs appliance (the binaries etc are not baked into the appliance for obvious security/maintainability reasons). For years these came from the yum cache, but problem: dnf defaults to keepcache=0 and so doesn't save these RPMs. Signed-off-by: Dennis Gilmore <dennis(a)ausil.us> --- koji/__init__.py | 1 + 1 file changed, 1 insertion(+) diff --git a/koji/__init__.py b/koji/__init__.py index 031adb0..3842a9d 100644 --- a/koji/__init__.py +++ b/koji/__init__.py @@ -1327,6 +1327,7 @@ retries=20 obsoletes=1 gpgcheck=0 assumeyes=1 +keepcache=1 # repos -- 2.5.0

1 0

[PATCH] Use keepcache=1 in yum/dnf.conf.
by Richard W.M. Jones 30 Oct '15

30 Oct '15

Supermin builds very tiny appliances as described here: http://libguestfs.org/supermin.1.html To do this, it needs to have access to the original /etc files [technically, any file marked %config by RPM] since those are the only files that could be modified by the administrator, so those are the only ones we need to save in the appliance at build time. When not running under Koji, it gets these by downloading the RPMs (using yumdownloader or the dnf equivalent), unpacking them and extracting the /etc files it needs. However this doesn't work when running under Koji because there is no network access and no root access (so we can't just read the unmodified files from /etc). This is of course as it should be. Since Koji doesn't provide an official way to get to the pristine RPMs that were used to build the buildroot, we grabbed them from the yum cache. But since the move to dnf in Fedora Rawhide, this no longer works as dnf defaults to keepcache=0 (which is not a great decision for plenty of other reasons, but dnf upstream show no sign of changing this despite many asking). Anyhow, this patch takes the path of least resistance and just overrides the default so it's the same as it was in yum. It would be nice to have a way to access pristine build RPMs in Koji/mock, but that's probably a much larger patch. Rich.

1 2

koji 1.10.1
by Mike McLean 30 Oct '15

30 Oct '15

Just a minor release to pull in some of the fixes and changes since 1.10. $ git log --oneline koji-1.10.0..master 28a1f1e version 1.10.1 9e81597 docs: Document how to write a plugin 86fdd77 Avoid multiple updates to same rows in taskSetWait 2ae4a0a fix int encoding in list_rpms 4bb191c check for tag existence in add-pkg 37c6eed use encode_int on rpm sizes 6a075b0 Remove koji._forceAscii. 4264719 Resolve the canonical hostname when constructing the Kerberos server principal ae71801 add support for Image Factory generation of VMWare Fusion Vagrant boxes 9103bda Be more careful when detect cert-expiry exceptions. 875b243 don't omit debuginfos on buildinfo page 94d95cb correct error message in fastUpload 8fe7135 cli: rename download-scratch-build to download-task 4ec6cd3 koji cli: add download-scratch-build command ab0b2e4 Better catch SSL errors 4d296f1 Check task method before trying to determine "scratch" status.

1 1

display state of package generation on KOJI
by Joachim Backes 27 Oct '15

27 Oct '15

Hi Kojis, sometimes I'm searching for new packages on KOJI, for example new kernels, but I see only a "Finished" column (beside others) on the specific website. It would be helpful for me if the "Finished" column could display a little bit more: The time of *starting* the package generation and the time when the generation has *finished* (with/without error), so one could guess the remaining time of package generation. I would be grateful for such an improvement. Kind regards Joachim Backes -- Fedora release 23 (Twenty Three) Kernel-4.2.5-300.fc23.x86_64 Joachim Backes <joachim.backes(a)rhrk.uni-kl.de> http://www-user.rhrk.uni-kl.de/~backes/

2 2

[koji PATCH 1/2] koji-shadow: use workpath consistently
by Dan Horák 27 Oct '15

27 Oct '15

--- util/koji-shadow | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/util/koji-shadow b/util/koji-shadow index 3b62776..ce88a63 100755 --- a/util/koji-shadow +++ b/util/koji-shadow @@ -436,7 +436,7 @@ class TrackedBuild(object): print "Downloading %s" % url #XXX - this is not really the right place for this fsrc = urllib2.urlopen(url) - fn = "/tmp/koji-shadow/%s.src.rpm" % self.nvr + fn = "%s/%s.src.rpm" % (options.workpath, self.nvr) koji.ensuredir(os.path.dirname(fn)) fdst = file(fn, 'w') shutil.copyfileobj(fsrc, fdst) -- 2.4.3

1 1

Proposal for some Project Updates/Changes
by Adam Miller 21 Oct '15

21 Oct '15

Hello all, I wanted to make a few suggestions/proposals to the Koji project to get feedback. First off, I'd like to propose that koji officially move out of FedoraHosted and into pagure[0] so that people can easily fork, create topic branches and open pull requests for interactive peer review. In the event that is acceptable I would also like to propose that all documentation move out of the Fedora Wiki and move into the koji git repo itself under the docs directory either formatted as Sphinx[1] reStructured Text, or markdown[2]. This could either be hosted directly in pagure.io or in readthedocs.org[3]. >From there I would like to suggest a formal website for koji, maybe koji.io or similar. I don't really have a preference or suggestion on the specific url. This website would be a simple landing page for all information that someone interested in Koji would be looking for. It would briefly explain what koji is, provide references on how to use it, deploy it, how to administer it, and how get involved in development of it. My idea is that the website itself would be a static site that is generated using something like pelican[4] or nikola[5], the source code for the site would also live in koji's git repository such that all content would be in a central location and could even be shared between the site and docs where appropriate. We could later get clever and have the website be updated automatically when a pull request gets merged that updates it's content, but I don't want to get ahead of myself. In the event that is acceptable, I would also like to propose a "recommended developer workflow" and introduce the use of the tito[6] utility for koji to assist in both the release tasks but also for iterative development and/or eventual CI without giving up the standard rpm install process. I have started mocking up what I think would be a good starting place for a workflow, it's currently a work in progress and doesn't actually function as described for reasons I don't yet know (koji-hub and I are fighting with the database) but before chewing up more time working on it I wanted to make sure that this is even something that the group at large is open to. https://github.com/maxamillion/koji-dev Eventually if this developer workflow (or really any documented developer workflow) was deemed as "recommended" by the group, I would like to also have it live within the koji git repository such that it can be a part of the official documentation for new and potential contributors on how to get started working with koji development and be highlighted on the (new) proposed website. This is effectively a multi-part "step 1", as I would like to build on top of this and move towards having CI for the project but getting things in a place where we can easily facilitate iterative developer workflows is something that I consider as a prerequisite. I'm definitely looking forward to feedback, thanks for reading this far :) -AdamM [0] - https://pagure.io/ [1] - http://sphinx-doc.org/ [2] - https://en.wikipedia.org/wiki/Markdown [3] - https://readthedocs.org/ [4] - http://blog.getpelican.com/ [5] - https://getnikola.com/ [6] - https://github.com/dgoodwin/tito

6 13

Adding liveimg-squashfs support to koji
by Fabian Deutsch 16 Oct '15

16 Oct '15

Hey, I'm using squashfs images quite often to either install them using anaconda or boot them directly using dracut. It would be great to get some input on the following patch, which is surprisingly small: https://github.com/fabiand/koji/compare/master...liveimg I see two open issues: - Extract the filesystem from the raw disk image (a liveimg squashfs just contains the raw fs image, not a disk image) - Add support to handle this new archive type in the schem upgrade of the database (I need some help with that). Greetings fabian

2 1

Merging primary and secondary kojis into one?
by Marcin Juszkiewicz 13 Oct '15

13 Oct '15

I probably use koji in a bit different way than Fedora maintainers as I do not concentrate on few packages but instead check which ones are broken (mostly on aarch64 secondary architecture). My workflow goes like that: 1. package "xyz" fails on aarch64 2. check logs to find out is it dependency or build issue 3. check how situation on primary look 4. check how it looks on other secondary architectures 5. check bugs reported against package (there could be fix) 6. do local build 7. work on fixing 8. create patch 9. do scratch build on primary/secondaries 10. provide patch via bugzilla/irc/git So the question is: are there plans to integrate primary and secondary architectures into one koji? This would allow to present state of each architecture/tag: packagename ----------------------------------------------------------------------- x86-64 | OK 1.2-3.fc24 | FAIL 1.1-7.fc23 | OK 1.1-2.fc22 i686 | OK 1.2-3.fc24 | FAIL 1.1-7.fc23 | OK 1.1-2.fc22 armhf | OK 1.2-3.fc24 | FAIL 1.1-7.fc23 | OK 1.1-2.fc22 aarch64 | FAIL 1.2-2.fc24 | OK 1.1-6.fc23 | OK 1.1-2.fc22 ppc64 | OK 1.2-1.fc24 | FAIL 1.1-7.fc23 | OK 1.1-2.fc22 ppc64le | OK 1.2-1.fc24 | FAIL 1.1-7.fc23 | OK 1.1-2.fc22 s390 | OK 1.2-3.fc24 | FAIL 1.1-7.fc23 | OK 1.1-2.fc22 s390x | OK 1.2-3.fc24 | FAIL 1.1-7.fc23 | OK 1.1-2.fc22 Then both package maintainers and architecture maintainers will see how situation looks like. All newer NVRs would wait in a queue like it is now with koji-shadow setups. And with links to builds being present in this table it would be easier to follow ftbfs situations. How it looks now? Koji web interface provides list of completed or failed builds. If I see that 'somename' failed then I have to check all builds of it to check did it completed in newer NVR or not. Or write scripts which will follow fedmsg and query all koji instances (there are at least two such on my hard drive).

2 1

fixing deadlock issue in chainmaven
by Mike McLean 09 Oct '15

09 Oct '15

This patch works around a deadlock issue that can occasionally happen with chainmaven builds if the hub is using an older version of postgres.

3 4

Koji git hosting and Pagure
by Ken Dreyer 09 Oct '15

09 Oct '15

I guess Koji is still hosted at https://git.fedorahosted.org/cgit/koji Can we move this to https://pagure.io/ ? (I see there's a https://pagure.io/koji already, maybe we could move that? or is there some other solution?) Pagure supports pull requests similar to GitHub, has a nice UI, et - Ken

3 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

koji-devel October 2015