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 Sigul[0]? > 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[1]), 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 > > Elections being moved to Communishift really soon! Stay tuned! > > > > Fedocal > > Still no progress on kanban board last four weeks > > https://teams.fedoraproject.org/project/fedora-calendar/kanban > > > > Jlanda is still hitting permission error in communishift > > https://pagure.io/fedora-infrastructure/issue/8274 > > 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. > > Nuancier > > 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 > > > > Pastebin > > 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 and paste.fedoraproject.org still work? They will, for some versions of 'work'. They will point to the centos pastebin. The old fpaste client won't work against them. > > CentOS: > > 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. > > > > > Misc > > > > Bugzilla sync script has been resolved > > Email inviting to review its change has been sent > > > > New changes to src.fedoraproject.org deployed: > > Ability to set the anitya monitoring status directly in the UI > > Ability to adopt orphan (and not retired) packages directly in the UI > > > > Yay! > > > 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 those requests. > Somehow I wound up getting EPEL 8 branches for buildbot[2][3], 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. > > [2]: https://pagure.io/releng/fedora-scm-requests/issue/19857 > [3]: https://pagure.io/releng/fedora-scm-requests/issue/19856 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 > > > > > > Koji > > 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 ticket? > 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. ...snip... > > 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. ;) kevin
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx
