Fedora package maintainers,
FESCo approved an updated policy for packages which fail to build from
source during mass rebuilds (FTBFS) .
The updated policy is still at https://fedoraproject.org/wiki/Fails_to_build_from_source.
- packages which FTBFS are subject to orphaning if there is no
maintainer acknowledgement within 8 weeks
- packages which FTBFS in two consecutive mass rebuilds will be
retired soon after the second mass rebuild
The implementation of this policy hinges on improving the releng
scripts used to create and manage FTBFS bugs. There is approximately
two months until the next use of those scripts, so I'm hopeful we'll
get them working.
If your package wasn't successfully built for F28, please fix that!
Users of OpenSHift Origin require CRI-O 1.10 right now. But Kubernetes
users want to try out the latest packages for kubernetes 1.11 which
would require CRI-O 1.11. Origin might not be ready to move to
Kubernetes 1.11 for a while.
Bottom line we want to be able to ship CRI-0 1.10.* and CRI-O 1.11.*
releases in the same Fedora 28.
I believe this is what Modularity was designed to fix.
Can I do this with Modularity? If I can how do I use fedpkg to make
tl;dr: Unless someone steps up to maintain Python 2 after 2020, we need
to start dropping python2 packages now.
Python 2.7 will reach end of upstream support on 1st of January, 2020,
after almost 10 years (!) of volunteer maintenance.
Fedora still has more than 3000 packages depending on python2 – many
more than we can support without upstream help.
We (rightly) don't have the authority to say "please drop your unneeded
python2 subpackages, or let us drop them for you" .
The next best thing we *can* say is: "if Fedora is to keep python2
alive, we won't be the ones doing it – at least not at the current
Here are the details.
The current maintainers of python2 would like to "orphan" the python2
package in 2020 (~ Fedora 30):
- Charalampos Stratakis (cstratak)
- Tomáš Orsava (torsava)
- Miro Hrnočok (churchyard)
- Petr Viktorin (pviktori)
- Iryna Schcherbina (ishcherb)
- Michal Cyprian (mcyprian)
- Bohuslav Kabrda (bkabrda)
- David Malcolm (dmalcolm)
- Thomas Spura (tomspur)
As with any orphaning, that leaves two options:
- someone else agrees now to take over in 2020 (keeping in mind this is
a security-critical package and will be abandoned upstream), or
- dependent packages drop support for Python 2.
Unlike most other orphanings, we have some thousands of dependent
packages, so a lot of time and care is required.
In case no one steps up, we'd like to start dropping Python 2 support
from dependent packages *now*, starting with ported libraries on whose
python2 version nothing in Fedora depends. (We keep a list of those at .)
Of course, we're ready to make various compromises with interested
packagers, as long as there's an understanding that we won't just
support python2 forever.
If you are a maintainer of anything at  we ask you kindly to consider
removing the python2 subpackages.
You can either do it now in Rawhide, or add a conditional for Fedora >
29. (On the current schedule, Fedora 30 will be the first release still
supported after 2020-01-01.)
If no one steps up to maintain python2 after 2020, we're prepared to
package a "legacy" python27 package, similar to what we do for e.g.
python33 , to:
- help developers that still need to test against this version
- support exceptionally important non–security critical applications, if
their upstreams don't manage to port to Python 3 in time
I'm working on improving the Fedora boot experience, with the
end goal being a user pressing the on button and then going
to the graphical login manager without him seeing any
text messages / menus filled with technical jargon.
IIRC we used to hide the grub-menu by default on single
OS installs, but we seemed to have stopped doing that,
for new Fedora 29 installs I would like us to start
hiding the menu by default on single OS installs again,
The goal if this email is to:
1) Give people an advance warning about the plan to change
this so we can discuss this early on
2) See if anyone knows why we stopped doing this, I think
we may simply have stopped doing this to simplify to bootconfig
code in anaconda and because we did not always identify the
single OS case correctly, but I wonder if there were other
On Thu, 2018-06-28 at 20:41 +0200, Miro Hrončok wrote:
> sergiomb opencv
error: invalid conversion from 'const char*' to 'char*' [-fpermissive]
char* str = PyString_AsString(obj);
This problem is not about new gcc flags ? or about python rebuild ? now
that I'm reading if I just add const to the code  will fix this
build error ?
original code here 
const char* str = PyString_AsString(obj);
Sérgio M. B.
= Proposed System Wide Change: Modules for Everyone =
* Stephen Gallagher <sgallagh at fedoraproject dot org>
* Langdon White <langdon at fedoraproject dot org>
All Fedora installations will have modular repositories enabled by default,
previously available, by default, only to Server Edition.
== Detailed description ==
In Fedora 28, the Server Edition debuted new modular functionality,
allowing end-users access to alternative versions of popular software. Due
to technical limitations with package-management software, it was not
available for non-Server deployments of Fedora. Beginning with Fedora 29,
all installations of Fedora will have modules available for installation
and update. This will be done by merging the `fedora-repos-modular`
sub-package back into the `fedora-repos` package.
== Scope ==
* Proposal owners:
The proposal owners need to coordinate the work of the DNF team and
release-engineering to make sure that the repo subpackage merge only
happens once the libdnf enhancements are stable. We will also need to
prepare and run a Fedora Test Day with the QA team.
* Other developers:
The DNF team is already committed to providing the necessary changes for
libdnf in Fedora 29.
* Release engineering:
** List of deliverables:
All Fedora installations
* Policies and guidelines:
No alterations to packaging guidelines are required specifically for this
* Trademark approval:
N/A (not needed for this Change)
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
I'm working on making Fedora being able to function completely without the
'initscripts' package (hopefully) some day in the future. I have done some
cleanup in initscripts recently, and I would like to ask maintainers of
packages listed below to check if their package(s) still really need the
initscripts package to function properly (for any reason).
It seems that for many packages the requirement of initscripts is just a
leftover from past. If the package does not need the initscripts any
longer, please remove the requirement in Rawhide (F29) and forward. (Do not
backport this change into F28 or F27, it would break things.)
NOTE: In case you are depending on initscripts because of networking
scripts (ifup/ifdown, etc.), then you will need to update your specfile to
depend directly on new package 'network-scripts' (instead of 'initscripts').
I've opened bug reports for each of the packages listed here, and created a
tracking BZ for it:
List of packages still depending on initscripts (some of them were already
Thank you, and best regards! :)
David Kaspar [Dee'Kej]
*Associate Software Engineer*
*Brno, Czech Republic*
RED HAT | TRIED. TESTED. TRUSTED.
Every airline in the Fortune 500 relies on Red Hat.
Find out why at Trusted | Red Hat <http://www.redhat.com/en/about/trusted>.
The Python 3.7 rebuild in the f29-python side tag is currently:
- 2168 built
- ~170 FTBFS
- ~120 blocked by dependencies that FTBFS
Ideally, this would all get fixed before the merge, but that's
unrealistic, there are packages that are FTBFS for unrelated reasons, etc.
What is the criterion to merge the side tag?
The critpath installs fine (except stuff that cannot be installed due to
yum-deprecated vs yum collisions and gnome-software that has some broken
dependency on PackageKit).
Stuff that doesn't build and sounds important:
- ceph (also FTBFS in regular rawhide)
- libreoffice (also FTBFS in regular rawhide)
- orca (blocked by pyatspi, looking at it ATM)
There will be an outage starting at 2018-07-02 21:00UTC, which will
last approximately 4 hours.
To convert UTC to your local time, take a look at
date -d '2018-07-02 21:00UTC'
Reason for outage:
There have been a set up of updates for EL7 and Fedora requiring
reboots of infrastructure. We will be rebooting the Build and remote
systems outside of PHX2 on this day.
All build and cloud services may be up or down during the outage
window. Various proxies will not be available and fedorapeople will be
Please join #fedora-admin or #fedora-noc on irc.freenode.net or add
comments to the ticket for this outage above.
Stephen J Smoogen.