F26 Self Contained Change: Making sudo pip Safe (Again)
by Jan Kurik
= Proposed Self Contained Change: Making sudo pip Safe (Again) =
https://fedoraproject.org/wiki/Changes/Making_sudo_pip_safe
Change owner(s):
* Michal Cyprian <mcyprian AT redhat DOT com>
* Petr Viktorin <pviktori AT redhat DOT com>
* Tomas Orsava <torsava AT redhat DOT com>
* Miro Hroncok <mhroncok AT redhat DOT com>
At the present time, running sudo pip3 in Fedora is not safe. Pip
shares its installation directory with dnf, can remove dnf-managed
files and generally break the Python 3 interpreter. We propose a
series of measures that will make it safe to use.
== Detailed Description ==
The danger of using sudo pip3 stems from the fact that both Python dnf
packages and sudo pip3 install modules to the same location, namely
/usr/lib/pythonX.Y/site-packages.
We aim to move the working directory for sudo pip3 to a more
appropriate location: /usr/local/lib/pythonX.Y/site-packages, and
modify the Python 3 interpreter in Fedora to scan both above mentioned
locations when importing modules. In addition, system-python—a
stripped down version of Python 3 for use by system tools—will not
read the sudo pip3 install location, making it more secure by being
less susceptible to interference by user-downloaded modules.
From the technical standpoint, this will be accomplished by changing
the sys.prefix setting in the /usr/bin/python3 executable from /usr/
to /usr/local. pip3 will thereafter use this prefix when determining
where to install modules. In addition, the original path
/usr/lib/pythonX.Y/site-packages will be added to the sys.path
variable (so that modules at that location are still processed when
importing), because this path will not be automatically scanned
anymore as it no longer lies inside the sys.prefix path. These
settings, however, will not be modified for the system-python binary,
and the %{__python3} macro will be changed from /usr/bin/python3 to
/usr/libexec/system-python. Therefore, Python dnf packages will
continue to be built with the correct installation path for system
modules.
Note that using sudo pip3 is not strictly necessary, as using pip3
install --user would satisfy the vast majority of use cases.
Nevertheless, sudo pip is far too prevalent an instruction in various
guides and installation notes throughout the Internet that there is
little hope of changing users' behaviour in this regard.
== Scope ==
* Proposal owners:
Modify the Python 3 executable as described above.
Modify the %{__python3} macro so that it points to /usr/libexec/system-python
* Other developers:
Spec files that use pip3 install without the use of a macro will need
to be modified accordingly. Only 3 like packages were identified
(python-flit, python-entrypoints, python-setuptools).
* Release engineering:
A rebuild of all Python packages will be necessary.
* List of deliverables:
All Fedora deliverables will be affected in a minor way that does not
jeopardize their delivery.
* Policies and guidelines:
The definition of the %{__python3} macro will be updated as mentioned above.
* Trademark approval:
Not needed for this Change
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
7 years, 2 months
F26 Self Contained Change: Docker Overlay 2
by Jan Kurik
= Proposed Self Contained Change: Docker Overlay 2 =
https://fedoraproject.org/wiki/Changes/DockerOverlay2
Change owner(s):
* Lokesh Mandvekar <lsm5 AT fedoraproject DOT org
* Dan Walsh <dwalsh AT redhat DOT com>
Change the default Docker Storage to be overlay2 .
== Detailed Description ==
Upstream docker is moving to overlay2 by default for its storage. We
plan on following suit. There are some performance advantages of
overlay2 over devicemapper in memory sharing, which we would like to
take advantage of. We now have SELinux support for Overlay file
systems, so the security should be just as good.
Note: Overlay is not a Posix Compliant file system, so there could be
problems with your containers running on overlay, so we want to make
sure it is fairly easy to switch back to devicemapper.
Devicemapper out of the box, on Fedora Workstation, currently defaults
to loopback devices for storage, which has a performance penalty, but
this was the only way we were able to get docker to work right away.
Switching to overlay2 will cause the storage to be shared with / and
will eliminate this performance overhead. This is the way we will ship
Fedora Workstation.
On Fedora atomic host and Fedora server we have been storing
devicemapper storage on a separate partition. We plan on doing the
same thing with overlay2. This means separate device will be mounted
on /var/lib/docker. This will make it easier for someone to switch
back to devicemapper, if overlay2 has problems.
Upgraded systems will not be effected.
If you want to switch from one storage to another take a look at the
`atomic storage` commands.
We will write up release notes to cover this change. Along with a blog
explaining the commands to switch back and forth.
== Scope ==
* Proposal owners:
Implementation of this Change
* Other developers:
N/A (not a System Wide Change)
* Release engineering:
N/A (not a System Wide Change)
* List of deliverables:
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)
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
7 years, 2 months
REMINDER: Submission deadline for System Wide Changes of Fedora 26 in
two weeks
by Jan Kurik
Hi everyone!
The submission deadline for System Wide Changes of Fedora 26 [1] is
coming pretty soon - in two weeks on January 31st. Alpha release of
Fedora 26 is planned on March 14th.
Please, submit your System Wide Changes by this deadline, earlier
better. As the deadline applies for System Wide Changes it is always
good to have most of Self Contained Changes proposed as well. In case
you'll need any help with your Change proposals, feel free to contact
me.
[1] https://fedoraproject.org/wiki/Releases/26/Schedule
Best Regards,
Jan
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
7 years, 2 months
FAmSCo Elections - January 2017 - Result announcement
by Jan Kurik
Greetings, all!
The elections for FAmSCo Elections - January 2017 have concluded, and
the results
are shown below.
FAmSCo is electing 7 seats this time.
A total of 247 ballots were cast, meaning a candidate
could accumulate up to 3211 votes (247 * 13).
The results for the elections are as follows:
# votes | name
- --------+----------------------
1623 | Robert Mayr (robyduck)
1576 | Jona Azizaj (jonatoni)
1274 | Gabriele Trombini (mailga)
1168 | Giannis Konstantinidis (giannisk)
1110 | Itamar Reis Peixoto (itamarjp)
1010 | Frederico Lima (fredlima)
964 | Sylvia Sanchez (Kohane / lailah)
- --------+----------------------
944 | Sirko Kemter (gnokii)
920 | Zacharias Mitzelos (mitzie)
862 | Marcel Ribeiro Dantas (mribeirodantas)
856 | Daniel Lara (danniel)
735 | Lucas Landim (landim)
731 | Tulio Macedo (_Teseu_ / teseu)
Congratulations to the winning candidates, and thank you all
candidates for running this elections!
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
7 years, 2 months
Council Elections - January 2017 - Result announcement
by Jan Kurik
Greetings, all!
The elections for Council - January 2017 have concluded, and the results
are shown below.
Council is electing 1 seats this time.
A total of 260 ballots were cast, meaning a candidate
could accumulate up to 1300 votes (260 * 5).
The results for the elections are as follows:
# votes | name
- --------+----------------------
743 | Robert Mayr (robyduck)
- --------+----------------------
738 | Justin W. Flory (jflory7)
466 | Giannis Konstantinidis (giannisk)
413 | Charles Profitt (cprofitt)
393 | Itamar Reis Peixoto (itamarjp/itamarjp)
Congratulations to the winning candidates, and thank you all
candidates for running this elections!
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
7 years, 2 months
FESCo Elections - January 2017 - Result announcement
by Jan Kurik
Greetings, all!
The elections for FESCo - January 2017 have concluded, and the results
are shown below.
FESCo is electing 5 seats this time.
A total of 267 ballots were cast, meaning a candidate
could accumulate up to 1869 votes (267 * 7).
The results for the elections are as follows:
# votes | name
- --------+----------------------
1401 | Kevin Fenzi (nirik / kevin)
1075 | Adam Miller (maxamillion / maxamillion)
988 | Jared Smith (jsmith / jsmith)
735 | Justin Forbes (jforbes / jforbes)
691 | Kalev Lember (kalev / kalev)
- --------+----------------------
558 | Itamar Reis Peixoto (itamarjp / itamarjp)
539 | Frederico Lima (fredlima / fredlima)
Congratulations to the winning candidates, and thank you all
candidates for running this elections!
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
7 years, 2 months
F26 System Wide Change: Enable TRIM pass down to encrypted disks
by Jan Kurik
= System Wide Change: Enable TRIM pass down to encrypted disks =
https://fedoraproject.org/wiki/Changes/EnableTrimOnDmCrypt
Change owner(s):
* Vratislav Podzimek <vpodzime AT redhat DOT com>
* Ondrej Kozina <okozina AT redhat DOT com>
Override kernel default for dm-crypt mappings of LUKS1 encrypted
volumes via flag put in /etc/crypttab file. This change should affect
only newly created encrypted storage based on LUKS1 format during
installation.
== Detailed Description ==
User base of Fedora distribution with SSDs grows steadily and while
the argument for kernel default setting not to enable the discard is
still strong one it doesn't change the fact that vast majority of
users (with SSDs) doesn't want to sacrifice better performance of
drive with discard/trim enabled for the sake of secrecy.
We're not speaking encrypted data security here and double emphasize
on it! Only the fact that blank filesystem on top of dm-crypt device
with discard enabled may create well visible patterns in ciphertext
device below on SSDs.
For LUKS1 metadata format we don't have a space to store the new
default in metadata and therefore we can't flip the default for new
LUKS1 devices being formated via libcryptsetup or cryptsetup utility.
Changing the kernel default is of the table due to risk of data
corruption with some TrueCrypt configurations involving hidden
volumes.
For rotational devices the cost of enabled discard is negligible
== Scope ==
* Proposal owners:
This change despite being system wide change due to overriding legacy
default is quite small and easy to manage.
* Other developers:
Very minor change in python-blivet. Basically we just need to store
discard keyword in /etc/crypttab lines related to new partitions
created during installation process.
* Release engineering:
N/A
* List of deliverables:
N/A
* Policies and guidelines:
Add short information in documentation we're changing long term
default and copy the reasoning there.
* Trademark approval:
N/A
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
7 years, 2 months
F26 Self Contained Change: LXQt Spin
by Jan Kurik
= Proposed Self Contained Change: LXQt Spin =
https://fedoraproject.org/wiki/Changes/LXQt_Spin
Change owner(s):
* Christian Dersch <lupinix AT mailbox DOT org>
A Fedora Spin providing the LXQt desktop environment.
== Detailed Description ==
LXQt is a lightweight Qt-based desktop environment. Fedora provides it
since Fedora 22 as a group of packages. Now that LXQt is much more
complete, it is time to provide a live spin to our users. Therefore
some effort has been made to provide a first impression and it is
ready for submission as an official spin.
== Scope ==
* Proposal owners:
Implement this Change, almost done.
https://pagure.io/lxqt-remix
* Other developers:
N/A (not a System Wide Change)
* Release engineering:
Add spin to spin-kickstarts, ensure spin has been tested, and release
with rest of spins
* Policies and guidelines:
N/A (not a System Wide Change)
* Trademark approval:
requested
https://pagure.io/Fedora-Council/tickets/issue/84
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
7 years, 2 months
F26 System Wide Change: Separate Subpackage and Source Debuginfo
by Jan Kurik
= System Wide Change: Separate Subpackage and Source Debuginfo =
https://fedoraproject.org/wiki/Changes/SubpackageAndSourceDebuginfo
Change owner(s):
* Mark Wielaard <mjw AT redhat DOT com>
* Neal Gompa <ngompa13 AT gmail DOT com>
Allow to install just the debuginfo for a subpackage and/or without
the source files. The debuginfo packages are huge because they contain
debuginfo and all sources for all subpackages. Being able to install
only the debuginfo for the subpackage that is installed reduces the
size that needs to be downloaded to analyze, trace, profile or debug a
program or core file. Some tracing and profiling tools don't need the
actual source files to provide stack traces or insert probes. So
installing the debugsources should be optional.
== Detailed Description ==
Currently both the .debug files and the source files of all
subpackages are included in a debuginfo package. This creates huge
debuginfo packages with a lot of data that might not be relevant to
the user/developer. By splitting out the sources (found under
/usr/src/debug) and the .debug file for the separate binaries of the
subpackages (under /usr/lib/debug) the amount of data a developer/user
needs to install to trace, profile or debug will be greatly reduced.
Other distributions (notably Suse) already split their debuginfo
packages this way. We will take those patches
(https://build.opensuse.org/package/view_file/openSUSE:Factory/rpm/debugsu...)
and integrate them into rpm upstream. This will involve two steps: -
https://taiga.fedorainfracloud.org/project/mjw-better-rpm-debuginfo-packa...
- https://taiga.fedorainfracloud.org/project/mjw-better-rpm-debuginfo-packa...
This depends on some of the cleanups introduced by the
ParallelInstallableDebuginfo change.
We can either make this work with the current dnf debuginfo-install
plugin by providing a meta package that matches the main-debuginfo
package which depends on all sub- and source-debuginfo packages. Or we
work with the dnf hackers to make dnf debuginfo-install work with
sub-debuginfo packages.
A couple of packages already have hand-written sub-debuginfo packages
(notably the kernel, glibc and gcc). We will work with those packages
to adopt the new standard approach.
Release engineering needs to be involved to see if any changes are
necessary for adding the sub-debuginfo/debugsources packages to the
repodata.
== Scope ==
* Proposal owners:
Patches against rpm upstream need to be integrated as outlined in the
Detailed Description.
* Other developers:
Upstream rpm and dnf maintainers have to review the proposed patches.
If accepted the package maintainers will have to decide whether those
patches can be backported for the next fedora release. Packages that
now split their debuginfo packages by hand might want to change their
package to adopt the new (standard) approach. Once all changes are in
a package debuginfo needs to be regenerated before it becomes
sub-package/source split.
* Release engineering:
Needs to be discussed. In theory no changes apart from those listed
above are needed. But release engineering might know whether any
changes are necessary for adding the sub-debuginfo/debugsources
packages to the repodata.
* List of deliverables:
N/A (Still Unknown)
* Policies and guidelines:
No changes, the debuginfo related rpm macros won't change. They will
just start producing sub-package debuginfo and debugsources packages
once all changes are in place.
* Trademark approval:
N/A (not needed for this Change)
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
7 years, 2 months