koji in PiPy/support of setup.py
by Pavol Babincak
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
5 years, 8 months
dropping old ssl support
by Michael McLean
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)
5 years, 10 months
Koji: How to handle internal package moved to external repo?
by Dustin C. Hatch
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
5 years, 10 months
broke my Koji and now stuck with "BuildError: Unknown origin..."
by John Florian
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?
5 years, 11 months
