I saw mention of FPO's rollout of new koji hubs and builders and am
wondering does that mean integration is now possible again with sigul?
If so, are any special side repos for special builds necessary? Is it
best to deploy all of koji and sigul both on F35 or is there some other
combination that works better or is required?
On 2021-11-16 10:36, John Florian wrote:
On 2021-11-11 18:38, Kevin Fenzi wrote:
> On Thu, Nov 11, 2021 at 09:14:56AM -0500, John Florian wrote:
>> What is the recommended solution for this these days? What is
>> I presently have a setup using Sigul on CentOS 7 but that's leading to my
>> current problem of being unable to upgrade anything. I can't find anything
>> workable with CentOS 8, meanwhile my Koji Hub is stuck at 1.21.1 because I'm
>> unaware of any newer builds via epel7. My Koji Builders are now stuck at
>> Fedora 33 because tasks fail if they have a newer version of Koji than the
> koji has moved to python3, so I can't update epel7 koji until I move it
> to python3. There's still some prereq packages needed:
> I keep wanting to work on this, but have had no time. ;(
> Perhaps with holidays up soon I can finally get to it.
Please let me know if I can be of any help. I do Python all day and
have been under the hood of koji a fair bit, but sigul much less.
Like everyone else, I'm always busy, but I like to help where I can,
even if it's just testing or writing docs.
>> My attempts at moving Sigul to CentOS 8 Stream have just led to one bug
>> after another using the only build I could find, located
>> I've fumbled my way through a few fixes and would be happy to contribute
>> when I can or, at least, report bugs. However, whenever I go to
, the apparent upstream for the project, I see the
>> last commit as 10 months ago, the last comment on any issue as 7 months ago,
>> no issues closed, no PRs merged. Is it dead?
> it's... sleeping. :)
> The primary developer, Patrick is busy on other stuff and hasn't had
> much time for it lately.
That's fair. We all have fires to put out and I'm not going to tell
anyone which fire is bigger. I saw he's put a lot of work into
improvements and I've been hoping to benefit from those, but ... (below)
> We are using a el8 version from our infra tags:
I found that and have tried to use it, but without docs for migrating
the schema I wasn't sure how to populate the new keys.keytype field
that didn't exist back with sigul-0.101-1.el7. (The new field was
preventing a simple dump & load.) I thought I'd be clever and `sigul
new-key tempkey` to see what value a brand new key would have and
mimic that by editing a data dump from the old server before importing
into the new server. However, that failed, first with an error because
the variable key_name was undefined. I took a reasonable guess at a
patch for that problem but then ran into a unique constraint error
from the database. Since the project is "sleeping" I just now created
to report this problem, but am
confounded how fpo is making this work.
> We don't have it in epel8 because python-nss was dropped there (and
> upstream). Patrick plans to re-write things so it doesn't use python-nss
> anymore, but hasn't yet done so.
> tracks sigul in epel8.
> Sorry this is such a mess. ;(
No apologies needed, it's FOSS. I do really appreciate the effort of
all involved and the difficulty of taming so many finicky parts to
> buildsys mailing list --buildsys(a)lists.fedoraproject.org
> To unsubscribe send an email tobuildsys-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
> Do not reply to spam on the list, report it:https://pagure.io/fedora-infrastructure
buildsys mailing list --buildsys(a)lists.fedoraproject.org
To unsubscribe send an email tobuildsys-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/
Do not reply to spam on the list, report it:https://pagure.io/fedora-infrastructure