Pyramid 2.0 update proposal for F38
by Mattia Verga
As you may have read in the announcement on the devel mailing list, I've
started a change proposal about bumping Pyramid to version 2.0 for F38.
I cross-announce here because Pyramid and its dependencies are mostly
maintained by infra-sig and I don't want to bypass main-admins, but I
think it's time to move forward (and I have some projects about using
pyramid-openapi3 to provide REST APIs in Bodhi which will need Pyramid 2).
I intend to upgrade Pyramid and rebuild dependent packages also updating
spec files to latest packaging guidelines and possibly upgrade packages
to the latest versions. The list of packages is:
* python-pyramid - Maintained by kevin / infra-sig
* bodhi-server - Maintained by humaton
* python-cornice - Maintained by hguemar / python-packagers-sig
* python-pyramid-fas-openid - Maintained by abompard / infra-sig
* python-pyramid-mako - Maintained by kevin / infra-sig
* python-pyramid-tm - Maintained by kevin / infra-sig
* python-pyramid_sawing - Maintained by abompard
The dependent packages rebuild is not really needed, but it will ensure
that the tests will not fail with Pyramid 2.0. In fact,
python-pyramid-mako is the only one which needs an upgrade to be
compatible with Pyramid 2.0.
I have set up a COPR repository to test the upgrade:
Let me know if there's any objection to the proposal.
3 weeks, 3 days
rhel9 and /boot | /boot/efi
by Kevin Fenzi
I've been working on migrating things to rhel9 of late.
I reinstalled a staging virthost or two and found that while rhel8 would
allow /boot and /boot/efi to be on raid, rhel9 does not all this at all.
So, what do people do for this?
1. Just put /boot | /boot/efi on a primary partition on one disk and
hope that disk doesn't die.
2. Put them on one disk, but have duplicate partitions on the other raid
disks and some script that copies the 'primary' copies to the backups
when kernels are changed.
3. Something else more clever?
Whats best practice here? If 2 is the answer, does anyone have already
scripts to do this and tie into dnf for kernel updates?
I'd like to get this sorted out before moving any more bare metal hosts
over to rhel9 if possible.
1 month, 2 weeks
Proposed change to rendering of release schedule ics file
by Ben Cotton
I want to get feedback before I make a change to how Fedora Linux
schedules are generated. As reported in schedule#91, the current
ics files include very long tasks that aren't particularly useful. I
have a plan for how to address that, but first I want to check that it
won't impact how people currently use the ics files.
If you're using the Fedora Linux schedule ics files, please see the
details in the Pagure issue. If this will affect how you or your
team use those files, comment in the issue before 13 February. Note
that this will not change how the html or json versions are produced.
He / Him / His
Fedora Program Manager
1 month, 3 weeks
by Kevin Fenzi
Hey folks. I thought I would open a discussion about fedoraplanet and
possibly some plans for it.
fedoraplanet.org runs on people02.fedoraproject.org (aka fedorapeople).
To add a blog/rss feed you have to login there and edit your .planet
file, then scripting pulls all those .planet files and tries to fetch
all the feeds and then serves them up at http://fedoraplanet.org.
It uses a app called 'venus' to do this. venus is written in very old
python2 and very very dead upstream.
We run into the following problems with it:
* Sometimes it gets stuck and just stops processing until it's killed.
* It's serving on a http site, which causes people to ask us to make it
https, but that would just change the errors because many feeds it pulls
are still http since they were added back before letsencrypt existed.
* We have a handy 'website' field in our new account system, but aren't
using it at all.
* The .planet parsing is poor, any number of things can cause it to
We have two open tickets on it:
- https://pagure.io/fedora-infrastructure/issue/10383 (upgrade to pluto,
a ruby based, but maintained thing)
( planet not served via ssl) Which I am just going to close now.
So, I can think of a number of options and would love everyone who has
thoughts on it to chime in:
1. Do nothing. Venus "works" and .planet files are cool and retro.
2. Switch to pluto and use account system 'website' fields of
contributors. We could likely shove it in openshift and serve it
directly from there to avoid fedorapeople entirely.
(This would likely break anyone who has multiple feeds in there)
3. Switch to something better/bigger. I would think (although I don't
know) that there might be something that would not only aggregate rss
feeds for contributors, but perhaps mastodon/twitter/whatever also.
4. Planets are old and tired, just drop the entire thing. People can
maintain their own rss lists.
5. Planets are old and tired, just drop the entire thing.
But also, get our social media people to maintain contributor /
interesting lists. ie, the fedoraproject twitter account could maintain
a list of 'fedora contributors' and 'fedora packagers' or whatever.
6. Switch to pluto as in 2, but also setup some curators. Have a
'firehose' of all feeds, but the main fedora planet would be just
curated things that are known to be related to fedora and not off topic
6. Get someones (not it!) to take in all the
twitter/facebook/mastodon/blog posts/rss feeds and post some kind of
curated round up every week or something.
7. Your brilliant idea here!
So, thoughts? this is not at all urgent, but we should end up doing
something with it sometime. :)
1 month, 4 weeks
Sysadmin Main Membership
by Jonathan Steffan
Fedora Infra Team,
I was looking into some delays/failures on the main web properties and
noticed a couple nodes are likely the cause. Please see
https://pagure.io/fedora-infrastructure/issue/11097 for details.
I would like to be considered for sysadmin-main again. I've been a
long-term contributor, have had access before, and would like to contribute
Please let me know what the next steps are to make this happen.
Thanks for all you do,