I was thinking about this for a while and I got the impression that this
is something I don't know the answer for. The question is a bit harder
to formulate simply, so let put it in examples:
a) A need packaging guideline is about to be discussed. A member of FPC
wants to know how many packages would be affected so they run a quick
grep query over all the rawhide specfiles at .
b) A CVE is found in a web framework, so bugz are filled for the
"framewrok" package to be fixed in Fedora 27, because newer Fedoras have
newer version of the framework where the CVE is not applicable.
c) A new version of interpreted language lands in rawhide. All packages
depending on the interpeter need mass rebuild in a side tag.
d) A packager decides to retire a library and they check nothing in
Fedora requires it.
I wonder how are such situations meant to be handled with modules?
Do we build modules for rawhide? If so, should Fedora changes (such as,
but not limited to, "the Changes") somehow handle all the modules, or is
it the modular maintainer responsibility to make sure their module works
on the next Fedora version?
For the above examples, here are some more specific situations with more
a) I was planning to propose a more strict "No more automagic Python
bytecompilation"  change for Fedora 30 where we would query all
packages that depend on the old behavior and mass add "%global
_python_bytecompile_extra 1" to all of them, so we could switch the
default to be 0. Normally, we would do it in Rawhide only. But how do I
handle modules? How do I find out what modular packages rely on the old
b) A CVE was filled for Django . How does the security team
responsible for tracking CVEs figure out we have Django 1.6 in modular
Fedora? How is a bugzilla filled against a modular package anyway?
c) When we recently mass rebuilt Python 3 packages for Python 3.7,
should we go and seek for modules that use Python 3 (how do I do that?)
and rebuild the packages in the modules (or even the modules?)?
d) (this example is not real (yet)) We decide to retire (remove)
python2-sphinx because upstream Sphinx no longer supports Python 2. We
make sure that nothing in Fedora requires or buildrequires it, as all
Fedora's Python packages use python3-sphinx or no Sphinx at all. However
there is a Django 1.6 module where python-django uses python2-sphinx to
build the docs, while python2-sphinx is not part of the module itself.
How do we find out about this and is it our reprehensibility to keep it
in rawhide or add it to the module?
Sorry if those things are obvious, yet I don't know the answers. There
might be even more examples where traditionally we would only think
rawhide, but now with modules the problem seems more complex.
There are some incompatible changes so I'm building it only for Rawhide.
Just wanted to let you know yet another software reaching 1.0 milestone.
= PHP 7.3 =
== Summary ==
Update the PHP stack in Fedora to latest version 7.3.x
== Owner ==
* Name: [[User:Remi| Remi Collet]] and [[SIGs/PHP|PHP SIG]]
* Email: remi at fedoraproject dot org
== Detailed Description ==
Update the PHP stack in Fedora to latest version 7.3.x.
* [http://php.net/archive/2018.php#id2018-09-13-2 First RC] was
released on Sept 13th
* PHP 7.3.0 is [https://wiki.php.net/todo/php73 planed] for end of
year, which seems compatible with Fedora roadmap.
Compatibility for PHP code is very good.
== Benefit to Fedora ==
Provides the latest PHP version to developers and system administrators.
== Scope ==
* Proposal owners: Check Koschei status. Test with latest version to
ensure compatibility. Work with upstream on bug fixing. Needed mass
rebuild (C extensions) done by change owner.
* Other developers: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
== How To Test ==
* The PHP stack (extensions and libraries) are monitored by Koschei,
see the https://apps.fedoraproject.org/koschei/groups/php?order_by=state%2C-started
* install and play with your web applications
== User Experience ==
Developers and system administrators will have the great benefit or
running the latest PHP version.
== Dependencies ==
All php-* packages (and some *-php)
== Contingency Plan ==
* Contingency mechanism: Drop not compatible packages.
== Documentation ==
Fedora Program Manager
I have to admit that I am a bit puzzled about DNF behavior with modularity.
I have installed repo files with modularity repos, but all of them are disabled. I have no module enabled on my system
(F29 BTW). To be precise:
output of `dnf module list`
And every time I run `dnf upgrade` I get this output:
Problem 1: cannot install the best update candidate for package bubblewrap-0.3.0-2.fc29.x86_64
- package bubblewrap-0.3.0-2.module_2123+73a9ef6f.x86_64 is disabled
Problem 2: cannot install the best update candidate for package docker-distribution-2.6.2-7.git48294d9.fc28.x86_64
- package docker-distribution-2.6.2-7.git48294d9.module_1641+02d06da9.x86_64 is disabled
Problem 3: cannot install the best update candidate for package eog-3.28.3-1.fc29.x86_64
- package eog-3.28.3-1.module_2123+73a9ef6f.x86_64 is disabled
Problem 4: cannot install the best update candidate for package exempi-2.4.5-3.fc29.x86_64
- package exempi-2.4.5-3.module_2123+73a9ef6f.x86_64 is disabled
Problem 5: cannot install the best update candidate for package flatpak-runtime-config-27-7.fc29.x86_64
- package flatpak-runtime-config-27-7.module_2021+15e5e3e7.x86_64 is disabled
Problem 6: cannot install the best update candidate for package gimp-2:2.10.6-2.fc29.x86_64
- package gimp-2:2.10.6-2.module_2129+8576126a.x86_64 is disabled
Problem 7: cannot install the best update candidate for package gimp-libs-2:2.10.6-2.fc29.x86_64
- package gimp-libs-2:2.10.6-2.module_2129+8576126a.x86_64 is disabled
Problem 8: cannot install the best update candidate for package kubernetes-client-1.10.3-1.fc29.x86_64
- package kubernetes-client-1.10.3-1.module_2132+faf1362b.x86_64 is disabled
Problem 9: cannot install the best update candidate for package libnghttp2-1.33.0-1.fc29.x86_64
- package libnghttp2-1.33.0-1.module_2177+2526c218.x86_64 is disabled
Problem 10: cannot install the best update candidate for package libpeas-1.22.0-9.fc29.x86_64
- package libpeas-1.22.0-9.module_2123+73a9ef6f.x86_64 is disabled
Problem 11: cannot install the best update candidate for package libpeas-gtk-1.22.0-9.fc29.x86_64
- package libpeas-gtk-1.22.0-9.module_2123+73a9ef6f.x86_64 is disabled
Problem 12: cannot install the best update candidate for package libpeas-loader-python3-1.22.0-9.fc29.x86_64
- package libpeas-loader-python3-1.22.0-9.module_2123+73a9ef6f.x86_64 is disabled
Problem 13: cannot install the best update candidate for package libuv-1:1.22.0-2.fc29.x86_64
- package libuv-1:1.23.0-1.module_2177+2526c218.x86_64 is disabled
Problem 14: cannot install the best update candidate for package nghttp2-1.33.0-1.fc29.x86_64
- package nghttp2-1.33.0-1.module_2177+2526c218.x86_64 is disabled
Problem 15: cannot install the best update candidate for package nodejs-1:10.11.0-1.fc29.x86_64
- package nodejs-1:10.11.0-1.module_2200+adbac02b.x86_64 is disabled
Problem 16: cannot install the best update candidate for package npm-1:6.4.1-184.108.40.206.1.fc29.x86_64
- package npm-1:6.4.1-220.127.116.11.1.module_2200+adbac02b.x86_64 is disabled
Problem 17: cannot install the best update candidate for package perl-DB_File-1.842-1.fc29.x86_64
- package perl-DB_File-1.842-1.module_2073+eebc5b71.x86_64 is disabled
Problem 18: cannot install the best update candidate for package perl-HTTP-Tiny-0.076-1.fc29.noarch
- package perl-HTTP-Tiny-0.076-1.module_2073+eebc5b71.noarch is disabled
Problem 19: cannot install the best update candidate for package perl-Thread-Queue-3.13-1.fc29.noarch
- package perl-Thread-Queue-3.13-1.module_2073+eebc5b71.noarch is disabled
It does not matter if I pass `--best` option or not.
Why I - as a user - see this warnings/errors?
Is this an error or a feature?
we have no tickets on the agenda for the FESCo meeting today,
so hopefully it will be short one.
The meeting will be held at 15:00UTC in #fedora-meeting-1 on
To convert UTC to your local time, take a look at
date -d '2018-09-24 15:00 UTC'
Links to all issues can be found at:
If you would like to add something to this agenda, you can reply to
this e-mail, file a new issue at https://pagure.io/fesco, e-mail me
directly, or bring it up at the end of the meeting, during the open
floor topic. Note that added topics may be deferred until the