Holiday plans and reminders
by Kevin Fenzi
Greetings everyone.
The holidays are coming up later this month and so I thought I would
remind folks about holiday handling in Fedora Infrastructure.
Red Hat has a shutdown period, this year between 2018-12-22 and
2019-01-02. All Red Hat employees (at least in the US) are supposed to
take this time to spend with friends and family and recharge for the
year ahead. So, this means there's not too many Red Hat employees around
then.
If you are making changes to Fedora Infrastructure during this time,
please be aware that alerts or problems might call in someone who is
spending time away, so be especially careful not to disrupt things,
cause alerts or outages.
If you are someone who does want to work on things, try and update
tickets or PR's or lists posts with your work instead of pinging people
or mailing them directly. This work can then be processed when everyone
is back.
Hope everyone has a lovely holidays...
kevin
5 years, 4 months
Releasing Greenwave
by Giulia Naponiello
Hello,
I'll try to release Greenwave today.
I'm available on IRC on #fedora-apps - giulia/gnaponie is my nickname.
Cheers
Giulia
5 years, 4 months
Best path for Fedora zchunk dictionaries
by Jonathan Dieter
I'm currently in the process of packaging up fedora-repo-zdicts[1], a
package which will contain the zchunk dictionaries for all active
Fedora releases.
When running createrepo_c or mergerepo_c with zchunk support, the
directory containing the zdicts is passed in and createrepo_c will
choose the right zdict for each metadata file. The form of that
directory is /usr/share/fedora-repo-dicts/<release> where <release> is
the release that the metadata is being generated for.
My question is what <release> should actually look like. This is very
Fedora specific, so I want to choose whatever the easiest variable is
for infra to pass to createrepo_c or mergerepo_c.
Currently <release> is set to PLATFORM_ID in /etc/os-release (so,
platform:fedora-30 for Rawhide), but that's probably overly generic.
What would be a better pattern for <release>? fedora-30? f30? Just 30?
Jonathan
5 years, 4 months
[PATCH] bodhi-pungi: don't run silverblue compose for testing
by Dusty Mabe
This is a temporary hack to workaround https://pagure.io/pungi/issue/1092.
Note this also just re-uses the f27 logic, which is no longer needed.
---
roles/bodhi2/backend/templates/pungi.rpm.conf.j2 | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/roles/bodhi2/backend/templates/pungi.rpm.conf.j2 b/roles/bodhi2/backend/templates/pungi.rpm.conf.j2
index ee1edb6ed..74c0378ec 100644
--- a/roles/bodhi2/backend/templates/pungi.rpm.conf.j2
+++ b/roles/bodhi2/backend/templates/pungi.rpm.conf.j2
@@ -153,8 +153,8 @@ ostree = {
"failable": ["ppc64le", "aarch64"],
[% endif %]
},
- # Atomic Workstation
- [% if release.version_int >= 27 %]
+ # Fedora Silverblue
+ [% if request.name == 'stable' %]
{
[% if release.version_int >= 28 %]
"version": "!VERSION_FROM_VERSION_DATE_RESPIN",
--
2.14.5
5 years, 4 months
[PATCH] bodhi-pungi: pass in ostree_oskey to fedora-lorax-templates
by Dusty Mabe
This is needed because of a recent change to parameterize
the key. https://pagure.io/fedora-lorax-templates/pull-request/30
---
roles/bodhi2/backend/templates/pungi.rpm.conf.j2 | 1 +
1 file changed, 1 insertion(+)
diff --git a/roles/bodhi2/backend/templates/pungi.rpm.conf.j2 b/roles/bodhi2/backend/templates/pungi.rpm.conf.j2
index baed32f3f..ee1edb6ed 100644
--- a/roles/bodhi2/backend/templates/pungi.rpm.conf.j2
+++ b/roles/bodhi2/backend/templates/pungi.rpm.conf.j2
@@ -312,6 +312,7 @@ ostree_installer = [
'ostree_install_repo=https://kojipkgs.fedoraproject.org/compose/atomic/repo/',
'ostree_update_repo=https://dl.fedoraproject.org/atomic/repo/',
'ostree_osname=fedora-atomic',
+ 'ostree_oskey=fedora-[[ release.version_int ]]-primary',
'ostree_install_ref=fedora/[[ release.version_int ]]/[[ arch ]]/[% if request.name == "testing" %]testing[% else %]updates[% endif %]/atomic-host',
'ostree_update_ref=fedora/[[ release.version_int ]]/[[ arch ]]/atomic-host',
],
--
2.14.5
5 years, 4 months
