We (the Anaconda installer team) want to solve multiple problems by one
solution and we want
In short we are proposing to use custom repo files when configuring
Anaconda for image creation instead of adding even more complexity to
the kickstart repo command. For more details see the link below.
Purpose of this mail is to give everyone interested in the topic a
place to discuss our proposal to find out if we didn't miss something
or better case, if you agree with it :). It could be that this is not
applicable for Lorax / Pungi / live-cd tool in that case please write a
response to the document.
You can read details here:
Please, all the relevant comments should stay in the document if
possible. If that solution won't work because of higher traffic then we
will find a better solution but the point is to have everything on one
Have a great day everyone,
Do anyone know how to subscribe to Bugzilla bugs for a particular
I'm trying to watch glib-networking bugs. I'm already watching issues
and PRs at https://src.fedoraproject.org/rpms/glib-networking, but that
only watches for Pagure issues, not Bugzilla.
I'm already watching webkit2gtk3 package issues on Bugzilla and this
works exactly as I would expect, but I think I configured that long ago
with pkgdb back when pkgdb still existed.
This seems pretty basic, so it shouldn't be hard. Any ideas?
I've just orphaned the "paper-icon-theme" package. I no longer use it
and have no interest in maintaining it further. The package is
up-to-date with the latest upstream release (though the upstream
project is pretty much dead now).
This is the Minimization Objective  update.
Status: Discovery phase
== Regular meeting canceled ==
We have decided to cancel the regular Minimization Team Meeting  as we
prefer async discussions on #fedora-devel and devel(a)lists.fp.o. This makes
it more inclusive to people with other commitments or being in timezones
that prevent them attending the meeting at that specific time.
== systemd-sysusers vs. containers ==
We don't want Systemd in containers , but we recognise this is a
container-specific problem. So we're asking other groups — Containers SIG
and people working with OpenShift — for how they're approaching this
== Feedback Pipeline ==
Feedback Pipeline  is now automated, refreshing every day.
It also now includes sizes of individual packages in all reports, as well
as a timestamp.
== pcre -> pcre2 ==
Moving grep (one of the last packages using pcre) to pcre2. 
== How to get involved ==
See if there is anything interesting to you on action plan , or reach
out with something you think is useful but is missing there. Open a ticket
in the tracker  or discuss in #fedora-devel on IRC.
 Objective: https://docs.fedoraproject.org/en-US/minimization/
 Meeting canceled: https://pagure.io/minimization/issue/14
 systemd-sysusers vs. containers: https://pagure.io/minimization/issue/13
 Feedback Pipeline: https://minimization.github.io/reports/
 switching grep to pcre2:
 Action plan:
 Issue tracker: https://pagure.io/minimization/issues
Senior Software Engineer
We have an odd issue with a module build of sway for F30: It looks like
the module was actually built with a F32 buildroot.
Here's the build:
The modulemd file contains:
But then, it built packages with f32 in the package version:
[and more packages]
The package shows up in a F30 repoquery:
$ dnf repoquery --releasever=30 mako
Last metadata expiration check: 0:08:32 ago on Sun 22 Sep 2019 11:25:43
But it requires systemd-libs from F32:
$ dnf repoquery --releasever=30 --requires \
mako-0:1.4-1.module_f32+6140+eb754d2b.x86_64 | grep SYSTEMD
Can someone tell me what's going on here?
I’d like to introduce myself first, my name is Aoife Moloney and I recently
started with the Community Platform Engineering (CPE) team. My role within
this team is going to be a hybrid role of a Product Owner / Project Manager.
As part of that, I want to send a weekly update to the lists to give an
insight into what the CPE team have worked on over the past week or so.
This will also be mirrored as a higher level blog to give maximum
We, as a team, welcome your input and comments and please do let us know
how we can improve this community facing information segment!
As you know, the CPE team looks after interests in both Fedora and CentOS,
so this update is also going to include work done on areas that are not
your Community, but for transparency, we are including it :)
High Level Project Updates:
Rawhide Gating: <https://github.com/fedora-infra/bodhi/projects/3>
First work around merging side tags has been completed
Open PR <https://github.com/fedora-infra/bodhi/pull/3498> that needs
to be finished
We need to update our staging environment which broke when we branched
F31 in production:
Tracked in: https://pagure.io/releng/issue/8838
Koji stuck/full: https://pagure.io/fedora-infrastructure/issue/8240
Overview page of the remaining blockers and dependencies organized at:
Input welcome for anything that would be missing
High priority items in the “Ready” column are all hard-dependency
for pushing multi-builds to production
Race condition discovered has been fixed and tested
Test suite has a number of issues which are being triaged and worked
through at the moment
Performance testing is next on our agenda
Badges has had some further conversations with community members and we
are aligning on a handover date
Packagedb-cli is being retired this week
Documentation for onboarding contributors to Community OpenShift was
started with a good mail thread on Fedora Devel
Pastebin: Ongoing conversations with future maintainer, expecting an
update in the next 2 weeks
Elections: Ben Cotton is taking this over and the CPE team are assisting
with moving this to Communishift
Fedocal still needs your help, we need a Maintainer here urgently
If no one steps up by October 15th, we will be looking at
Nuancier, we possibly have identified a maintainer here and the team are
engaging in a conversation
Misc highlights from various parts of the ecosystem:
FPDC had some light work on it, an instance of Kinto (
http://docs.kinto-storage.org/en/stable/) was deployed in staging at
Fedora Container base image update for F30, F31 and F32. (Dockerhub
Rawhide compose failures, due to podman gating, filed
https://github.com/fedora-infra/bodhi/issues/3512 on it
Announced F31 Beta freeze over, adjusted thing
F31 Beta saw the team help in various places, everything went smoothly!
Fixed pagure stunnel to use tls1.1/1.2 and a valid cert
Fixed pagure event server to use valid cert with intermediate:
Mdapi app fully moved to OpenShift:
Branched versioned Fedora docs for F31
Worked on updates to Fedora contributor docs
Progressing more fedmsg → fedora messaging conversions on our scripting
Fixed the Koji rpm.sign fedora-messaging message (
CentOS 8 was released this week :)
Core artifacts (repos and install media) were refreshed and sent to
CentOS Stream was built and staged
Cloud and Container images are outstanding, coming up next
Sources and debuginfo content synced to the mirrors
Armhfp enablement coming soon
Activities related to releasing CentOS 7.7 (17-September) and
subsequently CentOS 8 (24-September) consumed the entire teams time!
Community Platform Engineering Team
Red Hat EMEA <https://www.redhat.com>
On 2019-09-26, Pierre-Yves Chibon <pingou(a)pingoured.fr> wrote:
> ○ Every changes to dist-git is done via pull-requests
Pull requests are great for proposing your changes to foreign packages.
It does not make sense when maintaining the code. Either when doing
a mass changes like rebuilding all Perl packages against a new perl or
when pushing your own changes. It will become a bureaucracy that adds
a delay and complexity and spams you mailbox. Who is going to merge all
the requests? How do you automate it? We would need "koji watch-task"
for merging the pull requests. I will repeat it: pull requests are
great when you need a review. Otherwise it only consusmes resources.
I'm strongly against this.
> ○ Pull-requests are automatically tested
Nice. But i think this already happens.
> ○ Every commit to dist-git (ie: PR merged) is automatically built in koji
How do you want to implement waiting on propagating build root overrides?
> ○ Every build in koji results automatically in an update in bodhi
How do I merge related updates into on if more packages must be
tested and delivered as one unit? That very often happens with the
I smell automated side-tags that has never been implemented.
> ○ Every update in bodhi is automatically tested
This is already a reality.
> ○ If the tests pass, the update is automatically pushed to the repository
This also already happens.