On Fri, Nov 29, 2019 at 05:32:15PM -0500, Neal Gompa wrote:
Hey Neal. I'll try and answer these... note that this is just my
thoughts, I hope others will chime in and correct me if I am wrong.
Speaking of robosignatory, what's the state of affairs for
At Flock, I was assured by Patrick that he'd release a new Python
3-compatible Sigul that works with GnuPG 2.1 or higher. We still don't
have that, so it's *still* not possible for people to sign packages
and repos with Koji deployments...
The last time I brought this up (at the top of the year), I
proposed considering switching to obs-signd, since nothing has been
happening with Sigul. At that point, I was assured work was going on
here and also told that obs-signd is not capable of serving our needs.
So... now what?
I typed at Patrick a few weeks ago, and he was going to try and find
cycles to finish releasing sigul 1.0, so thats still the plan.
Note that he is no longer in the CPE team, so we may have to try and
arrange for him to get time to do this from his new management chain.
> Application Retirements
> Elections being moved to Communishift really soon! Stay tuned!
> Still no progress on kanban board last four weeks
> Jlanda is still hitting permission error in communishift
> Still working on running local instance
I'm confused how this is the first time we're seeing these issues. Do
we not have *any* apps in Communishift using PostgreSQL (or any
database for that matter) besides Fedocal?
No? Why would we.
I think I have fixed this issue, it was perms on the nfs server.
> Benson Muite is now working on OIDC authentication
> A PR will be created on Github to test if we can see the progress
> New PR from sebwoj - Porting to Fedora messaging is under review
> Still on track for December 1 modernpaste shutdown
> GDPR and privacy centric conversations with respect to application
> handovers have resulted in…..more conversations needed - shock :)
Can we please have fpaste.org
They will, for some versions of 'work'.
They will point to the centos pastebin. The old fpaste client won't
work against them.
> The team have been testing projects migration from repospanner to
> locally hosted git repositores on git.dev.centos.org
and come back
> with a migration script/plan to unblock RCM
Does this mean that the whole magical future plan of having multiple
distros' branches in src.fp.o and git.c.o is dead?
Nope, just regrouping I think.
> CentOS Stream
> Scoping meetings are still ongoing
What does this even mean!?
Disclaimer: I haven't been to any meetings on this.
I think this is just sorting out how much work on our side its going to
be to setup the infrastructure and workflows for centos streams.
> Bugzilla sync script has been resolved
> Email inviting to review its change has been sent
> New changes to src.fedoraproject.org
> Ability to set the anitya monitoring status directly in the UI
> Ability to adopt orphan (and not retired) packages directly in the UI
> New changes to Pagure on the horizon:
> New API endpoint to enable/disable git hooks
> Ability to set dist-git in the default assignee overrides for bugzilla
Can somebody please consider looking into supporting per-branch ACLs
in Pagure Dist-Git? It's become a problem that I'm too nervous to hand
out EPEL branches to people because they can do bad things to the
Fedora branches I care about...
But you can revert those changes and/or talk to them and/or remove them?
Also, question: is it supposed to be possible for people other than
the maintainer to request EPEL branches and force me to have them?
There was a thread on this on the devel list.
The process right now is not ideal... In pkgdb days the process was that
it was requested and the maintainers had 2 weeks to say ok, or reject.
It also wasn't ideal because pkgdb never actually notified anyone about
Somehow I wound up getting EPEL 8 branches for buildbot, and I
definitely did not ask for them. What's crap about this is that now
I'm stuck with Git branches I don't want in a configuration I didn't
ask for, with commits in there I definitely don't like. Thankfully,
there have been no builds, but it's still bad.
Please talk to the person who requested them and hopefully you can
either get them to move to your configuration or agree at least to
handle all epel stuff.
> EPEL 8 modularity
> Updates can now be created in bodhi staging!
> We are currently testing pushes/composes
> We are also testing epel8-playground-modules composes
Does anyone know how we're supposed to handle buildroot overrides with
modules (especially with Ursa Prime)? Everyone I ask seems to be
confused on whether that's even possible...
You mean you build module A and want it to be in the buildroot before
building module B? Or you build module A and want to build non modular
stuff against it?
At first at least, the process that makes the modular buildroot will be
a cron job, running based on how long it takes to make. So, it could be
you would need to wait for the next cron job run to see the new module
in the buildroot. If the cron jobs are spaced too much (but I hope we
can make them pretty often) we can have releng have a process to update
it on demand.
Also, are we using Ursa
Major or Ursa Prime for EPEL 8 modules?
Prime. Major was never deployed in fedora/epel, nor will it be.
> Aarch64 is now racked and networked
> New koji owner script was debugged
> Koji client was updated
> Koji was also patched for the --title option fix
I heard through the grapevine that we're supposed to be getting OIDC
support in Koji to replace the awkward Kerberos auth... Is that still
in the cards?
I hope so, but I haven't heard anything about it... is there a koji
Also, is there still a plan to do a visual refresh of
Koji to bring it in line with all the other web apps we have that have
been reskinned with the new standard Fedora Bootstrap 4 theme?
No idea there either. We should ask Ryan if thats on the roadmap.
Overall, you guys have been doing great work! Thanks for everything
and keep it up!
Thanks! Hopefully we are starting to get things more under control. ;)