The message about Ceph  reminded me that we should probably make the
same notification for Eclipse Platform.
The Eclipse Platform upstream is in the process of dropping all support for
The current state is that upstream are no longer building for 32bit arches
upstream for 4.10 (release 2018-12) onwards. I expect them to start
actively removing 32bit specific code in future releases.
You can read more about the decision on the upstream bug 
In Fedora, Eclipse 4.10 which I am building for Rawhide and F29 right now,
still builds for 32bit arches, but this will not last long. I expect in a
future release (4.11 or later) Eclipse will no longer build on x86/arm and
at that time I will no longer be able to support these architectures in
Fedora -- I expect to exclude those arches from Fedora builds.
If you depend on the ECJ batch compiler, this will continue to be available
on all arches as a noarch package. (It is packaged as a discrete SRPM and
has no build or runtime dependency on the Eclipse Platform itself.)
As some of you know, I've been involved with the OpenVPN packages for some
time as well as being an upstream OpenVPN developer and maintainer. Now we
have released the third beta release of OpenVPN 3 Linux.
This new client shares the same code base the OpenVPN Connect (proprietary)
clients uses as well as the OpenVPN for Android when switching to use the
OpenVPN 3 backend. The OpenVPN 3 code base is a rewrite in C++ and makes use
of the more modern features of C++11.
The Linux version is also very different from the OpenVPN 2.x generation, as
it is now D-Bus based. We have done this to allow easier integration with
other users and front-ends on Linux as well as having a better privilege
separation. Once all the backend pieces of OpenVPN 3 Linux has settled non of
them runs with more privileges than absolutely needed and there are several
services running which is responsible for only a subset of the features. This
is probably the least privileged OpenVPN implementation available today. On
top of that, we have also tried to make DNS configuration work out-of-the-box
as well (but here we need much more work to be really complete).
Part of this project we're also trying to get some kind of equivalent of the
Android VPN API in place on Linux. We have our own D-Bus service which
provides the needed functionality and can hopefully work as a stepping stone
towards something which can also be used outside OpenVPN alone too. The
current implementation should already provide all the needed features to
create and configure TUN devices (including IP addresses, routing and DNS) for
I'm announcing this here now as we also have Fedora Copr builds available for
EPEL-7, Fedora 28, Fedora 29 and Rawhide. In not too far future I would like
to get the process running to get the openvpn3 package into the mainline
Fedora repositories as well.
Our main source repositories can be found here:
We would be very much interested to get more users to try this out and to move
this project forward. The current codebase is in a reasonably good shape. It
is a bit rough around the edges when it comes to the DNS configuration and
/etc/resolv.conf handling, but otherwise it is fairly production ready.
This project aims to have good and reasonable documentation. I'm not saying
we're perfect in this regards, and we're open to improve here too. All D-Bus
services should be fairly well documented and we should have man pages for
most of the binaries we provide.
* D-Bus details
* man pages:
Feel free to reach out if you have some questions or good ideas.
There was a bug filed recently that indicated that printing was
broken on certain printers. As a result of that discussion, it became
apparent that there was no criteria for printing to work at all, which
seems like an oversight.
I discussed this briefly with Matthias Clasen this morning and he
agreed that this should be treated as blocking for Workstation.
I'd like to propose that we add the following criteria to Beta for Fedora 30+:
* Printing must work on at least one printer available to Fedora QA.
"Work" is defined as the output from the device matching a preview
shown on the GNOME print preview display. (Note that differences in
color reproduction are not considered "non-working".)
and this to Final for Fedora 30+:
* Printing must work on at least one printer using each of the
(I don't know which ones to specify here, but we ought to try to
figure out a cross-section that covers a large swath of our expected
In the past few weeks, it has come up regularly that future
"module-only" packages are orphaned (and hence will soon be retired),
and nobody stepped up to fix this issue - especially for non-leaf
packages. I don't think fedora as a project has a solution for this
I propose to create a "Stewardship" Group / SIG that will take care of
such packages - either until a new main maintainer steps up, or until
modularity matures enough so it won't be necessary anymore. (Or, until
it dies a quiet death, which is always a possibility.) However, I
think this is necessary until the situation stabilizes.
Comments and future contributors are very welcome.
It happened to me almost dozen times now, so here's my rage :D
I want to send a pull request to a Fedora project*, I clone it, fork it, push to
the fork, open a PR and there it goes:
! This repo requires all commits to have the Signed-off-by whatnot in them !
So I have to go again, amend with -s, push force. That is tedious and at least I
know how to do that. I assume there are people who don't.
Can we stop this nonsense? I usually smuggle something like:
Signed-off-by: Stop This <pretty(a)plea.se>
And nobody ever cares! The thing is enforced only because it can be enforced.
The line in that commit message is totally useless and doesn't provide any
benefit, just pain. I've signed the Fedora Project Contributor Agreement. That
should be enough.
Now a bit more serious:
What information am I missing? Why do Fedora upstreams enforce this?
(* last time it was simple-koji-ci, but it's also fedpkg and other projects on
At times this could be a requirement to track or know translation status of a package which has (just) built in koji.
Transtats could be used for this purpose. We just need to run a job.
1. Navigate to https://transtats-web-transtats.app.os.stg.fedoraproject.org/jobs/yml-based
2. Select 'Sync Package Build System' job template and proceed.
3. You may read and continue with the tasks defined in YML.
4. Select or enter package name. For example: anaconda.
Select Build System and Tag. For example: koji and rawhide
5. And run the job. Upon successful completion an unique URL will be created.
This could really be helpful. We are working on creating alerts or warnings.
Feel free to share comments on this here: http://feedback.transtats.xyz
tl;dr dhcp 4.4.1 will not require bind-export-libs and will bring
dhcp-libs-static with bundled version of libisc/libdns/etc
As ISC dropped support of single thread build of BIND libraries  and
dhcp requires one we decided to not patch dhcp/bind build scripts anymore
and ship bundled bind libraries just like upstream (ISC) does it. It will
allow to update BIND in Fedora to newest version. So dhcp 4.4.1 can be
expected in rawhide/F31 soon!
I'm aware of FPG recommendation to avoid shipping of bundled libraries due
to its maintenance cost but maintaining of heavy patched build sctipts and
inability to ship newer versions are even worse.
I have not find any application in Fedora repository which link with
libdhcp/libomapi. Please let me know if you aware of any.
= BuildRequires Generators =
== Summary ==
Add possibility to generate build-time dependencies within RPM spec
file and teach RPM and mock how to handle this.
== Owner ==
* Name: [[User:ignatenkobrain|Igor Gnatenko]], [[User:ffesti|Florian
Festi]], [[User:msuchy|Miroslav Suchý]]
* Email: ignatenkobrain(a)fedoraproject.org, ffesti(a)redhat.com, miroslav(a)suchy.cz
== Detailed Description ==
For many languages (Rust, Golang, Node.Js, Ruby, Python),
BuildRequires can be automatically generated. All it takes, run some
special tool which will output dependencies in RPM format.
Q: How will it work under the hood?
A: When you build RPM, something like this will happen under the hood…
# rpm would perform %prep (which is supposed to abort if some
dependencies missing and print them)
# mock would install those dependencies and resume build
Q: Will src.rpm contain all generated dependencies?
A: This is not known yet, we'll update page once it is known.
Q: Does this mean that package builds won't be reproducible anymore?
A: No, as long as you have same buildroot and tool which is generating
BuildRequires is doing so in reproducible manner, it should not affect
== Benefit to Fedora ==
Packagers won't have to pre-generate BuildRequires in the spec file
which means it will be always updated (and correct) :
* Packagers can focus of making their packages better instead of
spending all their packaging time copying BuildRequires from
documentation and third party tools.
* BuildRequires are dropped as soon as they're no longer necessary
* Packages can be easily bumped without requiring a manual BuildRequires refresh
* BuildRequires and Requires generation can use similar utilities,
making sure that the deps packages declare can also be used for
second-level building. Packages no longer need to declare the deps of
their second and n-th dependencies because someone forgot to declare
them in the correct package.
== Scope ==
* Proposal owners: Implement support for a feature in RPM and mock (if
implemented properly, Koji should just work). Make use of it in Rust
* Other developers: Maintainers of language stacks are advised to use
* Release engineering: [https://pagure.io/releng/issue/8129 #8129]
* Policies and guidelines: Packaging Guidelines need to be updated
with instructions how to use this feature.
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
Packagers and users who use repoquery might be affected (src.rpm might
not contain generated dependencies).
== How To Test ==
== User Experience ==
Users won't notice differences.
== Dependencies ==
Required feature needs to be implemented in RPM and mock.
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) Proposal
Owners might still ship feature disabled for Fedora buildsystem but
have it available for end-users, and move full completion to the next
* Contingency deadline: Beta Freeze
* Blocks release? No.
* Blocks product? No.
== Documentation ==
== Release Notes ==
Fedora Program Manager