sorry for a slightly off-topic post, but I've noticed that a significant
number of posters is sending HTML e-mail to this list (not to mention
top-replying), which generates unnecessary network traffic. Some people
pay for every bit downloaded, so they're paying for the same information
twice, because the e-mails are sent with multipart/alternative format,
which contains BOTH text/plain and text/html. One thing I noticed those
senders have in common is that they use Gmail.
So, a plea to Gmail users: please stop sending HTML e-mail to Fedora
Dominik (who still reads e-mail in text mode in a terminal)
Fedora https://getfedora.org | RPMFusion http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
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.
Earlier this week, I wrote a script to check and add all Golang packages to
Anitya. Everything went smoothly, and dozens of packages were registered and
got their version retrieved.
Since our float of Golang packages is severely out of date, I was expecting a
load of new messages from Bugzilla. But niet, nada, zilch: no new bug were
filed as part of this process.
So is Anitya broken again? Is it not supposed to fill bugs for new versions?
For example, I registered golang-github-montanaflynn-stats:
Latest version upstream is 0.5.0
Version in Fedora is 0.2.0
Yet no bug was filled for it.
Any help please?
Fedora prohibits the use of rpath, ref
When compiling varnish with litbool, I ensure this by the usual
sed -i 's|^hardcode_libdir_flag_spec=.*|hardcode_libdir_flag_spec=""|g;
However, during build and check, I need access to a library in the
build. For example, the test suite uses the binary varnishtest to
access libvarnishapi.so.2, which is not visible as the package is not
I have gotten around this by putting in LD_LIBRARY_PATH where I need,
but rpmlint gives me a warning on that.
Are there other possibilities to solve this?
So at last week's Fedora 30 Beta Go/No-Go meeting, it was decided that
the Basic release criterion:
"Boot menu contents
The boot menu for all supported installer and live images should
include an entry which causes both installation and the installed
system to use a generic, highly compatible video driver (such as
'vesa'). This mechanism should work correctly, launching the installer
or desktop and attempting to use the generic driver."
should no longer apply to Beta - i.e. that it should no longer be a
Basic or Beta criterion.
The justification for this is, I hope I am correctly representing all
views here (please say so if not), that this mechanism is both less
necessary (due to a general reduction in the amount of 'weird' graphics
hardware out there, and general improvement in the reliability and
coverage of the major drivers for the major graphics hardware
manufacturers) and inherently less likely to work (due to the general
trend of work on kernel modesetting and Wayland) than it used to be.
For context, it is worth noting that the *feature* predates the
introduction of both kernel modesetting *and* Wayland to Fedora. What
the feature initially did was tell anaconda to write an X config file
specifying the 'vesa' driver (instead of working out the correct
'native' driver for the adapter and writing a config file specifying
that). After KMS was introduced in Fedora 10, the mechanism was tweaked
to also pass the 'nomodeset' kernel parameter to disable KMS. Around
2012 (https://bugzilla.redhat.com/show_bug.cgi?id=858270) we noticed
that the X config file mechanism was a bit superfluous as 'nomodeset'
alone could basically be relied on to force some sort of 'fallback
mechanism', and so the feature was simplified to *only* specify the
'nomodeset' kernel parameter (this is all it does now).
The *criterion* dates to 2010, in the Fedora 15 release cycle: it
appears in the Fedora 15 Alpha criteria but not the Fedora 14 Alpha
criteria. It was added on 2010-08-16:
The group at the meeting did not, however, make any further decisions,
so this leaves us with some open questions:
0) Do we generally agree with the decision made at the meeting? If
anyone (especially a subject matter expert) strongly believes the
decision was wrong and this should still be a Basic/Beta requirement,
please say so.
1) Should the criterion be modified somehow, but some requirement in
relation to some kind of fallback graphical mode be kept at Basic or
2) Should the criterion be moved to Final, unchanged or changed
3) Should the requirement just basically be dropped entirely as no
4) (This one mainly for ajax and airlied) to what extent does the
concept of a 'fallback option' for our supported desktop environments
and graphical servers still actually make sense? Could a different
implementation of the same basic idea be envisaged, and would it be
useful? If so, should we do that, and what would be the consequences
for the criteria?
I realize this is quite a big and fuzzy topic, but I'm hoping the
responses to this mail will clarify our path :) So if you have any kind
of useful information or strong opinions on the general area here,
please do contribute them, and hopefully a clearer way forward will
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net