koji-devel May 2017

koji-devel@lists.fedorahosted.org

11 participants
7 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

poll: Postgres and jsonb
by Mike McLean 17 May '17

17 May '17

We've been using json in the database more and more, but because not all versions of Postgres have special support for it, we've been storing it in text fields. Postgres 9.4 and up support a jsonb type that has some really nice features. It would be really nice for us to use in Koji. Koji could actually query based on structural data in a jsonb field, and even index on it. So, here's the Poll: Question 1: What version of Postgres are you using for your Koji instance(s) Question 2: How would you be impacted if Koji required 9.4 or greater? Note that Postgres 9.4 and 9.5 are available as software collections for RHEL6 and RHEL7.

7 7

Re: RFC: Content generator for module build service
by Ralph Bean 17 May '17

17 May '17

On Mon, Apr 24, 2017 at 05:06:47PM +0200, Stanislav Ochotnicky wrote: > On Mon 24 Apr 2017 04:56:05 PM CEST Jan Kaluža <jkaluza(a)redhat.com> wrote: > > On 04/24/2017 04:20 PM, Stanislav Ochotnicky wrote: > >> On Mon 24 Apr 2017 03:25:48 PM CEST Ralph Bean <rbean(a)redhat.com> wrote: > >>> On Mon, Apr 24, 2017 at 01:51:39PM +0200, Stanislav Ochotnicky wrote: > >>>> This is the first stab and what the mbs CG metadata output might look like: > >>>> https://paste.fedoraproject.org/paste/5ix-EZVVRkmqpSvCQKOw715M1UNdIGYhyRLiv… > >>> > >>> Just to clarify - in the "build" entry here, this is a build of the > >>> "nginx module". The "version" (which is 1) and the "release" (which is > >>> 2) are in koji terms, not MBS terms. > >>> > >>> The mapping between MBS and koji terms should look something like: > >>> > >>> MBS -> Koji > >>> --------------- > >>> name -> name > >>> stream -> version > >>> version -> release > >>> > >>> The only kicker I can see at the moment is the datatype of stream(MBS) > >>> versus version(Koji). The MBS stream is a string (master, or f26, or > >>> whatever). The Koji version... does it have to be an integer? > >> > >> Well the version even for rpms is a string. Usually semantic versioning > >> style thing - but not necessarily. Of course if you use something lime > >> rpmdev-vercmp on these mbs builds EVRs it might make things weird. I.e.: > >> rpmdev-vercmp master-20 version2-10 > >> master-20 < version2-10 > >> > >> But I think that's OK. > >> > >> One thing however - can stream contain dash? Because version string > >> cannot. I'd be tempted to just replace it with underscore hoping there > >> won't be both :-) > > > > We currently set the the dist-git branch as a stream value. From MBS > > point of view, there is no problem with dash in a stream name and I > > presume there will dashes in a stream name if we don't decide you cannot > > use dash in dist-git branch name for modules. I would not like to > > restrict that if there is no real reason to do that. > > > > How much user-visible will the content generator data be? Can for > > example user search for module in Koji by typing its > > name-stream-version? In that case, I would start thinking about > > restricting the branch so it does not contain dash, because people will > > not replace dash with underscore when searching Koji. > > Well this part of content generator is very visible - it's part of the > build NVR after all. So things like API calls getBuild(nvr) would be > affected by it. And the NVR will need to be input as part of shipping > update in Bodhi for example. > > I would guess people *will* use dash in the stream name unless they are > prevented from doing it? From discussion in IRC today (paraphrasing others): We can use a new "build type" for this ("module"). With a new build type (btype) we can: - store the original MBS name-stream-version in koji as extra information, preserving dashes - while the build has a koji-reformatted name-version-release with dashes converted to underscores. There is precedent for this in the way Maven GAV is mapped to NVR. In the CG metadata provided by MBS, btype specific data goes into extra->typeinfo->BTYPENAME for build and archive and this how koji knows the btype. So, the MBS would need to define the mapping from NSV to NVR (hyphens become underscores, etc.) and use the mapped NVR to identify the build. The original, unmodified NSV would be recorded in the "extra" field of the build. (Archives can only have one btype. builds btypes must match their component archives. btype info can technically be {}) Is that sufficient to solve this mapping problem? Are there any other outstanding questions you need resolved, stano? (Sorry for this getting splintered across multiple lists...)

3 7

Questions about upcoming python 3 changes in Koji
by Kate Carcia 10 May '17

10 May '17

Hello, I have some questions about upcoming changes in Koji related to porting to python 3. Since Fedora rel eng depends on this change for porting about 80% of our rel eng scripts over to python 3, we wanted to reach out with some questions in anticipation of this change. First, we are wondering if these changes will affect how we interact with the Koji library and cli. For example, should we anticipate function signatures changes, different return values, etc.? Second, is the Python2-Koji-Library guaranteed to continue to have compatibility with the Python3-Koji-Server? As noted by one of our developers, Rob Marshall (who I've cc'ed on this email), Python3-Koji-Server is supposed to drop in mid-July. We are currently planning to have some overlap where we use the Python2-Koji-Library to talk to the Python3-Koji-Server. We are concerned our calls will fail due to the mismatch between the Python versions of the calling API versus the server. Best, Kate Best, Kate ------------------------------ Project Manager *|* RCM *|* Westford, MA Office: +1 (857) 770-0448 *|* IRC: katec

2 2

Questions about upcoming python 3 changes in Koji
by Kate Carcia 08 May '17

08 May '17

Hello, I have some questions about upcoming changes in Koji related to porting to python 3. Since Fedora rel eng depends on this change for porting about 80% of our rel eng scripts over to python 3, we wanted to reach out with some questions in anticipation of this change. First, we are wondering if these changes will affect how we interact with the Koji library and cli. For example, should we anticipate function signatures changes, different return values, etc.? Second, is the Python2-Koji-Library guaranteed to continue to have compatibility with the Python3-Koji-Server? As noted by one of our developers, Rob Marshall (who I've cc'ed on this email), Python3-Koji-Server is supposed to drop in mid-July. We are currently planning to have some overlap where we use the Python2-Koji-Library to talk to the Python3-Koji-Server. We are concerned our calls will fail due to the mismatch between the Python versions of the calling API versus the server. Best, Kate ------------------------------ Project Manager *|* RCM *|* Westford, MA Office: +1 (857) 770-0448 <(857)%20770-0448> *|* IRC: katec

1 0

Re: RFC: Content generator for module build service
by Ralph Bean 05 May '17

05 May '17

For the curious, the preliminaries of the MBS content generator can be found here: https://pagure.io/fm-orchestrator/pull-request/522#request_diff (We'll likely need some refactoring based on feedback in this thread.)

1 0

legacy-py24 branch
by Mike McLean 02 May '17

02 May '17

After looking over the things we expect to land in 1.13, I realized that none of them are really required for legacy users, so I've gone ahead and created a separate branch for py24 legacy systems (i.e. RHEL5). This branch is client and builder only. Everything else has been removed. Work on this branch will be as-needed, and it will be outside of our regular releases. With that done, we can now target python 2.6+ on the master branch. This will allow us to speed up our py3 compatibility effort, and should ease some contributor pain.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

koji-devel May 2017