koji-devel July 2017

koji-devel@lists.fedorahosted.org

5 participants
5 discussions

koji in PiPy/support of setup.py
by Pavol Babincak 04 Oct '17

04 Oct '17

Hi, I'm using koji as a python package in my scripts. Usually I develop them inside of a virtual environment. I do not use system packages[1] in virtualenv. Currently I'm not able to install koji and it dependencies inside virtualenv easily. Having koji in PiPy would help me. That way I can just specify it in my requirements.txt or in install_requires of my setup.py. I *guess*[2] one way to do that is to have setup.py in koji code and add some extra steps as part of the release process to publish it there. What do you think about this? For some time now I use my own setup.py. I guess it is not ready for PR so I'd love to see comments on this as well: https://pagure.io/fork/pbabinca/koji/blob/setup_WIP/f/setup.py [1] Among other reasons I'd like to have environment isolated from the system as much as possible. [2] I have never maintained package on PiPy. -- Pavol Babincak

8 12

dropping old ssl support
by Michael McLean 31 Jul '17

31 Jul '17

See: https://pagure.io/koji/issue/467 I'd like to drop the old ssl code from Koji. We've been using python-requests for a couple releases, which is just a better all around approach. [note: we'll still keep the support on the legacy-py24 branch, since requests does not support py24] So, currently planning on dropping this in 1.14. Tomas has the PR here: https://pagure.io/koji/pull-request/498 If this is going to cause you trouble, please speak up now. (Though I really doubt it will cause anyone problems, as you have to go fairly out of your way to hit that code path)

3 7

Koji: How to handle internal package moved to external repo?
by Dustin C. Hatch 19 Jul '17

19 Jul '17

I have encountered a situation where a newer version of package I used to build in my instance of Koji is now provided by an external repository. Until recently, everything has worked fine because the package was only a runtime dependency, so as long as the external repository was configured in Yum, the newer version would be installed. Now, though, that package, specifically the new version of it, is needed at build time, and I cannot figure out how to make this work. Since there is a build of the package tagged, via inheritance, into my build tag, Koji always prefers that version, even though it is older than the version in the external repository. I have tried blocking the package, but this makes it unavailable entirely. Is there any way I can get around this problem. The only thing I can come up with is to remove the inherited tag and copy the builds in it directly into my new tag, but I am hoping there is a better or simpler way. Thanks, -- ♫Dustin

1 0

Silly milestones
by Michael McLean 11 Jul '17

11 Jul '17

Fedora's Koji instance just passed the twenty million task mark. https://koji.fedoraproject.org/koji/taskinfo?taskID=20000000 And they are also getting near the one millionth build id.

3 3

broke my Koji and now stuck with "BuildError: Unknown origin..."
by John Florian 07 Jul '17

07 Jul '17

I was applying yum updates today and partway through those on my first builder I realized I had forgotten to disable it -- Bad admin, bad!. I rushed to do that while yum was still busy, but I suspect I was too late. Or perhaps this has nothing to do with my problems, but I sure suspect it. Regardless, I have a package which builds for my f24 target perfectly yet the same now fails every time for my f25 target (though which was previously never a problem). I discovered where the exception is raised in /usr/sbin/kojid and modified this line slightly to provide better info. The line now looks like: raise koji.BuildError, "Unknown origin for %s: ext_url=%r localtail=%r" % (key, ext_url, localtail) The error I see is: BuildError: Unknown origin for python3-mdct-6.0.0-1.fc25.noarch: ext_url='file:///var/tmp/koji/tasks/937/40937/repo_8178_premerge/' localtail='/repo_8179_premerge/' Thus the condition for internal rpms which avoids raising this exception is not met because localtail has 8179 versus the ext_url which has 8178 -- off by one. What do I need to investigate/do to rectify this?

1 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

koji-devel July 2017