Attention Gmail users, please turn off HTML mail
by Dominik 'Rathann' Mierzejewski
Dear developers,
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
mailing lists.
Regards,
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
1 week
[HEADS UP] Eclipse dropping 32-bit arches
by Mat Booth
The message about Ceph [1] 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
32bit arches.
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 [2]
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.)
Regards,
Mat
[1]
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=526620
1 week, 2 days
OpenVPN 3 Linux client - v3 beta release
by David Sommerseth
Hi,
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
unprivileged users.
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.
<https://copr.fedorainfracloud.org/coprs/dsommers/openvpn3/>
Our main source repositories can be found here:
<https://gitlab.com/openvpn/openvpn3-linux>
<https://github.com/OpenVPN/openvpn3-linux>
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
<https://github.com/OpenVPN/openvpn3-linux/tree/master/docs/dbus>
* man pages:
<https://github.com/OpenVPN/openvpn3-linux/tree/master/docs/man/>
Feel free to reach out if you have some questions or good ideas.
--
kind regards,
David Sommerseth
OpenVPN Inc
2 weeks
Blocking criteria proposal for F30+: Printing
by Stephen Gallagher
There was a bug[1] 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
following drivers:
(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
user base).
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1628255
3 weeks
Can we please stop enforcing Signed-off-by commits?
by Miro Hrončok
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?
Thanks
(* last time it was simple-koji-ci, but it's also fedpkg and other projects on
pagure.io)
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
1 month
Tracking translation status of a package built in koji
by Sundeep Anand
Hi Everyone,
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.
Steps:
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
Click 'Next'
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
thanks,
sundeep
1 month, 1 week
Proposal: Abandon v8 package
by Tom Callaway
Background:
I made the original v8 Fedora package many moons ago, when I was more
optimistic about the possibility of separating the useful components
inside of chromium. Since that point, it has become clear that while v8
is useful software, the following facts are also true:
1. The v8 upstream is entirely disinterested in the concept of
maintaining any sort of ABI/API consistency between releases.
2. The v8 that is used in chromium is not necessarily compatible with
the upstream v8, as they have a history of picking and choosing code
changes (and even applying chromium specific changes locally).
3. Virtually all consumers of v8 (including chromium) take a git
checkout (not a specific one, just whatever they decided to code to) and
use that revision, often creating a local fork of v8 from that revision,
as they are either unwilling or unable to track v8 upstream.
4. Since v8 has no concept of a "stable" release that I can see, they
simply do security fixes to the master branch, which, combined with the
code changing violently, makes it very difficult to backport security fixes.
This means that other than plv8 (which is currently unable to build
against the current v8 package in Fedora), I do not see any consumers of
the Fedora v8 package (chromium has long since abandoned any possibility
of using it). It does contain a "d8" binary, which is a javascript CLI
debugger, but it is not clear to me that this is widely used, or that
the benefit of its inclusion in Fedora outweighs the pain of maintaining
this package.
Thus, I propose that the v8 package be abandoned/orphaned/taken to the
farm upstate to run and play with the other dogs.
If you disagree, or are crazy enough to want to take it over, speak now.
~tom
P.S. I'll still maintain v8-314 as best I can, since there are actually
users of that. The irony of that really ancient version being considered
stable (and thus, used by other software) as a result of Fedora sticking
on that version of v8 for so many releases is not lost on me.
1 month, 2 weeks
F30 Self-Contained Change proposal: Retire YUM 3
by Ben Cotton
(Note this change was previously submitted for Fedora 29:
https://pagure.io/fesco/issue/2064)
https://fedoraproject.org/wiki/Changes/Retire_YUM_3
== Summary ==
Remove yum (v3) and all related packages from Fedora.
== Owner ==
* Name: [[User:mdomonko|Michal Domonkos]]
* Email: mdomonko(a)redhat.com
== Detailed Description ==
Remove packages from the distribution:
* createrepo
* yum
* yum-langpacks
* yum-utils
* yum-metadata-parser
* yum-updatesd
* python-urlgrabber
All these packages should no longer be used and all software using
them should be migrated to DNF.
Compatibility:
* Important packages such as yum, createrepo or yum-utils will be
provided/obsoleted by relevant packages from the dnf stack
* Important executables such yum, repoquery, createrepo, etc. will be
provided either as new executables or via symlinks
== Benefit to Fedora ==
Drop an old package manager that has no active upstream development.
Move existing users to DNF which that has active development.
Secondary benefit is reducing number of packages in Fedora that still
depend on Python 2.
== Scope ==
* Proposal owners: Remove packages from the distribution: createrepo,
yum, yum-langpacks, yum-utils, yum-metadata-parser, yum-updatesd,
python-urlgrabber
* Other developers: Either remove packages from the distribution or
switch them to DNF
* Release engineering: [https://pagure.io/releng/issue/7588 #7588]
* Policies and guidelines: N/A
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
Any tool based on YUM 3 Python API will stop working. This applies on
any 3rd party software which won't be changed in Fedora as part of
this change.
CLI compatibility will be provided by DNF.
== How To Test ==
Repoclosure passes after dropping the packages.
== User Experience ==
There shouldn't be any impact on YUM users because the functionality
is provided by DNF already.
Users of tools listed in the Dependencies section shouldn't see any
difference if the migration to DNF is done properly.
== Dependencies ==
The list of source packages (SRPMs) that still depend on some of the
yum-related packages to be removed:
(see wiki page)
== Contingency Plan ==
* Contingency mechanism: Do not remove the packages in the current release.
* Contingency deadline: Beta Freeze
* Blocks release? No
* Blocks product? No
== Documentation ==
N/A
== Release Notes ==
Inform end-users about removing the YUM 3 stack and definitive migration to DNF.
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
1 month, 2 weeks
F29 System Wide Change: OpenLDAP without Non-threaded Libraries
by Jan Kurik
= Proposed System Wide Change: OpenLDAP without Non-threaded Libraries =
https://fedoraproject.org/wiki/Changes/OpenLDAPwithoutNonthreadedLibraries
Owner(s):
* Matus Honek <mhonek at redhat dot com>
OpenLDAP will not ship non-threaded version of libldap. Instead,
libldap will be built with the same threading support as libldap_r.
== Detailed description ==
After this change the non-threaded version of libldap will not be
shipped any more. Instead, this library will rather be built the same
way as the threaded libldap_r. This has been previously discussed in
Bugzilla [https://bugzilla.redhat.com/show_bug.cgi?id=1370065] and
other distributions where this change already happened. Upstream still
supports non-threaded version of their library as it might be used on
processors where threads are not supported. However, when these two
versions happen to be loaded at the same time (as discussed about Curl
in the Bugzilla) symbol names overlap which may result in
unpredictable behaviour. Immediate solution would be to symlink
libldap to libldap_r, however SONAME of the library would be the same,
hence breaking dependencies of other packages. For that reason the
solution hereby proposed should be the most convenient one.
== Scope ==
* Proposal owners:
update SPEC file so that non-threaded libldap is replaced with threaded one.
* Other developers:
None. Issues should not occur.
* Release engineering:
[https://pagure.io/releng/issue/7253]
** List of deliverables:
N/A
* Policies and guidelines:
None.
* Trademark approval:
(not needed for this Change)
--
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
1 month, 2 weeks
